Acerca de los servicios de tipo LoadBalancer

En esta página se ofrece una descripción general de cómo crea y gestiona Google Kubernetes Engine (GKE) los balanceadores de carga cuando aplicas un manifiesto de servicios LoadBalancer de Kubernetes. Trusted Cloud by S3NS En ella se describen los tipos de LoadBalancer y los parámetros de configuración, y se ofrecen recomendaciones sobre las prácticas recomendadas.

Antes de leer esta página, asegúrate de que conoces los conceptos de redes de GKE.

Información general

Cuando creas un servicio LoadBalancer, GKE configura un Trusted Cloud balanceador de carga de transferencia cuyas características dependen de los parámetros del manifiesto de tu servicio.

Personalizar el servicio LoadBalancer

Cuando elijas la configuración del servicio LoadBalancer que quieras usar, ten en cuenta los siguientes aspectos:

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

Tipo de balanceador de carga: interno o externo

Cuando creas un servicio LoadBalancer en GKE, especificas si el balanceador de carga tiene una dirección interna o externa:

• Los servicios LoadBalancer externos se implementan mediante balanceadores de carga de red de paso a través externos. Los clientes que se encuentran fuera de tu red de VPC y las Trusted Cloud VMs con acceso a Internet pueden acceder a un servicio LoadBalancer externo.

  Si creas un servicio LoadBalancer y no especificas ningún ajuste personalizado, se aplicará esta configuración de forma predeterminada.

  Como práctica recomendada, cuando crees un servicio LoadBalancer externo, incluye la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del servicio. Si se incluye esta anotación en el manifiesto de Service, se crea un balanceador de carga de red de paso a través externo basado en el servicio de backend.

  Los manifiestos de servicio LoadBalancer que omiten la anotación cloud.google.com/l4-rbs: "enabled" crean un balanceador de carga de red de paso a través externo basado en grupos de destino. Ya no se recomienda usar balanceadores de carga de red de paso a través externos basados en grupos de destino.

• Los servicios LoadBalancer internos se implementan mediante balanceadores de carga de red de paso a través 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 servicio LoadBalancer interno.

  Para crear un servicio LoadBalancer interno, sigue estos pasos:

  • Como práctica recomendada, asegúrate de que la subdivisión de GKE esté habilitada para que GKE pueda agrupar nodos de forma eficiente mediante GCE_VM_IPgrupos de puntos finales de red (NEGs). No es obligatorio, pero sí muy recomendable.

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

Efecto de externalTrafficPolicy

El parámetro externalTrafficPolicy controla lo siguiente:

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

externalTrafficPolicy puede ser Local o Cluster:

• Usa externalTrafficPolicy: Local para asegurarte de que los paquetes se envíen solo a un nodo con al menos un pod activo, listo y no finalizado, conservando la dirección IP de origen del cliente original. Esta opción es la más adecuada para cargas de trabajo con un número relativamente constante de nodos con pods de servicio, aunque varíe el número total de nodos del clúster. Esta opción es necesaria para admitir el balanceo de carga ponderado.

.

• Usa externalTrafficPolicy: Cluster en situaciones en las que el número total de nodos de tu clúster sea relativamente constante, pero el número de nodos con pods de servicio varíe. Esta opción no conserva las direcciones IP de origen del cliente original y puede añadir latencia porque los paquetes se pueden enrutar a un pod de servicio en otro nodo después de entregarse a un nodo desde el balanceador de carga. Esta opción no es compatible con el balanceo de carga ponderado.

Para obtener más información sobre cómo afecta externalTrafficPolicy al enrutamiento de paquetes en los nodos, consulta Procesamiento de paquetes.

Balanceo de carga ponderado

Los servicios LoadBalancer externos admiten el balanceo de carga ponderado, lo que permite que los nodos con más pods activos, 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 carga con el balanceo de carga ponderado, consulta Efecto del balanceo de carga ponderado.

