Acerca de los Services LoadBalancer

Autopilot estándar

En esta página, se proporciona una descripción general de cómo Google Kubernetes Engine (GKE) crea y administra Google Cloud balanceadores de cargas cuando aplicas un manifiesto de objetos Service LoadBalancer de Kubernetes. Describe los tipos de LoadBalancer, los parámetros de configuración y proporciona recomendaciones de prácticas recomendadas.

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 Google Cloud balanceador de cargas de paso cuyas características dependen de los parámetros de tu manifiesto de Service.

Personaliza tu Service LoadBalancer

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

• Tipo de balanceador de cargas: interno o externo
• Política de tráfico externo
• Balanceo de cargas ponderado
• Afinidad zonal

Figura: Árbol de decisión del Service LoadBalancer

Tipo de balanceador de cargas: interno o externo

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

• Los objetos Service LoadBalancer externos se implementan con balanceadores de cargas de red de transferencia externos. Los clientes ubicados fuera de tu red de VPC y las VMs con acceso a Internet pueden acceder a un Service LoadBalancer externo. Google Cloud

  Cuando creas un servicio LoadBalancer y no especificas ningún parámetro de configuración personalizado, se usa esta configuración de forma predeterminada.

  Como práctica recomendada, cuando crees un objeto Service LoadBalancer externo, incluye la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del Service. Si incluyes esta anotación en el manifiesto del Service, se creará un balanceador de cargas de red de transferencia externo basado en servicios de backend.

  Los manifiestos de Service LoadBalancer que omiten la anotación cloud.google.com/l4-rbs: "enabled" crean un balanceador de cargas de red de transferencia externo basado en grupos de destino. Ya no se recomienda usar balanceadores de cargas de red de transferencia externos basados en grupos de destino.

• 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 en una red conectada a la red de VPC del clúster pueden acceder a un objeto Service LoadBalancer interno.

  Para crear un objeto Service LoadBalancer interno, haz lo siguiente:

  • Como práctica recomendada, asegúrate de que la subdivisión de GKE esté habilitada para que GKE pueda agrupar nodos de manera eficiente con grupos de extremos de red (NEG) de GCE_VM_IP. La subdivisión de GKE no es obligatoria, pero se recomienda.

  • Incluye la anotación networking.gke.io/load-balancer-type: "Internal" en el manifiesto de Service.

Efecto de externalTrafficPolicy

El parámetro externalTrafficPolicy controla lo siguiente:

• Qué nodos reciben paquetes del balanceador de cargas
• Si los paquetes se pueden enrutar entre los nodos del clúster después de que el balanceador de cargas los entrega a un nodo
• Si se conserva o pierde la dirección IP del cliente original

El externalTrafficPolicy puede ser Local o Cluster:

• Usa externalTrafficPolicy: Local para garantizar que los paquetes se entreguen solo a un nodo con al menos un Pod de entrega listo y sin cerrar, y conservar la dirección IP de origen del cliente original. Esta opción es mejor para las cargas de trabajo con una cantidad relativamente constante de nodos con Pods de entrega, incluso si la cantidad general de nodos en el clúster varía. Esta opción es obligatoria para admitir el balanceo de cargas ponderado.

Nota: El uso de la política Local para conservar las direcciones IP de origen no funcionará si ip-masq-agent se está ejecutando en tu clúster y el rango de direcciones IP del Pod no se excluye del masquerading de IP. Consulta custom nonMasqueradeCIDRs list in the ip-masq-agent configMap para obtener instrucciones sobre cómo excluir rangos de direcciones IP del masquerading.

• Usa externalTrafficPolicy: Cluster en situaciones en las que la cantidad general de nodos en tu clúster es relativamente constante, pero la cantidad de nodos con Pods de entrega varía. Esta opción no conserva las direcciones IP de origen del cliente originales y puede agregar latencia, ya que los paquetes se pueden enrutar a un Pod de servicio en otro nodo después de que se entregan a un nodo desde el balanceador de cargas. Esta opción no es compatible con el balanceo de cargas ponderado.

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

Importante: En el caso de los servicios de LoadBalancer internos, externalTrafficPolicy también determina de forma indirecta la cantidad de nodos con Pods de entrega admitidos. Para obtener más información, consulta Consideraciones sobre el recuento de nodos.

