Lineamientos para crear clústeres escalables

En este documento, se proporciona una guía para ayudarte a decidir cómo crear, configurar y operar clústeres de GKE que admitan cargas de trabajo que se acerquen a los límites de Kubernetes conocidos.

¿Qué es la escalabilidad?

En un clúster de Kubernetes, la escalabilidad se refiere a la capacidad del clúster para crecer dentro de los objetivos de nivel de servicio (SLO). Kubernetes también tiene su propio conjunto de SLO.

Kubernetes es un sistema complejo, y su capacidad de escalar está determinada por varios factores. Algunos de estos factores incluyen el tipo y la cantidad de nodos en un grupo de nodos, los tipos y la cantidad de grupos de nodos, la cantidad de pods disponibles, cómo se asignan los recursos a los pods y la cantidad de servicios o backends detrás de un servicio.

Prepara para la disponibilidad

Elige un plano de control regional o zonal

Debido a las diferencias en la arquitectura, los clústeres regionales son más adecuados para una alta disponibilidad. Los clústeres regionales tienen varios nodos principales en múltiples zonas de procesamiento en una región, mientras que los clústeres zonales tienen un nodo principal en una sola zona de procesamiento.

Si se actualiza un clúster zonal, la VM principal única experimenta un tiempo de inactividad durante el cual la API de Kubernetes no está disponible hasta que se complete la actualización.

En los clústeres regionales, el plano de control permanece disponible durante el mantenimiento del clúster, como la rotación de IP, la actualización de VM principales o el cambio de tamaño de clústeres o grupos de nodos. Cuando se actualiza un clúster regional, dos de cada tres VM principales siempre se ejecutan durante la actualización progresiva, por lo que la API de Kubernetes aún está disponible. Del mismo modo, una interrupción de una sola zona no causará ningún tiempo de inactividad en el plano de control regional.

Sin embargo, los clústeres regionales con alta disponibilidad tienen ciertas compensaciones:

  • Los cambios en la configuración del clúster tardan más porque deben propagarse a través de todos los principales en un clúster regional, en lugar del plano de control único en clústeres zonales.

  • Es posible que no puedas crear ni actualizar clústeres regionales con tanta frecuencia como los clústeres zonales. Si no se pueden crear VM en una de las zonas, ya sea por falta de capacidad o cualquier otro problema transitorio, no se podrán crear ni actualizar los clústeres.

Debido a estas compensaciones, los clústeres zonales y regionales tienen casos prácticos diferentes:

  • Usa clústeres zonales para crear o actualizar clústeres con rapidez cuando la disponibilidad no sea una preocupación.
  • Usa clústeres regionales cuando la disponibilidad sea más importante que la flexibilidad.

Selecciona con cuidado el tipo de clúster cuando crees uno porque no puedes cambiarlo después. En su lugar, debes crear un clúster nuevo y, luego, migrar el tráfico hacia él. La migración del tráfico de producción entre clústeres es posible, pero difícil hacerlo a gran escala.

Elige grupos de nodos multizonales o zonales

Para lograr una alta disponibilidad, el plano de control de Kubernetes y sus nodos deben distribuirse en diferentes zonas. GKE ofrece dos tipos de grupos de nodos: zonales y multizonales.

Para implementar una aplicación con alta disponibilidad, distribuye la carga de trabajo en múltiples zonas de procesamiento en una región mediante el uso de grupos de nodos multizonales que distribuyen los nodos de manera uniforme entre las zonas.

Si todos los nodos están en la misma zona, no podrás programar pods si no se puede acceder a la zona. El uso de grupos de nodos multizonales tiene ciertas compensaciones:

  • Los problemas intermitentes de redes interzonadas son otro modo de error que se debe tener en cuenta. La aplicación debe estar diseñada para funcionar si algunos nodos no pueden comunicarse con otros.

  • Las GPU solo están disponibles en zonas específicas. Puede que no sea posible obtenerlos en todas las zonas de la región.

Se espera que la latencia ida y vuelta entre ubicaciones dentro de una sola región permanezca por debajo de 1 ms en el percentil 95. La diferencia en la latencia del tráfico entre el tráfico zonal y el interzonal debe ser insignificante. El precio del tráfico de salida entre zonas en la misma región está disponible en la página de precios de Compute Engine.

Prepara para escalar

Infraestructura base