Como se muestra en el diagrama, los servicios con balanceo de carga ponderado habilitado distribuyen las nuevas conexiones de forma proporcional al número de pods listos en cada nodo. De esta forma, los nodos con más pods reciben una mayor proporción de nuevas conexiones.

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

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

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

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

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

• El manifiesto de servicio LoadBalancer debe usar externalTrafficPolicy: Local. GKE no te impide usar externalTrafficPolicy: Cluster, pero externalTrafficPolicy: Cluster inhabilita de forma eficaz el balanceo de carga ponderado porque el paquete se puede enrutar, después del balanceador de carga, a un nodo diferente.

Para usar el balanceo de carga ponderado, consulta Habilitar el balanceo de carga ponderado.

Afinidad zonal

Los servicios de balanceador de carga interno admiten la afinidad zonal (vista previa), que puede enrutar nuevas conexiones a nodos con pods de servicio en la misma zona que un cliente. Mantener el tráfico dentro de una zona puede minimizar el tráfico entre zonas, lo que reduce los costes y la latencia.

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

Consideraciones especiales para los servicios de tipo LoadBalancer internos

En esta sección se describe la opción de subconjunto de GKE, que es exclusiva de los servicios LoadBalancer internos, y cómo interactúa el subconjunto de GKE con externalTrafficPolicy para influir en el número máximo de nodos con balanceo de carga.

Subconjuntos de GKE

Práctica recomendada:

Habilita la creación de subconjuntos de GKE para mejorar la escalabilidad de los servicios de balanceadores de carga internos.

La creación de subconjuntos de GKE, también llamada creación de subconjuntos de GKE para balanceadores de carga internos de capa 4, es una opción de configuración de todo el clúster que mejora la escalabilidad de los balanceadores de carga de red de pases internos agrupando de forma más eficiente los endpoints de los nodos en GCE_VM_IP grupos de endpoints de red (NEGs). Los NEG se usan como backends del balanceador de carga.

En el siguiente diagrama se muestran dos servicios en un clúster zonal con tres nodos. El clúster tiene habilitado el subconjunto de GKE. Cada servicio tiene dos pods. GKE crea un GCE_VM_IP NEG para cada servicio. Los puntos finales de cada NEG son los nodos con los pods de servicio del servicio correspondiente.

Puedes habilitar el subconjunto de GKE al crear un clúster o al actualizar uno que ya tengas. Una vez habilitado, no puedes inhabilitar la creación de subconjuntos de GKE. Para usar el subconjunto de GKE, se necesita lo siguiente:

• GKE 1.18.19-gke.1400 o una versión posterior
• El complemento HttpLoadBalancing está habilitado en el clúster. Este complemento está habilitado de forma predeterminada. Permite que el clúster gestione los balanceadores de carga que usan servicios de backend.

Recuento de nodos

Un clúster con el subconjunto de GKE inhabilitado puede tener problemas con los servicios de tipo LoadBalancer internos si el clúster tiene más de 250 nodos en total (entre todos los grupos de nodos). Esto ocurre porque los balanceadores de carga de red de paso a través internos creados por GKE solo pueden distribuir paquetes a 250 máquinas virtuales de nodo de backend o menos. Esta limitación se debe a los dos motivos siguientes:

• GKE no usa subconjuntos de backend de balanceador de carga.
• Un balanceador de carga de red de paso a través interno solo puede distribuir paquetes a 250 backends o menos cuando la función de subconjunto de backend del balanceador de carga está inhabilitada.

Un clúster con subconjuntos de GKE admite servicios LoadBalancer internos en clústeres con más de 250 nodos en total.

• Un servicio LoadBalancer interno que usa externalTrafficPolicy: Local en un clúster que tiene habilitado el subconjunto de GKE admite hasta 250 nodos con pods de servicio que respaldan este servicio.

• Un servicio LoadBalancer interno que usa externalTrafficPolicy: Cluster en un clúster que tiene habilitado el subconjunto de GKE no impone ninguna limitación en el número de nodos con pods de servicio, ya que GKE configura no más de 25 endpoints de nodo en GCE_VM_IP NEGs. Para obtener más información, consulta Pertenencia de nodos a back-ends de GCE_VM_IP NEG.

