Acerca de los Services LoadBalancer

---

En esta página, se proporciona una descripción general de cómo Google Kubernetes Engine (GKE) crea y administra los balanceadores de cargas de Google Cloud cuando aplicas un manifiesto de objetos Service LoadBalancer de Kubernetes. Se describen los diferentes tipos de balanceadores de cargas y cómo ajustes, como externalTrafficPolicy y la subdivisión de GKE para balanceadores de cargas internos L4, determina cómo se configuran.

Antes de leer este documento, asegúrate de estar familiarizado con los conceptos de herramientas de redes de GKE.

Descripción general

Cuando creas un Service LoadBalancer, GKE configura un balanceador de cargas de paso de Google Cloud cuyas características dependen de los parámetros de tu manifiesto de Service.

Elige un Service LoadBalancer

Cuando elijas qué configuración del Service LoadBalancer usar, ten en cuenta los siguientes aspectos:

• El tipo de dirección IP del LoadBalancer. El balanceador de cargas puede tener una dirección IP interna o externa.
• La cantidad y el tipo de nodos compatibles con LoadBalancer.

Después de determinar los requisitos de arquitectura de red, usa el siguiente árbol de decisión a fin de determinar qué Service LoadBalancer elegir para la configuración de tu red.

Diferencias entre el balanceo de cargas interno y el externo

Cuando creas un objeto Service LoadBalancer en GKE, debes especificar si el balanceador de cargas tiene una dirección interna o externa:

• Si tus clientes están ubicados en la misma red de VPC o en una red conectada a la red del clúster (VPC), usa un Service LoadBalancer interno. Los objetos Service LoadBalancer internos se implementan mediante los balanceadores de cargas de red de transferencia internos. Los clientes ubicados en la misma red de VPC o una red conectada a la red de VPC del clúster pueden acceder al objeto Service mediante la dirección IP del balanceador de cargas.

  Para crear un objeto Service LoadBalancer interno, incluye una de las siguientes anotaciones en el metadata.annotations[] del manifiesto del objeto Service:

  • networking.gke.io/load-balancer-type: "Internal" (GKE 1.17 y versiones posteriores)
  • cloud.google.com/load-balancer-type: "Internal" (versiones anteriores a 1.17)

• Si tus clientes están ubicados fuera de tu red de VPC, usa un Service LoadBalancer externo. Puedes usar uno de los siguientes tipos de balanceadores de cargas de red de transferencia externos a los que se puede acceder en Internet (incluidas las VMs de Google Cloud con acceso a Internet):

  • (Recomendado) Para crear un balanceador de cargas de red de transferencia externo basado en servicios de backend, incluye lo siguiente en metadata.annotations[] del manifiesto: cloud.google.com/l4-rbs: "enabled"
  • Crea un balanceador de cargas de red de transferencia externo basado en grupos de destino omitiendo la anotación cloud.google.com/l4-rbs: "enabled".

Efecto de externalTrafficPolicy

Puedes configurar externalTrafficPolicy como Local o Cluster para definir cómo se enrutan los paquetes a los nodos con Pods que están listos y en funcionamiento. Ten en cuenta las siguientes situaciones cuando definas la externalTrafficPolicy:

• Usa externalTrafficPolicy: Local para conservar las direcciones IP de cliente originales o si deseas minimizar las interrupciones cuando cambia la cantidad de nodos sin entregar Pods en el clúster.

• Usa externalTrafficPolicy: Cluster si la cantidad general de nodos sin entregar Pods en el clúster permanece coherente, pero la cantidad de nodos con Pods de entrega cambia. Esta opción no conserva las direcciones IP de cliente originales.

Para obtener más información sobre cómo externalTrafficPolicy afecta el enrutamiento de paquetes dentro de los nodos, consulta procesamiento de paquetes.

Subdivisión de GKE

La opción de configuración de todo el clúster de subdivisión de GKE para balanceadores de cargas internos L4, o subdivisión de GKE, mejora la escalabilidad de los balanceadores de cargas de red de transferencia internos mediante la agrupación más eficiente de extremos de nodo para la carga backends del balanceador.