Las cargas de trabajo de Kubernetes requieren redes, procesamiento y almacenamiento. Debes proporcionar suficiente memoria y CPU para ejecutar pods. Sin embargo, existen más parámetros de infraestructura subyacente que pueden influir en el rendimiento y la escalabilidad de un clúster de GKE.

Redes de clústeres

GKE ofrece dos tipos de redes de clústeres: las antiguas basadas en rutas y las de VPC nativa más recientes.

  • Clústeres basados en rutas: cada vez que se agrega un nodo, se agrega una ruta personalizada a la tabla de enrutamiento en la red de VPC.

  • Clústeres de VPC nativa: en este modo, la red de VPC tiene un rango secundario para todas las direcciones IP de pods. A cada nodo se le asigna una porción del rango secundario para sus propias direcciones IP de pod. Esto permite que la red de VPC entienda de forma nativa cómo enrutar el tráfico a los pods sin depender de rutas personalizadas. Una sola red de VPC puede tener hasta 15,000 VM conectadas por lo que un clúster de VPC nativa escala verticalmente de manera efectiva hasta 5,000 nodos.

Gestiona IP en clústeres de VPC nativa

Un clúster de VPC nativa usa el rango de IP principal para los nodos y dos rangos de IP secundarios para los pods y los servicios. La cantidad máxima de nodos en los clústeres de VPC nativa puede estar limitada por las direcciones IP disponibles. La cantidad de nodos se determina por el rango principal (subred de nodo) y el rango secundario (subred de pod). La cantidad máxima de pods y servicios se determina por el tamaño de los rangos secundarios del clúster, la subred del pod y la de servicio, respectivamente.

Por configuración predeterminada, se establecen estos ajustes:

  • El rango secundario del pod se establece en /14 (262,144 direcciones IP) de forma predeterminada.
  • Cada nodo tiene un rango /24 asignado para sus pods (256 direcciones IP para sus pods).
  • La subred del nodo es /20 (4,092 direcciones IP).

Sin embargo, debe haber suficientes direcciones en ambos rangos (nodo y pod) para aprovisionar un nodo nuevo. Con los valores predeterminados, solo se pueden crear 1,024 debido a la cantidad de direcciones IP del pod.

De forma predeterminada, puede haber un máximo de 110 pods por nodo y cada nodo en el clúster tiene un rango de /24 asignado para sus pods. Esto da como resultado 256 direcciones IP de pod por nodo. Dado que hay dos direcciones IP disponibles por cada pod posible, Kubernetes puede mitigar la reutilización de las direcciones IP a medida que los pods se agregan y se quitan de un nodo. Sin embargo, esto es un desperdicio para ciertas aplicaciones que planean programar una cantidad menor de pods por nodo. La función Pod CIDR flexible permite que se configure el tamaño de bloque CIDR por nodo para pods y use menos direcciones IP.

De manera predeterminada, el rango secundario para los servicios se establece en /20 (4,096 direcciones IP), lo que limita el número de servicios en el clúster a 4,096.

Configura nodos para un mejor rendimiento

Los nodos de GKE son máquinas virtuales de GCP normales. Algunos de sus parámetros, por ejemplo, la cantidad de núcleos o el tamaño del disco, pueden influir en el rendimiento de los clústeres de GKE.

Tráfico de salida

En GCP, la cantidad de núcleos asignados a la instancia determina su capacidad de red. Un núcleo virtual proporciona un ancho de banda de salida de 2 Gbps; el ancho de banda máximo es de 16 Gbps o 32 Gbps en máquinas Skylake (función Beta). Todos los tipos de máquina de núcleo compartido tienen un límite de 1 Gbps.

IOPS y capacidad de procesamiento del disco

En GCP, el tamaño de los discos persistentes determina el IOPS y el rendimiento del disco. Por lo general, GKE usa discos persistentes como discos de arranque y para respaldar los volúmenes persistentes de Kubernetes. El aumento del tamaño del disco incrementa tanto IOPS como el rendimiento, hasta ciertos límites.

Cada operación de escritura de disco persistente contribuye al límite de salida de red acumulativo de la instancia de máquina virtual. Por lo tanto, el rendimiento de IOPS de los discos, en especial los SSD, también depende de la cantidad de CPU virtuales en la instancia, además del tamaño del disco. Las VM de núcleo inferior tienen límites de IOPS de escritura más bajos debido a las limitaciones de salida de red en la capacidad de procesamiento de escritura.