Distribución del tráfico

De forma predeterminada, los servicios LoadBalancer internos y externos crean balanceadores de carga de red de paso a través con la afinidad de sesión definida en NONE. Los balanceadores de carga de red de tipo Passthrough usan la afinidad de sesión, la información sobre el estado y, en determinadas circunstancias, detalles como el peso para identificar y seleccionar un backend de nodo apto para una nueva conexión.

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 de nodo apto seleccionado anteriormente. Para obtener más información sobre cómo identifican y seleccionan los balanceadores de carga de red de transferencia los back-ends aptos y cómo usan el seguimiento de conexiones, consulta lo siguiente:

• Distribución del tráfico de los balanceadores de carga de red de paso a través internos

• Distribución del tráfico de los balanceadores de carga de red de paso a través externos

Efecto del balanceo de carga ponderado

Cuando configuras el balanceo de carga ponderado para un servicio LoadBalancer externo, GKE habilita el balanceo de carga ponderado en el balanceador de carga de red de paso a través externo correspondiente. GKE configura el software kube-proxy o cilium-agent para incluir una cabecera de respuesta en la respuesta a la comprobación de estado del balanceador de carga. Este encabezado de respuesta define un peso proporcional al número de pods en estado de publicación, preparados y no finalizados en cada nodo.

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

• El conjunto de backends de nodos aptos del balanceador de carga está formado por todos los nodos en buen estado y con un peso distinto de cero.

• El balanceador de carga tiene en cuenta el peso cuando selecciona uno de los back-ends de nodo aptos. Cuando el servicio usa externalTrafficPolicy: Local (necesario para que el balanceo de carga ponderado sea eficaz), es más probable que se seleccione un backend de nodo apto que tenga más pods activos, listos y no finalizados que un backend de nodo apto con menos pods.

Efecto de la afinidad zonal

Cuando configuras la afinidad zonal para un servicio de balanceador de carga interno, GKE configura el balanceador de carga de red de paso a través 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 carga reduce el conjunto original de backends de nodo aptos a solo los que se encuentran en la misma zona que el cliente cuando se cumplen todas las condiciones siguientes:

• 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 el resto de las situaciones, el balanceador de carga sigue usando el conjunto original de back-ends de nodo aptos, sin aplicar ninguna optimización de afinidad zonal.

Para obtener más información sobre cómo afecta la configuración de la afinidad de zona al comportamiento del balanceador de carga, consulta la documentación sobre afinidad de zona.

Agrupación de nodos

La versión de GKE, las anotaciones del manifiesto de servicio y, en el caso de los servicios de balanceadores de carga internos, la opción Subconjunto de GKE determinan el balanceador de carga resultante y el tipo de back-ends. Trusted Cloud El balanceador de carga y el tipo de backend determinan cómo se agrupan los nodos en GCE_VM_IP grupos de puntos de conexión de red, grupos de instancias o grupos de destino. En cualquier circunstancia, Trusted Cloud los balanceadores de carga de transferencia identifican la interfaz de red (NIC) del nodo de GKE, no una dirección IP de un nodo o un pod concretos.

