Balanceo de carga nativo de contenedores

En esta página se explica el balanceo de carga nativo de contenedores en Google Kubernetes Engine (GKE).

En esta página se presupone que conoces Cloud Load Balancing y los grupos de puntos finales de red (NEG) por zonas. Con el balanceo de carga nativo de contenedores, estos balanceadores de carga pueden distribuir el tráfico directamente y de forma uniforme a los pods.

Arquitectura de balanceo de carga nativo de contenedores

El balanceo de carga nativo de contenedores usa GCE_VM_IP_PORTgrupos de puntos finales de red (NEGs). Los endpoints del NEG son direcciones IP de pods.

El balanceo de carga nativo de contenedores siempre se usa en los objetos Ingress internos de GKE y es opcional en los objetos Ingress externos. El controlador de entrada crea el balanceador de carga, incluidas la dirección IP virtual, las reglas de reenvío, las comprobaciones de estado y las reglas de cortafuegos.

Para saber cómo usar el balanceo de carga nativo de contenedores con Ingress, consulta Balanceo de carga nativo de contenedores mediante Ingress.

Para tener más flexibilidad, también puedes crear NEGs independientes. En este caso, eres responsable de crear y gestionar todos los aspectos del balanceador de carga.

Ventajas del balanceo de carga nativo de contenedores

El balanceo de carga nativo de contenedores ofrece las siguientes ventajas:

Los pods son objetos principales del balanceo de carga
kube-proxy configura las reglas iptables de los nodos para distribuir el tráfico a los pods. Sin el balanceo de carga nativo de contenedores, el tráfico del balanceador de carga se dirige a los grupos de instancias de nodo y se enruta mediante reglas iptables a los pods, que pueden estar o no en el mismo nodo. Con el balanceo de carga nativo de contenedores, el tráfico del balanceador de carga se distribuye directamente a los pods que deben recibirlo, lo que elimina el salto de red adicional. El balanceo de carga nativo de contenedores también ayuda a mejorar las comprobaciones de estado, ya que se dirige directamente a los pods.

Comparación del comportamiento predeterminado (izquierda) con el comportamiento del balanceador de carga nativo de contenedores.
Rendimiento de red mejorado
Como el balanceador de carga nativo de contenedores se comunica directamente con los pods y las conexiones tienen menos saltos de red, se mejoran tanto la latencia como el rendimiento.
Visibilidad mejorada
Con el balanceo de carga nativo de contenedores, puedes ver la latencia del balanceador de carga de aplicaciones a los pods. Se puede ver la latencia del balanceador de carga de aplicaciones a cada pod, que se ha agregado con el balanceo de carga nativo de contenedores basado en la IP del nodo. De esta forma, resulta más fácil solucionar problemas de tus servicios a nivel de NEG.
Compatibilidad con funciones avanzadas de balanceo de carga
El balanceo de carga nativo de contenedores en GKE admite varias funciones de los balanceadores de carga de aplicaciones externos, como la integración con servicios como Google Cloud Google Cloud Armor, Cloud CDN y Identity-Aware Proxy. También incluye algoritmos de balanceo de carga para distribuir el tráfico de forma precisa.
Compatibilidad con Cloud Service Mesh
Se necesita el modelo de datos de NEG para usar el plano de control del tráfico totalmente gestionado de Cloud Service MeshGoogle Cloudpara mallas de servicios.

Recuperación de pods

En los pods correspondientes, el controlador de entrada gestiona una puerta de preparación de tipo cloud.google.com/load-balancer-neg-ready. El controlador Ingress sondea el estado de la comprobación del estado del balanceador de carga, que incluye el estado de todos los endpoints del NEG. Cuando el estado de la comprobación de salud del balanceador de carga indica que el endpoint correspondiente a un Pod concreto está en buen estado, el controlador de Ingress asigna el valor True a la puerta de disponibilidad del Pod. El kubelet que se ejecuta en cada nodo calcula la disponibilidad efectiva del pod, teniendo en cuenta tanto el valor de esta puerta de disponibilidad como, si se ha definido, la sonda de disponibilidad del pod.