Balanceo de cargas ponderado

Los objetos Service LoadBalancer externos admiten el balanceo de cargas ponderado, lo que permite que los nodos con más Pods de servicio, listos y no finalizados reciban una mayor proporción de conexiones nuevas en comparación con los nodos con menos Pods. Para obtener más información sobre cómo cambian las configuraciones del balanceador de cargas con el balanceo de cargas ponderado, consulta Efecto del balanceo de cargas ponderado.

Figura: Distribución del tráfico del balanceo de cargas ponderado

Como se ilustra en el diagrama, los servicios con balanceo de cargas ponderado habilitado distribuyen las conexiones nuevas de forma proporcional a la cantidad de Pods listos en cada nodo, lo que garantiza que los nodos con más Pods reciban una mayor proporción de conexiones nuevas.

Para usar el balanceo de cargas ponderado, debes cumplir con todos los siguientes requisitos:

• Tu clúster de GKE debe usar la versión 1.31.0-gke.1506000 o una posterior.

• El complemento HttpLoadBalancing debe estar habilitado para tu clúster. Este complemento está habilitado de forma predeterminada. Permite que el clúster administre los balanceadores de cargas que usan servicios de backend.

• Debes incluir la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del Service LoadBalancer para que GKE cree un balanceador de cargas de red de transferencia externo basado en servicios de backend. Los balanceadores de cargas de red de transferencia externos basados en grupos de destino no admiten el balanceo de cargas ponderado.

• Debes incluir la anotación networking.gke.io/weighted-load-balancing: pods-per-node en el manifiesto del Service LoadBalancer para habilitar la función de balanceo de cargas ponderado.

• El manifiesto del Service LoadBalancer debe usar externalTrafficPolicy: Local. GKE no te impide usar externalTrafficPolicy: Cluster, pero externalTrafficPolicy: Cluster inhabilita de manera efectiva el balanceo de cargas ponderado porque el paquete podría enrutarse, después del balanceador de cargas, a un nodo diferente.

Para usar el balanceo de cargas ponderado, consulta Cómo habilitar el balanceo de cargas ponderado.

Afinidad zonal

Los servicios LoadBalancer internos admiten la afinidad zonal (vista previa), que puede enrutar conexiones nuevas a nodos con Pods de entrega en la misma zona que un cliente. Mantener el tráfico dentro de una zona puede minimizar el tráfico interzonal, lo que reduce el costo y la latencia.

Para usar la afinidad zonal, consulta Cómo usar la afinidad zonal. Para obtener más información sobre cómo cambian las configuraciones del balanceador de cargas con la afinidad zonal, incluso cuándo puedes mantener el tráfico dentro de una zona, consulta Efecto de la afinidad zonal. Para obtener más información sobre cómo la afinidad zonal y externalTrafficPolicy influyen en el enrutamiento de paquetes en las VMs de nodos, consulta Traducción de direcciones de red de origen y enrutamiento en nodos.

Consideraciones especiales para los Services LoadBalancer internos

En esta sección, se describe la opción de subdivisión de GKE, que es exclusiva de los servicios LoadBalancer internos, y cómo la subdivisión de GKE interactúa con externalTrafficPolicy para influir en la cantidad máxima de nodos balanceados por carga.

Subdivisión de GKE

Práctica recomendada:

Habilita la subdivisión de GKE para mejorar la escalabilidad de los objetos Service LoadBalancer internos.

La subdivisión de GKE, también llamada subdivisión de GKE para balanceadores de cargas internos de capa 4, es una opción de configuración de todo el clúster que mejora la escalabilidad de los balanceadores de cargas de red de transferencia internos agrupando de manera más eficiente los extremos de nodo en grupos de extremos de red (NEG) de GCE_VM_IP. Los NEG se usan como backends del balanceador de cargas.

En el siguiente diagrama, se muestran dos Services en un clúster zonal con tres nodos. El clúster tiene habilitada la subdivisión de GKE. Cada objeto Service tiene dos Pods. GKE crea un NEG de GCE_VM_IP para cada Service. Los extremos de cada NEG son los nodos con los Pods de entrega para el Service respectivo.

Puedes habilitar la subdivisión de GKE cuando creas un clúster o actualizas un clúster existente. Una vez habilitada, no puedes inhabilitar la 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.