Servicio LoadBalancer de GKE	Balanceador de carga Trusted Cloud resultante	Método de agrupación de nodos
Servicio de balanceador de carga interno creado en un clúster con subconjuntos de GKE habilitados1	Un balanceador de carga de red de paso a través interno cuyo servicio de backend usa GCE_VM_IP backends de grupos de puntos finales de red (NEG)	Las VMs de nodo se agrupan por zonas en GCE_VM_IP NEGs en función del servicio y del externalTrafficPolicy del servicio, así como del número de nodos del clúster. El externalTrafficPolicy del servicio también controla qué nodos superan la comprobación del estado del balanceador de carga y el procesamiento de paquetes.
Servicio de balanceador de carga interno creado en un clúster con el subconjunto de GKE inhabilitado	Un balanceador de carga de red de paso a través interno cuyo servicio de backend usa backends de grupos de instancias no gestionados zonales	Todas las VMs de nodo se colocan en grupos de instancias no gestionados zonales que GKE usa como backends para el servicio de backend del balanceador de carga de red interno de transferencia. El externalTrafficPolicy del servicio controla qué nodos superan la comprobación del estado del balanceador de carga y el procesamiento de paquetes. Los mismos grupos de instancias sin gestionar se usan para otros servicios de backend de balanceadores de carga creados en el clúster debido a la limitación de un solo grupo de instancias balanceado de carga.
Servicio 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 de GKE o una posterior4	Un balanceador de carga de red de paso a través externo basado en un servicio de backend cuyo servicio de backend usa backends de grupo de puntos finales de red (NEG) GCE_VM_IP	Las VMs de nodo se agrupan por zonas en GCE_VM_IP NEGs en función del servicio y del externalTrafficPolicy del servicio, así como del número de nodos del clúster. El externalTrafficPolicy del servicio también controla qué nodos superan la comprobación del estado del balanceador de carga y el procesamiento de paquetes.
Servicio 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.16520004	Un balanceador de carga de red de paso a través externo basado en un servicio de backend cuyo servicio de backend usa backends de grupos de instancias no gestionados zonales	Todas las VMs de nodo se colocan en grupos de instancias no gestionados zonales que GKE usa como backends para el servicio de backend del balanceador de carga de red de pases externo. El externalTrafficPolicy del servicio controla qué nodos superan la comprobación del estado del balanceador de carga y el procesamiento de paquetes. Los mismos grupos de instancias sin gestionar se usan para otros servicios de backend de balanceadores de carga creados en el clúster debido a la limitación de un solo grupo de instancias balanceado de carga.
Servicio LoadBalancer externo sin la anotación cloud.google.com/l4-rbs: "enabled"3	Un balanceador de carga de red de paso a través externo basado en grupos de destino cuyo grupo de destino contiene todos los nodos del clúster	El grupo de destino es una API antigua que no depende de los grupos de instancias. Todos los nodos son miembros directos del grupo de destino. El externalTrafficPolicy del servicio controla qué nodos superan la comprobación del estado del balanceador de carga y el procesamiento de paquetes.

Miembros de nodos en backends de NEG de GCE_VM_IP

Cuando se habilita la creación de subconjuntos de GKE en un clúster o se crean balanceadores de carga de red de pases externos con cloud.google.com/l4-rbs: "enabled" en GKE 1.32.2-gke.1652000 o versiones posteriores, GKE crea un NEG GCE_VM_IP único en cada zona para cada servicio 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 carga. El externalTrafficPolicy del servicio y el número de nodos del clúster determinan qué nodos se añaden como puntos finales a los NEGs GCE_VM_IP del servicio.

El plano de control del clúster añade nodos como endpoints a los NEGs GCE_VM_IP según el valor de externalTrafficPolicy del servicio y el número de nodos del clúster, tal como se resume en las siguientes tablas.

Nodos de balanceadores de carga de red de paso a través internos

externalTrafficPolicy	Número de nodos del clúster	Endpoint membership
Cluster	De 1 a 25 nodos	GKE usa todos los nodos del clúster como puntos finales de los NEG del servicio, aunque un nodo no contenga un pod de servicio para el servicio.
Cluster	más de 25 nodos	GKE usa un subconjunto aleatorio de hasta 25 nodos como endpoints de los NEG del servicio, aunque un nodo no contenga un pod de servicio para el servicio.
Local	cualquier número de nodos1	GKE solo usa nodos que tienen al menos uno de los pods de servicio del servicio como puntos finales de los NEG del servicio.

Nodos de un balanceador de carga de red de paso a través externo

