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 Google Kubernetes Engine (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 planos de control en múltiples zonas de procesamiento en una región, mientras que los clústeres zonales tienen un plano de control en una sola zona de procesamiento.

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

En los clústeres regionales, el plano de control permanece disponible durante el mantenimiento de los clústeres, como la rotación de las IP, la actualización de las VM del plano de control 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 del plano de control siempre están en ejecución 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 demoran más tiempo porque deben propagarse en todos los planos de control en un clúster regional, en lugar del plano de control único en los 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 de zona única

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: de zona única y multizonales.

Para implementar una aplicación con alta disponibilidad, distribuye la carga de trabajo entre varias zonas de procesamiento de una región mediante grupos de nodos multizonales que distribuyen los nodos de manera uniforme entre distintas 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:

  • 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 de latencia entre el tráfico zonal y el interzonal debería ser insignificante.

  • El precio del tráfico de salida entre zonas de la misma región está disponible en la página de precios de Compute Engine.

Prepárate 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úster basado 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úster nativo de la VPC: En este modo, la red de VPC tiene un rango secundario para todas las direcciones IP de los Pods. A cada nodo se le asigna una porción del rango secundario para sus propias direcciones IP de Pods. 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. Para obtener más información sobre las consecuencias de este límite, consulta la sección VM por límite de red de VPC.

Clústeres privados

En los clústeres de GKE normales, todos los nodos tienen direcciones IP públicas. En los clústeres privados, los nodos solo tienen direcciones IP internas para aislar los nodos desde la conectividad entrante y saliente hacia Internet. GKE usa el intercambio de tráfico de redes de VPC para conectar las VM que ejecutan el servidor de la API de Kubernetes con el resto del clúster. Esto permite una mayor capacidad de procesamiento entre los planos de control y los nodos de GKE, ya que el tráfico no se enruta a través de la Internet pública.

Usar clústeres privados tiene el beneficio de seguridad adicional de que los nodos no están expuestos a Internet.

Balanceo de cargas del clúster

Ingress de GKE y Cloud Load Balancing configuran e implementan balanceadores de cargas para exponer las cargas de trabajo de Kubernetes fuera del clúster y, también, a la Internet pública. Los controladores de Ingress y Service de GKE implementan objetos como reglas de reenvío, mapas de URL, servicios de backend, grupos de extremos de red, entre otros, en nombre de las cargas de trabajo de GKE. Cada uno de estos recursos tiene cuotas y límites inherentes, que también se aplican en GKE. Cuando un recurso de Cloud Load Balancing en particular alcance su cuota, evitará que un objeto Ingress o Service determinado se implemente de manera correcta y aparecerán errores en los eventos del recurso.

Estas son algunas recomendaciones y límites de escala para tener en cuenta cuando se usan Ingress y servicios de GKE:

  • Servicios Ingress (internos y externos) que se exponen a través de GKE: te recomendamos usar el balanceo de cargas nativo del contenedor con NEG con los servicios expuestos a través de Ingress de GKE.
  • Los recursos Ingress que no usan NEG solo son compatibles con clústeres de hasta 1,000 nodos. El Ingress con NEG no tiene un límite de nodos de clúster.
  • Objetos Service del balanceador de cargas interno: Los Service que implementan el balanceador de cargas de TCP/UDP interno solo son compatibles en clústeres de hasta 250 nodos.

Si necesitas aumentar la escala, comunícate con el equipo de ventas de Google Cloud para aumentar este límite. Ten en cuenta que el Ingress para el balanceo de cargas de HTTP(S) interno no tiene limitaciones de nodo por clúster y, por lo tanto, se puede usar en lugar del balanceador de cargas de TCP/UDP interno para el tráfico HTTP interno.

DNS

El descubrimiento de servicios en GKE se proporciona a través de kube-dns, que es un recurso centralizado para proporcionar una resolución de DNS a los pods que se ejecutan dentro del clúster. Esto puede generar un cuello de botella en clústeres muy grandes o para cargas de trabajo que tienen una carga de solicitudes alta. GKE realiza un ajuste de escala automático de kube-dns según el tamaño del clúster para aumentar su capacidad. Cuando esta capacidad aún no es suficiente, GKE ofrece una resolución local distribuida de las consultas de DNS en cada nodo con NodeLocal DNSCache. Esto proporciona una caché de DNS local en cada nodo de GKE que responde a las consultas de manera local, distribuye la carga y proporciona tiempos de respuesta más rápidos.

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.

De forma 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.

Si necesitas más direcciones IP que las disponibles en el espacio privado de RFC 1918, te recomendamos que uses direcciones que no sean RFC 1918.

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

Configura nodos para un mejor rendimiento

Los nodos de GKE son máquinas virtuales de Google Cloud 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 Google Cloud, el tipo de máquina y la cantidad de núcleos asignados a la instancia determinan la capacidad de red. El ancho de banda de salida máximo varía de 1 a 32 Gbps, mientras que el ancho de banda de salida máximo para las máquinas e2-medium-2 predeterminadas es de 2 Gbps. Para obtener más información sobre los límites de ancho de banda, consulta Tipos de máquinas de núcleo compartido.

IOPS y capacidad de procesamiento del disco

En Google Cloud, el tamaño de los discos persistentes determina las 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 con núcleo compartido tienen un límite de 16 PD con un tamaño total de 3 TB. Google Cloud aplica este límite, no Kubernetes.

Límites y cuotas relevantes para la escalabilidad

Límite de VM por red de VPC

Una sola red de VPC puede tener hasta 15,000 VM conectadas, lo que supera el límite de 5,000 nodos por clúster en GKE 1.17 y versiones anteriores. En el caso de GKE 1.18 y versiones posteriores, que pueden admitir hasta 15,000 nodos, un clúster nativo de la VPC puede tener casi 15,000 nodos (“casi” ya que se debe reservar una pequeña cantidad de direcciones para las necesidades del plano de control de GKE).

Ten en cuenta que, si configuraste el intercambio de tráfico entre redes, el límite de 15,000 VM se aplicará de forma predeterminada en las redes con intercambio de tráfico.

Cuota de la API de Compute Engine

Los planos de control de GKE usan la API de Compute Engine para descubrir metadatos de nodos en el clúster o conectar discos persistentes a instancias de VM.

De forma predeterminada, la API de Compute Engine permite 2,000 solicitudes de lectura cada 100 segundos, lo que puede no ser suficiente para clústeres con más de 100 nodos.

Si planeas crear un clúster con más de 100 nodos, recomendamos aumentar las cuotas de Read requests per 100 seconds y Read requests per 100 seconds per user a 4,000, como mínimo. Puedes cambiar esta configuración en Google Cloud Console.

Cuota de registro y supervisión

Es posible que debas aumentar las cuotas para la API de Cloud Logging (el valor predeterminado es 60,000 solicitudes de inserción de registros por minuto) y la API de Cloud Monitoring (el valor predeterminado es 6,000 rpm de inserción de series temporales) a medida que crece tu clúster.

Cuota de nodo

La cantidad de nodos se limita a 5,000 desde GKE 1.18 en adelante y se puede aumentar a 15,000 a pedido. Para obtener más información, consulta la sección Clústeres con más de 5,000 nodos.

Obtén información sobre 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.

Las versiones de GKE hasta la 1.17 admiten 5,000 nodos en un solo clúster. GKE 1.18 y las versiones posteriores admiten hasta 15,000 nodos. Sin embargo, Kubernetes es un sistema complejo con una gran plataforma de funciones. La cantidad de nodos es solo una de las muchas dimensiones en las que se puede escalar Kubernetes. Entre otras dimensiones, se incluyen la cantidad total de Pods, objetos Service o backends detrás de un Service. Para conocer las consideraciones relevantes sobre la creación de clústeres grandes, consulta la sección Clústeres con más 5,000 nodos.

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 110 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 Pods 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 Service se mantenga al mínimo o el tamaño del clúster se mantenga pequeño.

  • La cantidad de objetos Service por espacio de nombres no debería exceder los 5,000. Después de esto, la cantidad de variables de entorno del objeto Service supera los límites de shell y hace que los Pods fallen en el 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 detendría a etcd mucho más rápido).

