Balanceo de cargas nativo del contenedor

En esta página, se explica qué es el balanceo de cargas nativo del contenedor en Google Kubernetes Engine (GKE). El balanceo de cargas nativo del contenedor permite que varios tipos de balanceadores de cargas se orienten directamente a los pods y distribuyan el tráfico de manera uniforme a los pods.

Arquitectura del balanceo de cargas nativo del contenedor

El balanceo de cargas nativo del contenedor usa grupos de extremos de red (NEG) de GCE_VM_IP_PORT. Los extremos del NEG son direcciones IP de Pod.

El balanceo de cargas nativo del contenedor siempre se usa para Ingress de GKE interno y es opcional para Ingress externo. El controlador de Ingress crea el balanceador de cargas, incluidas la dirección IP virtual, las reglas de reenvío, las verificaciones de estado y las reglas de firewall.

Si deseas obtener información sobre cómo usar el balanceo de cargas nativo del contenedor con Ingress, consulta Balanceo de cargas nativo del contenedor mediante Ingress.

Para obtener más flexibilidad, también puedes crear NEG independientes. En este caso, eres responsable de crear y administrar todos los aspectos del balanceador de cargas.

Beneficios del balanceo de cargas nativo del contenedor

El balanceo de cargas nativo del contenedor ofrece los beneficios siguientes:

Los Pods son objetos principales para el balanceo de cargas
El kube-proxy configura las reglas de iptables de los nodos para distribuir el tráfico en los pods. Sin el balanceo de cargas nativo del contenedor, el tráfico del balanceador de cargas se transfiere a los grupos de instancias de nodo y se enruta mediante las reglas de iptables a los Pods que pueden o no estar en el mismo nodo. Con el balanceo de cargas nativo del contenedor, el tráfico del balanceador de cargas se distribuye directamente en los pods que deben recibir el tráfico y se borra el salto de red adicional. El balanceo de cargas nativo del contenedor también ayuda a mejorar la comprobación de estado, ya que se dirige directamente a los pods.

Comparación del comportamiento predeterminado (izquierda) con el comportamiento del balanceador de cargas nativo del contenedor.
Rendimiento de red mejorado
Debido a que el balanceador de cargas nativo del contenedor se comunica directamente con los pods y que las conexiones tienen menos saltos de red, tanto la latencia como la capacidad de procesamiento se ven mejoradas.
Mayor visibilidad
Con el balanceo de cargas nativo del contenedor, tienes visibilidad de la latencia desde el balanceador de cargas de aplicaciones hacia los pods. Se puede ver la latencia desde el balanceador de cargas de aplicaciones hacia cada uno de los pods, que se agregaron con el balanceo de cargas nativo del contenedor basado en IP. Esto facilita la solución de problemas de tus servicios a nivel de NEG.
Compatibilidad con funciones avanzadas de balanceo de cargas
El balanceo de cargas nativo del contenedor en GKE admite varias características de los balanceadores de cargas de aplicaciones externos, como la integración con los servicios de Google Cloud, como Google Cloud Armor, Cloud CDN y Identity-Aware Proxy. También cuenta con algoritmos de balanceo de cargas para lograr una distribución de tráfico exacta.
Compatibilidad con Traffic Director
Se requiere el modelo de datos NEG para usar Traffic Director, el plano de control de tráfico completamente administrado de Google Cloud para la malla de servicios.

Preparación del pod

Para los pod relevantes, el controlador Ingress correspondiente administra una puerta de preparación de tipo cloud.google.com/load-balancer-neg-ready. El controlador Ingress sondea la condición de la verificación de estado del balanceador de cargas, que incluye el estado de todos los extremos en el NEG. Cuando la condición de la verificación de estado del balanceador de cargas indica que el extremo correspondiente a un pod en particular está en buen estado, el controlador Ingress establece el valor de puerta de preparación del pod en True. El kubelet que se ejecuta en cada nodo calcula la preparación efectiva del pod, y considera el valor de esta puerta de preparación y el sondeo de preparación del pod, si está definido.

Las puertasde embarque de preparación de Pods se habilitan de forma automática cuando se usa el balanceo de cargas nativo del contenedor a través de Ingress.

Las puertas de preparación controlan la velocidad de una actualización progresiva. Cuando inicias una actualización progresiva, a medida que GKE crea pods nuevos, se agrega un extremo para cada pod nuevo a un NEG. Cuando el extremo está en buen estado desde la perspectiva del balanceador de cargas, el controlador de Ingress establece la puerta de preparación en True. Un pod recién creado debe pasar al menos su puerta de preparación antes de que GKE quite un pod anterior. Esto garantiza que el extremo correspondiente para el pod ya pasó la verificación de estado del balanceador de cargas y se mantiene la capacidad del backend.

Si la puerta de preparación de un pod nunca indica que el pod está listo, debido a una mala imagen del contenedor o una verificación de estado del balanceador de cargas mal configurado, el balanceador de cargas no dirigirá el tráfico al nuevo pod. Si se produce un error de este tipo cuando se lanza una implementación actualizada, el lanzamiento se detiene después de intentar crear un pod nuevo porque la puerta de preparación del pod nunca se establece en Verdadero. 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 cargas nativo del contenedor y las puertas de preparación, GKE no puede detectar si los extremos de un balanceador de cargas están en buen estado antes de marcar pods como listos. En versiones anteriores de Kubernetes, tú controlas la velocidad con la que se quitan y reemplazan los pods si especificas un período de retraso (minReadySeconds en la especificación de implementación).

GKE establece el valor de cloud.google.com/load-balancer-neg-ready para un Pod en True si se cumple alguna de las siguientes condiciones:

  • Ninguna de las direcciones IP del Pod son extremos en un NEG GCE_VM_IP_PORT administrado por el plano de control de GKE.
  • Una o más de las direcciones IP del pod son extremos en un NEG GCE_VM_IP_PORT administrado por el plano de control de GKE. El NEG se conecta a un servicio de backend. El servicio de backend tiene una verificación de estado del balanceador de cargas correcta.
  • Una o más de las direcciones IP del pod son extremos en un NEG GCE_VM_IP_PORT administrado por el plano de control de GKE. El NEG se conecta a un servicio de backend. Se agota el tiempo de espera de la verificación de estado del balanceador de cargas para el servicio de backend .
  • Una o más de las direcciones IP del Pod son extremos en uno o más NEG de GCE_VM_IP_PORT. Ninguno de los NEG está vinculado a un servicio de backend. No hay datos disponibles sobre la verificación de estado del balanceador de cargas.

Afinidad de sesión

El balanceo de cargas nativo del contenedor admite la afinidad de sesión basada en Pods.

Requisitos para usar el balanceo de cargas nativo del contenedor

Los balanceadores de cargas 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 el complemento HttpLoadBalancing habilitado. Los clústeres de GKE tienen el complemento HttpLoadBalancing habilitado de forma predeterminada. No debes inhabilitarlo.

Limitaciones de los balanceadores de cargas nativos del contenedor

Los balanceadores de cargas nativos de contenedores a través de Ingress en GKE tienen las siguientes limitaciones:

  • No admiten balanceadores de cargas de red de transferencia externas.
  • No debes cambiar ni actualizar de forma manual la configuración del balanceador de cargas de aplicaciones que crea GKE. GKE reemplazará todos los cambios que realices.

Precios de los balanceadores de cargas nativos del contenedor

Se te cobra por el balanceador de cargas de aplicaciones que aprovisiona el Ingress que creas en esta guía. Para obtener información sobre los precios del balanceador de cargas, consulta Balanceo de cargas y reglas de reenvío en la página de precios de VPC.

¿Qué sigue?