externalTrafficPolicy	Número de nodos del clúster	Endpoint membership
Cluster	De 1 a 250 nodos	GKE usa todos los nodos del clúster como puntos finales de los NEG del servicio, aunque un nodo no contenga un pod de servicio para el servicio.
Cluster	más de 250 nodos	GKE usa un subconjunto aleatorio de hasta 250 nodos como puntos finales de los NEG del servicio, aunque un nodo no contenga un pod de servicio para el servicio.
Local	cualquier número de nodos1	GKE solo usa nodos que tienen al menos uno de los pods de servicio del servicio como puntos finales de los NEG del servicio.

Limitación de un solo grupo de instancias con balanceo de carga

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

Cuando se usan back-ends de grupos de instancias sin gestionar, GKE crea o actualiza grupos de instancias sin gestionar que contienen todos los nodos de todos los grupos de nodos de cada zona que usa el clúster. Estos grupos de instancias sin gestionar se usan para lo siguiente:

• Balanceadores de carga de red de paso a través internos creados para servicios LoadBalancer internos cuando la creación de subconjuntos de GKE está inhabilitada.
• Balanceadores de carga de red de paso a través externos basados en servicios de backend creados para servicios LoadBalancer externos con la anotación cloud.google.com/l4-rbs: "enabled".
• Balanceadores de carga de aplicaciones externos creados para recursos de entrada de GKE externos, que usan el controlador de entrada de GKE, pero no el balanceo de carga nativo de contenedor.

Como las VMs de nodo no pueden pertenecer a más de un grupo de instancias con balanceo de carga, GKE no puede crear ni gestionar balanceadores de carga de red de paso a través internos, balanceadores de carga de red de paso a través externos basados en servicios de backend ni balanceadores de carga de aplicaciones externos creados para recursos Ingress de GKE si se cumple alguna de las siguientes condiciones:

• Fuera de GKE, has creado al menos un balanceador de carga basado en servicios de backend y has usado los grupos de instancias gestionados del clúster como backends del servicio de backend del balanceador de carga.
• Fuera de GKE, puedes crear un grupo de instancias no gestionado personalizado que contenga algunos o todos los nodos del clúster y, a continuación, adjuntar ese grupo de instancias no gestionado personalizado a un servicio de backend de un balanceador de carga.

Para evitar esta limitación, puedes indicar a GKE que use back-ends de NEG siempre que sea posible:

• Habilita la creación de subconjuntos de GKE. Por lo tanto, los nuevos servicios LoadBalancer internos usan GCE_VM_IP NEG.
• Configura recursos de Ingress de GKE externos para usar el balanceo de carga nativo de contenedores. Para obtener más información, consulta Balanceo de carga nativo de contenedores de GKE.

Comprobaciones del estado del balanceador de carga

Todos los servicios LoadBalancer de GKE implementan una comprobación de estado del balanceador de carga. El sistema de comprobación del estado del balanceador de carga funciona fuera del clúster y es diferente de una sonda de preparación, de actividad o de inicio de un pod.

Los paquetes de comprobación de estado del balanceador de carga se responden con el software kube-proxy (plano de datos antiguo) o cilium-agent (plano de datos de GKE V2) que se ejecuta en cada nodo. Los pods no pueden responder a las comprobaciones de estado del balanceador de carga de los servicios LoadBalancer.

El externalTrafficPolicy del servicio determina qué nodos superan la comprobación del estado del balanceador de carga. Para obtener más información sobre cómo usa el balanceador de carga la información de comprobación del estado, consulta Distribución del tráfico.