Las comprobaciones de disponibilidad de los pods se habilitan automáticamente cuando se usa el balanceo de carga nativo de contenedores mediante objetos Ingress independientes.

Las comprobaciones de disponibilidad controlan la velocidad de una actualización continua. Cuando inicias una actualización continua, a medida que GKE crea nuevos pods, se añade un endpoint de cada nuevo pod a un NEG. Cuando el endpoint está en buen estado desde la perspectiva del balanceador de carga, el controlador Ingress define el gate de disponibilidad como True. Un pod creado recientemente debe superar al menos su puerta de readiness antes de que GKE elimine un pod antiguo. De esta forma, se asegura de que el endpoint correspondiente del pod ya haya superado la comprobación del estado del balanceador de carga y de que se mantenga la capacidad del backend.

Si la puerta de disponibilidad de un pod nunca indica que el pod está listo, debido a una imagen de contenedor incorrecta o a una comprobación del estado del balanceador de carga mal configurada, el balanceador de carga no dirigirá el tráfico al nuevo pod. Si se produce un error de este tipo durante el lanzamiento de una implementación actualizada, el lanzamiento se detiene después de intentar crear un nuevo pod, ya que el readiness gate de ese pod nunca es True. Consulta la sección de solución de problemas para obtener información sobre cómo detectar y solucionar esta situación.

Sin el balanceo de carga nativo de contenedores y los readiness gates, GKE no puede detectar si los endpoints de un balanceador de carga están en buen estado antes de marcar los pods como listos. En versiones anteriores de Kubernetes, puedes controlar la velocidad a la que se eliminan y sustituyen los pods especificando un periodo de espera (minReadySeconds en la especificación de la implementación).

GKE asigna el valor de cloud.google.com/load-balancer-neg-ready a un pod como True si se cumple alguna de las siguientes condiciones:

  • Ninguna de las direcciones IP del pod es un endpoint de un GCE_VM_IP_PORTNEG gestionado por el plano de control de GKE.
  • Una o varias de las direcciones IP del pod son endpoints de un GCE_VM_IP_PORT NEG gestionado por el plano de control de GKE. El NEG está asociado a un servicio de backend. El servicio de backend tiene una comprobación de estado del balanceador de carga correcta.
  • Una o varias de las direcciones IP del pod son endpoints de un GCE_VM_IP_PORT NEG gestionado por el plano de control de GKE. El NEG está asociado a un servicio de backend. La comprobación del estado del balanceador de carga del servicio de backend se agota.
  • Una o varias de las direcciones IP del pod son endpoints de uno o varios NEGs.GCE_VM_IP_PORT Ningún NEG está asociado a un servicio de backend. No hay datos disponibles sobre las comprobaciones de estado del balanceador de carga.

Afinidad de sesión

El balanceo de carga nativo de contenedores admite la afinidad de sesión basada en pods.

Requisitos para usar el balanceo de carga nativo de contenedores

Los balanceadores de carga nativos de contenedores a través de Ingress en GKE tienen los siguientes requisitos:

  • El clúster debe ser nativo de VPC.
  • El clúster debe tener habilitado el complemento HttpLoadBalancing. Los clústeres de GKE tienen habilitado el complemento HttpLoadBalancing de forma predeterminada, por lo que no debes inhabilitarlo.

Limitaciones de los balanceadores de carga nativos de contenedores

Los balanceadores de carga nativos de contenedores mediante Ingress en GKE tienen las siguientes limitaciones:

  • No admiten balanceadores de carga de red de paso a través externos.
  • No debe cambiar ni actualizar manualmente la configuración del balanceador de carga de aplicaciones que crea GKE. GKE sobrescribe los cambios que hagas.

Precios de los balanceadores de carga nativos de contenedores

Se te cobrará por el balanceador de carga de aplicaciones aprovisionado por el Ingress que crees en esta guía. Para obtener información sobre los precios de los balanceadores de carga, consulta la sección Balanceo de carga y reglas de reenvío de la página de precios de VPC.

Siguientes pasos