En el diagrama siguiente, se muestran dos objetos Services en un clúster zonal con tres nodos y la subdivisión de GKE habilitada. Cada objeto Service tiene dos Pods. GKE crea un grupo de extremos de red (NEG) de GCE_VM_IP para cada objeto Service. Los extremos de cada NEG son los nodos con los Pods servidor para el objeto Service correspondiente.

Puedes habilitar la subdivisión de GKE cuando creas un clúster o editas un clúster existente. Una vez habilitado, no puedes inhabilitar la subdivisión de GKE. Para obtener más información, consulta subdivisión de GKE.

Para la subdivisión de GKE, se requiere lo siguiente:

• Versión de GKE 1.18.19-gke.1400 o posterior, y
• El complemento HttpLoadBalancing habilitado para el clúster. Este complemento está habilitado de forma predeterminada. Permite que el clúster administre los balanceadores de cargas que usan servicios de backend.

Consideración del recuento de nodos cuando se habilita la subdivisión de GKE

Como práctica recomendada, si necesitas crear objetos Service LoadBalancer internos, debes habilitar la subdivisión de GKE. La subdivisión de GKE te permite admitir más nodos en el clúster:

• Si tu clúster tiene la subdivisión de GKE inhabilitada, no debes crear más de 250 nodos en total (entre todos los grupos de nodos). Si creas más de 250 nodos en total en el clúster, los Services LoadBalancer internos pueden experimentar una distribución de tráfico desigual o una pérdida completa de conectividad.

• Si tu clúster tiene la subdivisión de GKE habilitada, puedes usar externalTrafficPolicy: Local o externalTrafficPolicy: Cluster, siempre que la cantidad de nodos únicos con al menos un Pod de entrega no supere los 250 nodos. Los nodos sin ningún Pod de entrega no son relevantes. Si necesitas más de 250 nodos con al menos un Pod de entrega, debes usar externalTrafficPolicy: Cluster.

Los balanceadores de cargas de red de transferencia internos que crea GKE solo pueden distribuir paquetes a 250 VMs de nodo de backend o menos. Esta limitación existe porque GKE no usa la subdivisión de backend del balanceador de cargas, y un balanceador de cargas de red de transferencia interno está limitado a distribuir paquetes a 250 o menos backends cuando la subdivisión del backend del balanceador de cargas está inhabilitada.

Agrupación de nodos

Las anotaciones del manifiesto de Service y, para el Service LoadBalancer interno, la subdivisión de GKE determinan el balanceador de cargas de Google Cloud resultante y el tipo de backends. Los backends para los balanceadores de cargas de paso de Google Cloud identifican la interfaz de red (NIC) del nodo de GKE, no un nodo particular ni una dirección IP de Pod. El tipo de balanceador de cargas y de backends determina cómo se agrupan los nodos en los NEG de GCE_VM_IP, los grupos de instancias o los grupos de destino.

Objeto Service LoadBalancer de GKE	Balanceador de cargas de Google Cloud resultante	Método de agrupación de nodos
El objeto Service LoadBalancer interno creado en un clúster con la subdivisión de GKE habilitada1	Un balanceador de cargas de red de transferencia interno cuyo servicio de backend usa backends de grupo de extremos de red (NEG) GCE_VM_IP	Las VM de nodo se agrupan por zonas en NEG por GCE_VM_IP según el servicio, de acuerdo con el externalTrafficPolicy del objeto Service y la cantidad de nodos del clúster. El externalTrafficPolicy del objeto Service también controla qué nodos pasan la verificación de estado del balanceador de cargas y el procesamiento de paquetes.
El objeto Service LoadBalancer interno creado en un clúster con la subdivisión de GKE inhabilitada	Un balanceador de cargas de red de transferencia interno cuyo servicio de backend usa backends de grupo de instancias no administrado zonal	Todas las VM de nodo se colocan en grupos de instancias no administrados zonales que GKE usa como backends para el servicio de backend del balanceador de cargas de red de transferencia interno. El externalTrafficPolicy del objeto Service controla qué nodos pasan la verificación de estado del balanceador de cargas y el procesamiento de paquetes. Los mismos grupos de instancias no administrados se usan para otros servicios de backend del balanceador de cargas creados en el clúster debido a la limitación de un solo grupo de instancias con balanceo de cargas.
Objeto Service LoadBalancer externo con la anotación cloud.google.com/l4-rbs: "enabled"2	Un balanceador de cargas de red de transferencia externo basado en servicios de backend cuyo servicio de backend usa backends de grupo de instancias no administrado zonales	Todas las VM de nodo se colocan en grupos de instancias no administrados zonales que GKE usa como backends para el servicio de backend del balanceador de cargas de red de transferencia externo. El externalTrafficPolicy del objeto Service controla qué nodos pasan la verificación de estado del balanceador de cargas y el procesamiento de paquetes. Los mismos grupos de instancias no administrados se usan para otros servicios de backend del balanceador de cargas creados en el clúster debido a la limitación de un solo grupo de instancias con balanceo de cargas.
Objeto Service LoadBalancer externo sin la anotación cloud.google.com/l4-rbs: "enabled"3	Un balanceador de cargas de red de transferencia externo basado en grupos de destino cuyo grupo de destino contenga todos los nodos del clúster	El grupo de destino es una API heredada que no depende de grupos de instancias. Todos los nodos tienen membresía directa en el grupo de destino. El externalTrafficPolicy del objeto Service controla qué nodos pasan la verificación de estado del balanceador de cargas y el procesamiento de paquetes.