Nota: La subdivisión de GKE es diferente de la subdivisión de backend del balanceador de cargas de red de transferencia interno Google Cloud. Los balanceadores de cargas de red de transferencia internos que crea GKE nunca se configuran para usar la subdivisión de backend del balanceador de cargas de red de transferencia interno.

Recuento de nodos

Un clúster con la subdivisión de GKE inhabilitada puede tener problemas con los Services LoadBalancer internos si tiene más de 250 nodos en total (entre todos los grupos de nodos). Esto sucede porque 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 por los siguientes dos motivos:

• GKE no usa la subdivisión de backend del balanceador de cargas.
• 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.

Un clúster con subdivisión de GKE admite Services LoadBalancer internos en clústeres con más de 250 nodos en total.

• Un Service LoadBalancer interno que usa externalTrafficPolicy: Local en un clúster que tiene habilitada la subdivisión de GKE admite hasta 250 nodos con Pods de entrega que respaldan este Service.

• Un Service LoadBalancer interno que usa externalTrafficPolicy: Cluster en un clúster que tiene habilitada la subdivisión de GKE no impone ninguna limitación en la cantidad de nodos con Pods de entrega, ya que GKE no configura más de 25 extremos de nodos en los NEG de GCE_VM_IP. Para obtener más información, consulta Membresía de nodos en backends de NEG de GCE_VM_IP.

Distribución del tráfico

De forma predeterminada, los objetos Service LoadBalancer internos y externos crean balanceadores de cargas de red de transferencia con la afinidad de sesión establecida en NONE. Los balanceadores de cargas de red de transferencia usan la afinidad de sesión, la información de estado y, en ciertas circunstancias, detalles como el peso para identificar y seleccionar un backend de nodo apto para una conexión nueva.

Las conexiones nuevas crean entradas en la tabla de seguimiento de conexiones, que se usan para enrutar rápidamente los paquetes posteriores de la conexión al backend del nodo apto seleccionado previamente. Para obtener más información sobre cómo los balanceadores de cargas de red de transferencia identifican y seleccionan los backends aptos, y cómo usan el seguimiento de conexiones, consulta lo siguiente:

• Distribución del tráfico en los balanceadores de cargas de red de transferencia internos

• Distribución del tráfico en los balanceadores de cargas de red de transferencia externa

Efecto del balanceo de cargas ponderado

Cuando configuras el balanceo de cargas ponderado para un objeto Service de tipo LoadBalancer externo, GKE habilita el balanceo de cargas ponderado en el balanceador de cargas de red de transferencia externo correspondiente. GKE configura el software kube-proxy o cilium-agent para incluir un encabezado de respuesta en la respuesta a la verificación de estado del balanceador de cargas. Este encabezado de respuesta define un peso que es proporcional a la cantidad de Pods en servicio, listos y no finalizados en cada nodo.

El balanceador de cargas usa la información del peso de la siguiente manera:

• El conjunto de backends de nodos aptos del balanceador de cargas consta de todos los nodos en buen estado y con una ponderación distinta de cero.

• El balanceador de cargas tiene en cuenta el peso cuando selecciona uno de los backends de nodos aptos. Cuando el Service usa externalTrafficPolicy: Local (obligatorio para que el balanceo de cargas ponderado sea eficaz), es más probable que se seleccione un backend de nodo apto que tenga más Pods de entrega listos y no finalizables que un backend de nodo apto con menos Pods.

Efecto de la afinidad zonal

Cuando configuras la afinidad zonal para un objeto Service LoadBalancer interno, GKE configura el balanceador de cargas de red de transferencia interno correspondiente con la opción ZONAL_AFFINITY_SPILL_CROSS_ZONE y una proporción de desbordamiento cero.

Con esta configuración de afinidad zonal, el balanceador de cargas reduce el conjunto original de backends de nodos aptos a solo los backends de nodos aptos que se encuentran en la misma zona que el cliente cuando se cumplen todas las siguientes condiciones:

• El cliente es compatible con la afinidad zonal.

• Al menos un backend de nodo apto y en buen estado se encuentra en la zona del cliente.

En todas las demás situaciones, el balanceador de cargas sigue usando el conjunto original de backends de nodos aptos, sin aplicar ninguna optimización de afinidad zonal.