Si tu instancia de máquina virtual no tiene suficientes CPU, tu aplicación no podrá acercarse al límite de IOPS. Como regla general, debes tener una CPU disponible para cada 2,000 o 2,500 IOPS de tráfico esperado.

Para las cargas de trabajo que requieren una alta capacidad o una gran cantidad de discos, se debe tener en cuenta los límites de la cantidad de PD que se pueden conectar a una sola VM. Para las VM normales, ese límite es de 128 discos con un tamaño total de 64 TB, mientras que las VM de núcleo compartido tienen un límite de 16 PD con un tamaño total de 3 TB. GCP aplica este límite, no Kubernetes.

Comprende los límites

Kubernetes, como cualquier otro sistema, tiene límites que deben tenerse en cuenta cuando se diseñan aplicaciones y se planifica su crecimiento.

Kubernetes admite hasta 5,000 nodos por clúster. Sin embargo, Kubernetes es un sistema complejo con una gran cantidad de características. La cantidad de nodos es solo una de las muchas dimensiones en las que se puede escalar Kubernetes. Otras dimensiones incluyen la cantidad total de pods, servicios o backends detrás de un servicio.

No deberías estirar más de una dimensión a la vez. Este estrés puede causar problemas, incluso en clústeres más pequeños.

Por ejemplo, es posible que el intento de programar 100 pods por nodo en un clúster de 5,000 nodos no tenga éxito, porque la cantidad de pods, la cantidad de pods por nodo y la cantidad de nodos se extendería demasiado.

Límites de dimensión

Puedes consultar la lista oficial de límites de Kubernetes.

Ni esta lista ni los siguientes ejemplos forman una lista exhaustiva de los límites de Kubernetes. Esos números se obtienen con un clúster simple de Kubernetes sin extensiones instaladas. Es común ampliar los clústeres de Kubernetes con webhooks o CRD, pero puede limitar tu capacidad para escalar el clúster.

La mayoría de esos límites no se aplican, por lo que puedes superarlos. El clúster no quedará inutilizable al instante si se exceden los límites. El rendimiento se degrada (a veces, se muestra con fallos de los SLO) antes de que se produzca un error. Además, algunos de los límites se dan para el clúster más grande posible. En clústeres más pequeños, los límites son proporcionalmente más bajos.

  • Cantidad de pods por nodo. GKE tiene un límite estricto de 110 pods por nodo. Esto supone un promedio de dos o menos contenedores por pod. Tener demasiados contenedores puede reducir el límite de 110 porque algunos recursos se asignan por contenedor.

  • La cantidad total de servicios debe mantenerse por debajo de 10,000. El rendimiento de iptables se degrada si hay demasiados servicios o si hay una gran cantidad de backends detrás de un servicio.

  • La cantidad de pods detrás de un solo servicio es segura si se mantiene por debajo de 250. Kube-proxy se ejecuta en todos los nodos y observa todos los cambios en los extremos y los servicios. Por lo tanto, cuanto más grande sea el clúster, más datos se deberán enviar. El límite estricto es de alrededor de 5,000, según la longitud de los nombres de los pod y sus espacios de nombres. Si son más largos, se almacenan más bytes en etcd, donde el objeto Endpoint excede el tamaño máximo de la fila etcd. Con más tráfico de backend, las actualizaciones se vuelven grandes, en especial en clústeres grandes (más de 500 nodos). Puedes superar esta cantidad un poco, siempre que la cantidad de pods detrás del servicio se mantenga al mínimo o el tamaño del clúster se mantenga pequeño.

  • La cantidad de servicios por espacio de nombres no debe exceder los 5,000. Después de esto, la cantidad de variables de entorno del servicio supera los límites de shell y hace que los pods fallen al inicio. En Kubernetes 1.13, puedes inhabilitar la inclusión de esas variables propagadas si estableces enableServiceLinks en PodSpec como falso.

  • Cantidad total de objetos. Existe un límite para todos los objetos de un clúster, tanto los incorporados como los CRD. Depende de su tamaño (cuántos bytes se almacenan en etcd); con qué frecuencia cambian; y los patrones de acceso (por ejemplo, la lectura frecuente de todos los objetos de un tipo mataría a etcd mucho más rápido).

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Kubernetes Engine