externalTrafficPolicy	Qué nodos superan la comprobación del estado	Qué puerto se usa
Cluster	Todos los nodos del clúster superan la comprobación de estado, incluidos los nodos sin pods de servicio. Si hay al menos un pod de servicio en un nodo, ese nodo supera la comprobación del estado del balanceador de carga, independientemente del estado de su pod.	El puerto de comprobación del estado del balanceador de carga debe ser el puerto TCP 10256. No se puede personalizar.
Local	La comprobación del estado del balanceador de carga considera que un nodo está en buen estado si hay al menos un pod de servicio listo y no finalizado en el nodo, independientemente del estado de cualquier otro pod. Los nodos sin un pod de servicio, los nodos cuyos pods de servicio no superan las comprobaciones de disponibilidad y los nodos cuyos pods de servicio están terminando no superan la comprobación de estado del balanceador de carga. Durante las transiciones de estado, un nodo sigue superando la comprobación de estado del balanceador de carga hasta que se alcanza el umbral de comprobación de estado incorrecto del balanceador de carga. El estado de transición se produce cuando todos los pods de servicio de un nodo empiezan a fallar en las comprobaciones de disponibilidad o cuando todos los pods de servicio de un nodo están finalizando. La forma en que se procesa el paquete en esta situación depende de la versión de GKE. Para obtener más información, consulta la siguiente sección, Procesamiento de paquetes.	El plano de control de Kubernetes asigna el puerto de comprobación del estado del intervalo de puertos de nodo, a menos que especifiques un puerto de comprobación del estado personalizado.

Cuando el balanceo de carga ponderado está habilitado, el balanceador de carga usa la información sobre el estado y el peso para identificar el conjunto de back-ends de nodos aptos. Para obtener más información, consulta Efecto del balanceo de carga ponderado.

Cuando la afinidad zonal está habilitada, el balanceador de carga 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 explica cómo funcionan el balanceador de carga y los nodos del clúster para enrutar los paquetes recibidos por los servicios LoadBalancer.

Balanceo de carga de tipo Pasarela

Los balanceadores de carga de red con paso a través enrutan los paquetes a la interfaz nic0 de los nodos del clúster de GKE. Cada paquete balanceado de carga 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 carga.
• El protocolo y el puerto de destino del paquete coinciden con ambos:
  • Un protocolo y un puerto especificados en spec.ports[] del manifiesto de Service
  • Un protocolo y un puerto configurados en la regla de reenvío del balanceador de carga

Traducción de direcciones de red de destino en nodos

Una vez que el nodo recibe el paquete, realiza un procesamiento adicional del paquete. En los clústeres de GKE que usan el plano de datos antiguo, los nodos usan iptables para procesar los paquetes con balanceo de carga. En los clústeres de GKE con GKE Dataplane V2 habilitado, los nodos usan eBPF. El procesamiento de paquetes a nivel de nodo siempre incluye las siguientes acciones:

• El nodo realiza la traducción de direcciones de red de destino (DNAT) en el paquete y establece su dirección IP de destino en la dirección IP de un pod de servicio.
• El nodo cambia el puerto de destino del paquete al targetPort del spec.ports[] del servicio 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 ha recibido los paquetes con balanceo de carga realiza la traducción de direcciones de red de origen (SNAT) antes de enviar los paquetes con balanceo de carga a un pod:

externalTrafficPolicy	Comportamiento de SNAT
Cluster	En los clústeres de GKE que usan el plano de datos antiguo, cada nodo que recibe paquetes balanceados de carga siempre cambia la dirección IP de origen de esos paquetes para que coincida con la dirección IP del nodo, independientemente de si el nodo enruta los paquetes a un pod local o a un pod de otro nodo. En los clústeres de GKE que usan GKE Dataplane V2, cada nodo que ha recibido paquetes balanceados de 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 de un nodo diferente. Si el nodo que ha recibido los paquetes con carga equilibrada los enruta a un pod local, el nodo no cambia la dirección IP de origen de esos paquetes.
Local	Cada nodo que ha recibido paquetes con balanceo de carga enruta los paquetes 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 la forma en que los nodos enrutan los paquetes con carga equilibrada y los paquetes de respuesta:

externalTrafficPolicy	Enrutamiento de paquetes con balanceo de carga	Enrutamiento de paquetes de respuesta
Cluster	A continuación, se describe el comportamiento de referencia para enrutar paquetes con balanceo de carga: Si el nodo que ha recibido los paquetes balanceados de carga no tiene un pod activo, listo y no finalizado, ese nodo enruta los paquetes a otro nodo que sí tenga un pod activo, listo y no finalizado. Si el nodo que ha recibido los paquetes balanceados de carga tiene un pod activo, listo y no finalizado, el nodo puede enrutar los paquetes a: Un Pod local. Un nodo diferente que tenga un pod de servicio, listo y no finalizado. En los clústeres regionales, si el nodo que ha recibido paquetes balanceados de carga ruta los paquetes a otro nodo, la afinidad de zona 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 ha recibido los paquetes con balanceo de carga intenta enrutar los paquetes a otro nodo de la misma zona. Si no es posible, el nodo diferente puede estar en cualquier zona. Como último recurso, si no hay pods activos, listos y no finalizados para el servicio en todos los nodos del clúster, ocurre lo siguiente: Si los endpoints de finalización de proxy están habilitados1, el nodo que ha recibido paquetes balanceados de carga los enruta a un pod de servicio, pero de finalización si es posible. Si los endpoints de finalización de proxy están inhabilitados o no hay ningún pod en todo el clúster, el nodo que haya recibido paquetes balanceados de carga cerrará la conexión con un restablecimiento de TCP.	Los paquetes de respuesta siempre se envían desde un nodo mediante la devolución directa del servidor: Si el nodo con el pod de servicio no es el nodo que ha recibido los paquetes correspondientes con balanceo de carga, el nodo de servicio envía los paquetes de respuesta al nodo receptor. A continuación, el nodo receptor envía los paquetes de respuesta mediante la devolución directa del servidor. Si el nodo con el pod de servicio es el nodo que ha recibido los paquetes balanceados de carga, ese nodo envía los paquetes de respuesta mediante retorno directo del servidor.
Local	A continuación, se describe el comportamiento de referencia para enrutar paquetes con balanceo de carga: el nodo que recibe paquetes con balanceo de carga suele tener un pod activo, listo y no finalizado (porque es necesario tener un pod de este tipo para superar la comprobación del estado del balanceador de carga). El nodo enruta los paquetes con balanceo de carga a un pod local. En los clústeres regionales, la afinidad de zona no cambia el comportamiento de referencia para enrutar paquetes balanceados de carga. Como último recurso, si no hay pods de servicio, listos y no finalizados en el nodo que ha recibido paquetes con balanceo de carga, ocurre lo siguiente: Si la opción Proxy Terminating Endpoints está habilitada1, el nodo que ha recibido los paquetes balanceados de carga los dirige a un pod de servicio local, pero de terminación si es posible. Si la opción Proxy Terminating Endpoints está inhabilitada o el nodo que ha recibido los paquetes balanceados de carga no tiene ningún pod de servicio, ese nodo cierra la conexión con un restablecimiento de TCP.	El nodo con el pod de servicio siempre es el nodo que ha recibido los paquetes balanceados de carga, y ese nodo envía los paquetes de respuesta mediante la devolución directa del servidor.

Cuotas

El número de reglas de reenvío que puedes crear se controla mediante las cuotas de balanceadores de carga:

• Los balanceadores de carga de red de paso a través internos usan la cuota de servicios de backend por proyecto, la cuota de comprobaciones de estado por proyecto y la cuota de reglas de reenvío de balanceadores de carga de red de paso a través internos por red de nube privada virtual.
• Los balanceadores de carga de red de paso a través externos basados en el servicio de backend usan la cuota de servicios de backend por proyecto, la cuota de comprobaciones del estado por proyecto y la cuota de reglas de reenvío de balanceadores de carga de red de paso a través externos por proyecto.
• Los balanceadores de carga de red de paso a través externos basados en grupos de destino usan la cuota de grupos de destino por proyecto, la cuota de comprobaciones del estado por proyecto y la cuota de reglas de reenvío de balanceadores de carga de red de paso a través externos por proyecto.

Siguientes pasos

• Consulta información sobre los parámetros del servicio LoadBalancer de GKE.
• Consulta información sobre los servicios de Kubernetes.