Clústeres con más de 5,000 nodos

A partir de la versión 1.18, GKE admite hasta 15,000 nodos en un solo clúster. Sin embargo, se debe aclarar que todos los límites anteriores permanecen vigentes, en particular el límite de la cantidad de objetos resultantes de las limitaciones de etcd. Como resultado, no todas las cargas de trabajo implementadas en 5,000 nodos se escalarán hasta 15,000 nodos.

Además, los clústeres con más de 5,000 nodos deben ser regionales y privados.

Por lo tanto, si deseas crear un clúster con más de 5,000 nodos, primero debes crear un ticket de asistencia para solicitar un aumento de cuota superior a 5,000 nodos. El equipo de Google se comunicará contigo a fin de obtener más información sobre tu carga de trabajo y asesorarte sobre si se escalará de la forma que necesitas, o te recomendará cómo modificarla para obtener una mejor escalabilidad. Como parte de esta actividad, también te ayudaremos a aumentar de forma apropiada otras cuotas relevantes.

Inhabilita la cuenta de servicio predeterminada de activación automática

Cuando creas un pod, este tiene de forma automática la cuenta de servicio predeterminada. Puedes usar la cuenta de servicio predeterminada para acceder a la API de Kubernetes desde un pod mediante las credenciales de la cuenta de servicio activadas de forma automática.

Por cada secreto activado, el kubelet observa el kube-apiserver en busca de cambios en ese secreto. En clústeres grandes, esto se traduce en miles de observaciones y puede poner una carga significativa en el kube-apiserver. Si el pod no va a acceder a la API de Kubernetes, debes inhabilitar la cuenta de servicio predeterminada.

Próximos pasos