Membresía del nodo en backends de NEG GCE_VM_IP

Cuando se habilita el subconjunto de GKE en un clúster, GKE crea un NEG GCE_VM_IP único en cada zona para cada Service LoadBalancer interno. A diferencia de los grupos de instancias, los nodos pueden ser miembros de más de un NEG GCE_VM_IP con balanceo de cargas. El externalTrafficPolicy del Service y la cantidad de nodos del clúster determinan qué nodos se agregan como extremos a los NEG GCE_VM_IP del Service.

El plano de control del clúster agrega nodos como extremos a los NEG GCE_VM_IP según el valor del externalTrafficPolicy del objeto Service y la cantidad de nodos del clúster, como se resume en la siguiente tabla.

externalTrafficPolicy	Cantidad de nodos en el clúster	Membresía de los extremo
Cluster	Entre 1 y 25 nodos	GKE usa todos los nodos del clúster como extremos para los NEG del objeto Service, incluso si un nodo no contiene un Pod servidor para el objeto Service.
Cluster	Más de 25 nodos	GKE usa una subdivisión aleatoria de 25 nodos como extremos para los NEG del objeto Service, incluso si un nodo no contiene un Pod servidor para el objeto Service.
Local	cualquier cantidad de nodos1	GKE solo usa nodos que tienen al menos uno de los Pods servidor del Service como extremos para los NEG del objeto Service.

Limitación del grupo de instancias con balanceo de cargas único

La API de Compute Engine prohíbe que las VM sean miembros de más de un grupo de instancias con balanceo de cargas. Los nodos de GKE están sujetos a esta restricción.

Cuando se usan backends de grupos de instancias no administrados, GKE crea o actualiza grupos de instancias no administrados que contienen todos los nodos de todos los grupos de nodos en cada zona que usa el clúster. Estos grupos de instancias no administrados se usan para lo siguiente:

• Balanceadores de cargas de red de transferencia internos creados para los objetos Service LoadBalancer internos cuando la subdivisión de GKE está inhabilitada.
• Balanceadores de cargas de red de transferencia externos basados en servicios de backend creados para objetos Service LoadBalancer externos con la anotación cloud.google.com/l4-rbs: "enabled".
• Balanceadores de cargas de aplicaciones externos creados para recursos de Ingress de GKE externos, mediante el controlador de Ingress de GKE y sin usar el balanceo de cargas nativo del contenedor.

Debido a que las VM de nodo no pueden ser miembros de más de un grupo de instancias con balanceo de cargas, GKE no puede crear ni administrar balanceadores de cargas de red de transferencia internos, balanceadores de cargas de red de transferencia externos basados en servicios de backend y balanceador de cargas de aplicaciones externos creados para los recursos de Ingress de GKE si alguna de las siguientes condiciones es true:

• Fuera de GKE, creaste al menos un balanceador de cargas basado en servicios de backend y usaste los grupos de instancias administrados del clúster como backends para el servicio de backend del balanceador de cargas.
• Fuera de GKE, debes crear un grupo de instancias no administrado personalizado que contenga algunos o todos los nodos del clúster y, luego, conectar ese grupo de instancias no administrado personalizado a un servicio de backend para un balanceador de cargas.