Para obtener más detalles sobre cómo la configuración de la afinidad zonal afecta el comportamiento del balanceador de cargas, consulta la documentación sobre la afinidad zonal.

Agrupación de nodos

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

Objeto Service LoadBalancer de GKE	Balanceador de cargas 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 habilitada^1	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 aplicada a un clúster que ejecuta la versión 1.32.2-gke.1652000 o posterior de GKE^4	Un balanceador de cargas de red de transferencia externo basado en servicios de backend cuyo servicio de backend usa backends de GCE_VM_IP grupo de extremos de red (NEG)	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.
Objeto Service LoadBalancer externo con la anotación cloud.google.com/l4-rbs: "enabled"^2 aplicada a un clúster que ejecuta una versión de GKE anterior a la 1.32.2-gke.1652000^4	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.

¹ Solo los balanceadores de cargas de red de transferencia internos creados después de habilitar la subdivisión de GKE usan NEG GCE_VM_IP. Los objetos Service LoadBalancer internos creados antes de habilitar la subdivisión de GKE continuarán usando backends de grupo de instancias no administrados. Para obtener ejemplos y orientación de configuración, consulta Crea objetos Service LoadBalancer internos.

²GKE no migra automáticamente los objetos Service LoadBalancer externos existentes de los balanceadores de cargas de red de transferencia externos basados en grupos de destino a los balanceadores de cargas de red de transferencia externos basados en servicios de backend. Para crear un objeto Service LoadBalancer externo con la tecnología de un balanceador de cargas de red de transferencia externo basado en servicios de backend, debes incluir la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del Service en el momento de la creación.

³Quitar la anotación cloud.google.com/l4-rbs: "enabled" de un objeto Service LoadBalancer externo existente con la tecnología de un balanceador de cargas de red de transferencia externo basado en servicios de backend no hace que GKE cree un balanceador de cargas de red de transferencia externo basado en grupos de destino. Para crear un objeto Service LoadBalancer externo con la tecnología de un balanceador de cargas de red de transferencia externo basado en grupos de destino, debes omitir la anotación cloud.google.com/l4-rbs: "enabled" del manifiesto del objeto Service en el momento de la creación.

⁴GKE no migra automáticamente los objetos Service LoadBalancer externos existentes con la tecnología de balanceadores de cargas de red de transferencia externos basados en servicios de backend con backends de grupos de instancias a balanceadores de cargas de red de transferencia externos basados en servicios de backend con backends de NEG GCE_VM_IP. Para crear un objeto Service LoadBalancer externo con la tecnología de un balanceador de cargas de red de transferencia externo basado en servicios de backend que usa backends de NEG GCE_VM_IP, debes incluir la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del Service y aplicar el manifiesto a un clúster que ejecute la versión 1.32.2-gke.1652000 o posterior de GKE. Para obtener instrucciones sobre la migración manual, consulta Migra a back-ends de NEG de GCE_VM_IP.

Membresía del nodo en backends de NEG GCE_VM_IP

Cuando se habilita la subdivisión de GKE para un clúster o se crean balanceadores de cargas de red de transferencia externos con cloud.google.com/l4-rbs: "enabled" en la versión 1.32.2-gke.1652000 de GKE o posterior, GKE crea un NEG GCE_VM_IP único en cada zona para cada Service LoadBalancer. 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.

Nota: El NEG GCE_VM_IP es diferente del tipo GCE_VM_IP_PORT de NEG zonal que se usa para el balanceo de cargas nativo del contenedor. Los NEG GCE_VM_IP identifican las interfaces de red de las VM del nodo según la dirección IP del nodo. Sin embargo, los paquetes tienen destinos que coinciden con la dirección IP de la regla de reenvío del balanceador de cargas y uno de los puertos configurados para la regla de reenvío.

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 las siguientes tablas.

Nodos en el balanceador de cargas de red de transferencia interno

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 nodos^1	GKE solo usa nodos que tienen al menos uno de los Pods servidor del Service como extremos para los NEG del objeto Service.