Para solucionar esta limitación, puedes indicarle a GKE que use backends de NEG cuando sea posible:

• Habilita la subdivisión de GKE. Como resultado, los nuevos objetos Service LoadBalancer internos usan NEG GCE_VM_IP en su lugar.
• Configura los recursos de Ingress de GKE externos para usar el balanceo de cargas nativo del contenedor Para obtener más información, consulta Balanceo de cargas nativo de contenedores de GKE.

Verificaciones de estado del balanceador de cargas

Todos los objetos Service LoadBalancer de GKE requieren una verificación de estado del balanceador de cargas. La verificación de estado del balanceador de cargas se implementa fuera del clúster y es diferente de un sondeo de preparación o funcionamiento.

El externalTrafficPolicy del objeto Service define cómo opera la verificación de estado del balanceador de cargas. En todos los casos, los sistemas de sondeo de verificación de estado del balanceador de cargas envían paquetes al software kube-proxy que se ejecuta en cada nodo. La verificación de estado del balanceador de cargas es un proxy para la información que recopila kube-proxy, por ejemplo, si existe un Pod, se está ejecutando y pasó su sondeo de preparación. Las verificaciones de estado de los objetos Service de tipo LoadBalancer no pueden enrutarse a los Pods de entrega. La verificación de estado del balanceador de cargas está diseñada para dirigir las conexiones nuevas de TCP a los nodos.

En la siguiente tabla, se describe el comportamiento de la verificación de estado:

externalTrafficPolicy	Qué nodos pasan la verificación de estado	Qué puerto se usa
Cluster	Todos los nodos del clúster pasan la verificación de estado, incluso si el nodo no tiene Pods de entrega. Si existen uno o más Pods de entrega en un nodo, ese nodo pasa la verificación de estado del balanceador de cargas, incluso si los Pods de entrega finalizan o fallan los sondeos de preparación.	El puerto de verificación de estado del balanceador de cargas debe ser el puerto TCP 10256. No se puede personalizar.
Local	Solo los nodos que tengan al menos un Pod de entrega listo y sin cerrar pasan la verificación de estado del balanceador de cargas. Los nodos sin un Pod de entrega, los nodos cuyos Pods de entrega fallan en los sondeos de preparación y los nodos cuyos Pods de entrega se están cerrando fallan la verificación de estado del balanceador de cargas. Durante las transiciones de estado, un nodo aún pasa la verificación de estado del balanceador de cargas hasta que se alcanza el umbral de mal estado del balanceador de cargas. El estado de transición ocurre cuando todos los Pods de entrega en un nodo comienzan a fallar los sondeos de preparación o cuando todos los Pods de entrega en un nodo se cierran. La forma en que se procesa el paquete en esta situación depende de la versión de GKE. Para obtener detalles adicionales, consulta la siguiente sección, Procesamiento de paquetes.	El puerto de verificación de estado es el puerto TCP 10256, a menos que especifiques un puerto de verificación de estado personalizado.

Procesamiento de paquetes

En las siguientes secciones, se detalla cómo trabajan los balanceadores de cargas y los nodos del clúster a fin de enrutar los paquetes recibidos para los objetos Service LoadBalancer.

Balanceo de cargas de paso

El balanceador de cargas de paso de Google Cloud enruta los paquetes a la interfaz nic0 de los nodos del clúster de GKE. Cada paquete con balanceo de cargas recibido por un nodo tiene las siguientes características:

• La dirección IP de destino del paquete coincide con la dirección IP de la regla de reenvío del balanceador de cargas.
• El protocolo y el puerto de destino del paquete coinciden con los siguientes:
  • un protocolo y un puerto especificados en spec.ports[] del manifiesto del objeto Service
  • un protocolo y un puerto configurados en la regla de reenvío del balanceador de cargas

Traducción de direcciones de red de destino en nodos

Después de que el nodo recibe el paquete, el nodo realiza un procesamiento de paquetes adicional. En los clústeres de GKE sin GKE Dataplane V2 habilitado, los nodos usan iptables para procesar paquetes con balanceo de cargas. En los clústeres de GKE con GKE Dataplane V2 habilitado, los nodos usan eBPF en su lugar. El procesamiento de paquetes a nivel de nodo siempre incluye las siguientes acciones:

• El nodo realiza la traducción de la dirección de red de destino (DNAT) en el paquete y configura su dirección IP de destino en una dirección IP de Pod servidor.
• El nodo cambia el puerto de destino del paquete al targetPort del spec.ports[] del Service correspondiente.

Traducción de direcciones de red de origen en los nodos

externalTrafficPolicy determina si el procesamiento de paquetes a nivel del nodo también realiza la traducción de direcciones de red de origen (SNAT), así como la ruta de acceso que toma el paquete del nodo al Pod:

externalTrafficPolicy	Comportamiento de la SNAT del nodo	Comportamiento de enrutamiento
Cluster	El nodo cambia la dirección IP de origen de los paquetes con balanceo de cargas para que coincidan con la dirección IP del nodo que lo recibió del balanceador de cargas.	El nodo enruta los paquetes a cualquier Pod de activo. El Pod activo puede o no estar en el mismo nodo. Si el nodo que recibe los paquetes del balanceador de cargas no tiene un Pod listo y activo, el nodo enruta los paquetes a un nodo diferente que contiene un Pod listo y activo. Los paquetes de respuesta del Pod se enrutan desde su nodo al nodo que recibió los paquetes de solicitud del balanceador de cargas. Luego, ese primer nodo envía los paquetes de respuesta al cliente original mediante el retorno directo del servidor.
Local	El nodo no cambia la dirección IP de origen de los paquetes con balanceo de cargas.	En la mayoría de los casos, el nodo enruta el paquete a un Pod activo que se ejecuta en el nodo que recibió el paquete del balanceador de cargas. Ese nodo envía paquetes de respuesta al cliente original mediante el retorno directo del servidor. Este es el intent principal de este tipo de política de tráfico. En algunas situaciones, un nodo recibe paquetes del balanceador de cargas, aunque el nodo no tenga un Pod de entrega no finalizable para el Service. Esta situación se produce cuando la verificación de estado del balanceador de cargas aún no alcanzó su umbral de falla, pero un Pod listo y activo ya no está listo o finaliza (por ejemplo, cuando se realiza una actualización progresiva). La forma en que se procesan los paquetes en esta situación depende de la versión de GKE, de si el clúster usa GKE Dataplane V2 y el valor de externalTrafficPolicy: Sin GKE Dataplane V2, en GKE 1.26 y versiones posteriores, y con GKE Dataplane V2 en las versiones 1.26.4-gke.500 y posteriores de GKE, está habilitado el extremo de finalización del proxy. Los paquetes se enrutan a un Pod de finalización como último recurso si se cumplen todas las siguientes condiciones: Si todos los Pods de entrega finalizan y el externalTrafficPolicy es Cluster. Si todos los Pods de entrega en el nodo finalizan y el externalTrafficPolicy es Local. Para todas las demás versiones de GKE, el kernel del nodo responde con el paquete con un restablecimiento de TCP.

Precios y cuotas

Los precios de red se aplican a los paquetes que procesa un balanceador de cargas. Para obtener más información, consulta los precios de Cloud Load Balancing y las reglas de reenvío. También puedes estimar los cargos de facturación con la calculadora de precios de Google Cloud.

Las cuotas del balanceador de cargas controlan la cantidad de reglas de reenvío que puedes crear:

• Los balanceadores de cargas de red de transferencia internos usan la cuota de servicios de backend por proyecto, la cuota de verificaciones de estado por proyecto y las reglas de reenvío del balanceador de cargas de red de transferencia interno por cuota de red de nube privada virtual.
• Los balanceadores de cargas de red de transferencia externos basados en servicios de backend usan la cuota de servicios de backend por proyecto, la cuota de verificaciones de estado por proyecto y la cuota de reglas de reenvío del balanceador de cargas de red de transferencia externo.
• Los balanceadores de cargas de red de transferencia externos basados en grupos de destino usan la cuota de grupos de destino por proyecto, la cuota de verificaciones de estado por proyecto y la cuota de reglas de reenvío del balanceador de cargas de red de transferencia externo.

¿Qué sigue?

• Obtén información sobre los parámetros de Service LoadBalancer de GKE.
• Obtén información sobre los Servicios de Kubernetes.