¹Limitado a 250 nodos con Pods de entrega. Puede haber más de 250 nodos en el clúster, pero los balanceadores de cargas de red de transferencia internos solo pueden distribuirse a 250 VMs de backend cuando la subdivisión de backend del balanceador de cargas de red de transferencia interno está inhabilitada. Incluso con el subconjunto de GKE habilitado, GKE nunca configura los balanceadores de cargas de red de transferencia internos con la subdivisión de backend de balanceador de cargas de red de transferencia interno. Para obtener detalles sobre este límite, consulta Cantidad máxima de instancias de VM por servicio de backend interno.

Nodos en el balanceador de cargas de red de transferencia externo

externalTrafficPolicy	Cantidad de nodos en el clúster	Membresía de los extremo
Cluster	De 1 a 250 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 250 nodos	GKE usa una subdivisión aleatoria de hasta 250 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 nodos^1	GKE solo usa nodos que tienen al menos uno de los Pods servidor del Service como extremos para los NEG del objeto Service.

¹Limitado a 3,000 nodos con Pods de entrega. Puede haber más de 3,000 nodos en el clúster, pero GKE solo admite la creación de hasta 3,000 extremos cuando crea balanceadores de cargas de red de transferencia externos basados en servicios de backend que usan backends de NEG GCE_VM_IP.

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 verdadera:

• 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 implementan una verificación de estado del balanceador de cargas. El sistema de verificación de estado del balanceador de cargas opera fuera del clúster y es diferente de un sondeo de preparación, funcionamiento o inicio de Pod.

Los paquetes de verificación de estado del balanceador de cargas se responden con el software kube-proxy (plano de datos heredado) o cilium-agent (GKE Dataplane V2) que se ejecuta en cada nodo. Los Pods no pueden responder a las verificaciones de estado del balanceador de cargas para los objetos Service de tipo LoadBalancer.

El externalTrafficPolicy del objeto Service determina qué nodos pasan la verificación de estado del balanceador de cargas. Para obtener más información sobre cómo el balanceador de cargas usa la información de las verificación de estado, consulta Distribución del tráfico.

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, incluidos los nodos sin Pods de entrega. Si existe al menos un Pod de entrega en un nodo, ese nodo pasa la verificación de estado del balanceador de cargas, independientemente del estado de su Pod.	El puerto de verificación de estado del balanceador de cargas debe ser el puerto TCP 10256. No se puede personalizar.
Local	La verificación de estado del balanceador de cargas considera que un nodo está en buen estado si existe al menos un Pod de entrega listo y sin cerrar en el nodo, independientemente del estado de cualquier otro Pod. 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 de la verificación de 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 plano de control de Kubernetes asigna el puerto de verificación de estado desde el rango de puertos del nodo, a menos que especifiques un puerto de verificación de estado personalizado.

Cuando se habilita el balanceo de cargas ponderado, el balanceador de cargas usa la información de estado y de ponderación para identificar el conjunto de backends de nodos aptos. Para obtener más información, consulta Efecto del balanceo de cargas ponderado.

Cuando la afinidad zonal está habilitada, el balanceador de cargas puede refinar el conjunto de backends de nodos aptos. Para obtener más información, consulta Efecto de la afinidad zonal.

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

Los balanceadores de cargas de red de transferencia enrutan los paquetes a la interfaz nic0 de los nodos del clúster de GKE. Cada paquete con balanceo de cargas que se recibe en 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 que usan el plano de datos heredado, 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 y enrutamiento en nodos

En la siguiente tabla, se muestra la relación entre externalTrafficPolicy y si el nodo que recibió paquetes con balanceo de cargas realiza la traducción de direcciones de red de origen (SNAT) antes de enviar los paquetes con balanceo de cargas a un Pod:

externalTrafficPolicy	Comportamiento de la SNAT
Cluster	En los clústeres de GKE que usan el plano de datos heredado, cada nodo que recibe paquetes balanceados por carga siempre cambia la dirección IP de origen de esos paquetes para que coincida con la dirección IP del nodo, ya sea que el nodo enrute los paquetes a un Pod local o a un Pod en un nodo diferente. En los clústeres de GKE que usan GKE Dataplane V2, cada nodo que recibió paquetes balanceados por carga cambia la dirección IP de origen de esos paquetes para que coincida con la dirección IP del nodo solo si el nodo receptor enruta los paquetes a un Pod en un nodo diferente. Si el nodo que recibió paquetes con balanceo de cargas los enruta a un Pod local, el nodo no cambia la dirección IP de origen de esos paquetes.
Local	Cada nodo que recibió paquetes con balanceo de cargas los enruta exclusivamente a un Pod local, y el nodo no cambia la dirección IP de origen de esos paquetes.

En la siguiente tabla, se muestra cómo externalTrafficPolicy controla el enrutamiento de los paquetes balanceados y los paquetes de respuesta de los nodos:

externalTrafficPolicy	Enrutamiento de paquetes con balanceo de cargas	Enrutamiento de paquetes de respuesta
Cluster	A continuación, se describe el comportamiento de referencia para el enrutamiento de paquetes con balanceo de cargas: Si el nodo que recibió los paquetes balanceados por carga no tiene un Pod de entrega, listo y no finalizable, ese nodo enruta los paquetes a un nodo diferente que sí tiene un Pod de entrega, listo y no finalizable. Si el nodo que recibió los paquetes balanceados por carga tiene un Pod de entrega listo y no finalizable, el nodo puede enrutar los paquetes a cualquiera de los siguientes destinos: Es un Pod local. Un nodo diferente que tiene un Pod de entrega listo y no finalizable. En los clústeres regionales, si el nodo que recibió paquetes con balanceo de cargas enruta paquetes a un nodo diferente, la afinidad zonal tiene el siguiente efecto: Si la afinidad zonal no está habilitada, el nodo diferente puede estar en cualquier zona. Si la afinidad zonal está habilitada, el nodo que recibió los paquetes con balanceo de cargas intenta enrutarlos a un nodo diferente en la misma zona. Si eso no es posible, el nodo diferente puede estar en cualquier zona. Como último recurso, si no hay Pods de entrega, listos y no finalizados para el Service en todos los nodos del clúster, ocurre lo siguiente: Si la opción Proxy Terminating Endpoints está habilitada^1, el nodo que recibió los paquetes balanceados por carga los enruta a un Pod de entrega, pero de finalización, si es posible. Si los extremos de finalización de proxy están inhabilitados o no hay Pods en todo el clúster, el nodo que recibió paquetes balanceados por carga cierra la conexión con un restablecimiento de TCP.	Los paquetes de respuesta siempre se envían desde un nodo a través del retorno directo del servidor: Si el nodo con el Pod de entrega no es el nodo que recibió los paquetes con balanceo de cargas correspondientes, el nodo de entrega envía los paquetes de respuesta al nodo receptor. Luego, el nodo receptor envía los paquetes de respuesta con el retorno directo del servidor. Si el nodo con el Pod activo es el nodo que recibió los paquetes con balanceo de cargas, ese nodo envía los paquetes de respuesta con el retorno directo del servidor.
Local	A continuación, se describe el comportamiento de referencia para enrutar paquetes con balanceo de cargas: el nodo que recibió paquetes con balanceo de cargas generalmente tiene un Pod de entrega listo y sin cerrar (porque tener un Pod de este tipo es necesario para pasar la verificación de estado del balanceador de cargas). El nodo enruta los paquetes con balanceo de cargas a un Pod local. En los clústeres regionales, la afinidad zonal no cambia el comportamiento de referencia para el enrutamiento de paquetes con balanceo de cargas. Como último recurso, si no hay Pods de entrega listos y no finalizables para el Service en el nodo que recibió paquetes balanceados por carga, sucede lo siguiente: Si la opción Proxy Terminating Endpoints está habilitada^1, el nodo que recibió los paquetes balanceados por carga los enruta a un Pod de entrega local, pero de finalización si es posible. Si los extremos de finalización de proxy están inhabilitados o el nodo que recibió paquetes balanceados por carga no tiene ningún Pod de entrega, ese nodo cierra la conexión con un restablecimiento de TCP.	El nodo con el Pod de servicio siempre es el nodo que recibió los paquetes con balanceo de cargas, y ese nodo envía los paquetes de respuesta con el retorno directo del servidor.

¹ Proxy Terminating Endpoints está habilitado en estas configuraciones:

• Clústeres de GKE que usan el plano de datos heredado: versión 1.26 de GKE y versiones posteriores
• Clústeres de GKE que usan GKE Dataplane V2: versión 1.26.4-gke.500 y posteriores de GKE

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 Google Cloud calculadora de precios.

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.