Parámetros de Services LoadBalancer


En este documento, se describen los parámetros para manifiestos de Services que controlan el comportamiento y la configuración de Services LoadBalancer. Antes de leer este documento, asegúrate de estar familiarizado con los conceptos de Services LoadBalancer de Google Kubernetes Engine (GKE).

Parámetros de servicio

GKE admite los siguientes parámetros para los Services LoadBalancer.

Parámetro Campo y descripción del Service Interno Externo Compatibilidad con las versiones
Balanceador de cargas de red de transferencia interno networking.gke.io/load-balancer-type: "Internal"

Indica a GKE que cree un balanceador de cargas de red de transferencia interno.

Para obtener más detalles, consulta los conceptos de Services LoadBalancer.

Todas las versiones compatibles.
Balanceador de cargas de red de transferencia externo basado en servicios de backend cloud.google.com/l4-rbs: "enabled"

Indica a GKE que cree un balanceador de cargas de red de transferencia externo basado en servicios de backend.

Para obtener más detalles, consulta los conceptos de Services LoadBalancer.

GKE 1.25.5+
Política de tráfico interno spec.internalTrafficPolicy

Cuando se configura como Local, GKE solo enruta paquetes de Pods cliente en un nodo a Pods de entrega en el mismo nodo. Cuando se configura como Cluster, GKE enruta los paquetes desde los Pods cliente en un nodo a los Pods de entrega en cualquier nodo. Para obtener más detalles, consulta la Política de tráfico interno del servicio.

Este parámetro no es compatible con clústeres que ejecutan GKE Dataplane V2.

GKE 1.22+
Política de tráfico externo spec.externalTrafficPolicy

Controla cuáles VM del nodo pasan las verificaciones de estado del balanceador de cargas y cómo se enrutan los paquetes a los Pods que están listos y en funcionamiento en el clúster. También controla cómo los nodos se agrupan en los NEG GCE_VM_IP cuando la subdivisión de GKE está habilitada.

Para obtener más detalles, consulta los conceptos de Services LoadBalancer.

GKE 1.14+ (1.23.4-gke.400+ para el grupo de nodos de Windows).
Puerto de verificación de estado spec.healthCheckNodePort

Implementa una verificación de estado del balanceador de cargas para los objetos Service de tipo LoadBalancer. Este parámetro solo es válido si spec.externalTrafficPolicy se configura como Local.

Todas las versiones compatibles.
Reglas de firewall y lista de direcciones IP de origen permitidas spec.loadBalancerSourceRanges

Configura reglas de firewall opcionales en GKE y en la red de VPC para permitir solo ciertos rangos de origen.

Todas las versiones compatibles.
Direcciones IP estáticas
  • spec.loadBalancerIP (solo IPv4)
  • networking.gke.io/load-balancer-ip-addresses

Especifica una dirección IPv4 estática, un rango de direcciones IPv6 estáticas o ambos, que se asignan a las reglas de reenvío del balanceador de cargas. Consulta Consideraciones para compartir una dirección IP común a fin de obtener información sobre los requisitos de configuración importantes y los detalles de implementación.

  • spec.loadBalancerIP: Todas las versiones compatibles.
  • networking.gke.io/load-balancer-ip-addresses: GKE 1.29 y versiones posteriores. Consulta Parámetros de direcciones IP estáticas para obtener requisitos adicionales de configuración o de anotación de clústeres.
Niveles de servicio de red cloud.google.com/network-tier

Especifica qué niveles de servicio de red usa GKE para la regla de reenvío externa y la dirección IP. Los valores válidos de anotación son Standard y Premium (configuración predeterminada).

GKE 1.19 y versiones posteriores.
Subred personalizada
  • networking.gke.io/internal-load-balancer-subnet
  • networking.gke.io/load-balancer-subnet

(solo se aplica a IPv6)
  • networking.gke.io/internal-load-balancer-subnet: Todas las versiones compatibles
  • networking.gke.io/load-balancer-subnet: GKE 1.29 y versiones posteriores. Consulta Anotaciones de subredes personalizadas para obtener requisitos adicionales.
Acceso global networking.gke.io/internal-load-balancer-allow-global-access: "true"

Permite que los clientes de cualquier región de la red de VPC o una red conectada puedan acceder a la dirección IP de la regla de reenvío.

Vista previa en GKE 1.16+. Disponibilidad general en GKE 1.17.9-gke.600+.
Se reenvían todos los puertos

No se requiere anotación, pero la subdivisión de GKE debe estar habilitada.

GKE configura de forma automática la regla de reenvío para usar todos los puertos si se especifican al menos seis puertos únicos (hasta 100) en spec.ports[].port.

Versión de GKE 1.18.19-gke.1400 o posterior
ipFamilyPolicy

spec.ipFamilyPolicy

Define cómo GKE asigna direcciones IP a un Service. Puedes definir spec.ipFamilyPolicy como SingleStack, PreferDualStack o RequireDualStack.

Para obtener más información, consulta Services de pila doble de IPv4/IPv6.

Los clústeres de GKE en la versión 1.29 o posterior admiten la red de pila doble para los objetos Service de LoadBalancer.
ipFamilies (opcional)

spec.ipFamilies

Define la familia de direcciones IP para asignar Services de pila única o doble. Usa cualquiera de los siguientes valores:

  • IPv4 solo para el servicio IPv4 de pila única.
  • IPv6 solo para el servicio IPv6.
  • IPv4,IPv6 para el servicio de pila doble en el que la dirección IP principal del servicio es IPv4.
  • IPv6,IPv4 para el servicio de pila doble en el que la dirección IP principal del servicio es IPv6.
Los clústeres de GKE en la versión 1.29 o posterior admiten la red de pila doble para los objetos Service de LoadBalancer.

Puerto de verificación de estado

Como se describe en Verificaciones de estado del balanceador de cargas y externalTrafficPolicy, GKE siempre implementa una verificación de estado del balanceador de cargas cuando crea un balanceador de cargas de red de transferencia externo o un balanceador de cargas de red de transferencia interno.

Si puedes establecer el parámetro healthCheckNodePort o no depende de la siguiente configuración de externalTrafficPolicy:

externalTrafficPolicy Puerto de verificación de estado
Cluster

No puedes utilizar spec.healthCheckNodePort.

Local

Puedes seleccionar un puerto personalizado con spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de verificación de estado desde el rango de puertos del nodo.

Reglas de firewall y lista de entidades permitidas de direcciones IP de origen

Cuando creas un objeto Service de tipo LoadBalancer, GKE crea una regla de firewall de VPC correspondiente al objeto Service. Cada regla de firewall tiene las siguientes características:

  • La dirección de la regla de firewall es de entrada y su acción es permitir. Las reglas de firewall de denegación de entrada implícitas en Google Cloud significan que GKE usa un modelo de lista de entidades permitidas cuando se crean reglas de firewall de entrada.
  • GKE establece el protocolo y el puerto de destino de la regla de firewall en aquellos especificados en la lista spec.ports[] del objeto Service.
  • GKE establece el destino de la regla de firewall mediante la configuración de su parámetro de destino en la dirección IP virtual de LoadBalancer.
  • Si el objeto Service incluye spec.loadBalancerSourceRanges[], GKE establece el parámetro de origen de la regla de firewall en las direcciones IP de esa lista. Si el objeto Service no incluye loadBalancerSourceRanges[], GKE establece el parámetro de origen de la regla de firewall en todas las direcciones IP (0.0.0.0/0).

La regla de firewall creada para un objeto Service de tipo LoadBalancer permite paquetes, que coinciden con los puertos de destino y el protocolo de ese servicio, con la dirección IP virtual del servicio.

Objetos Service que usan puertos comunes

Cuando un clúster contiene dos o más objetos Service que comparten al menos un protocolo y un puerto de destino comunes, el conjunto efectivo de rangos de origen es la unión de loadBalancerSourceRanges para todos los objetos Service que especifican esa combinación de protocolo y puerto de destino. Esto se debe a que el parámetro objetivo de una regla de firewall de entrada define las direcciones IP de destino como todas las direcciones IP asociadas con una VM.

Considera un clúster que tiene dos objetos Service de tipo LoadBalancer:

  • El primer spec.ports[0].port de un objeto Service es el puerto TCP 80 y su spec.loadBalancerSourceRanges=[100.10.0.0/16]. El balanceador de cargas resultante correspondiente a este objeto Service tiene la dirección IP 192.0.2.2.
  • El segundo spec.ports[0].port del objeto Service es el puerto TCP 80, spec.ports[1].port es el puerto TCP 90 y su spec.loadBalancerSourceRanges=[172.16.0.0/24]. El balanceador de cargas resultante correspondiente a este objeto Service tiene la dirección IP 198.51.100.3.

GKE crea dos reglas de firewall ingress-allow en la red de nube privada virtual del clúster. Ambas reglas de firewall especifican todos los nodos del clúster como sus objetivos:

  • La primera regla de firewall permite los paquetes en el puerto de destino TCP 80 desde el valor 100.10.0.0/16 de origen.
  • La segunda regla de firewall permite los paquetes en los puertos de destino TCP 80 y 90 desde el valor 172.16.0.0/24 de origen.

La primera regla de reenvío enruta el tráfico que coincide con el destino 192.0.2.2:80. La segunda regla de reenvío enruta el tráfico que coincide con los destinos 198.51.100.3:80 y 198.51.100.3:90. Los siguientes tres valores son destinos válidos en cada nodo: 192.0.2.2:80, 198.51.100.3:80 y 198.51.100.3:90. Esto significa que:

  • Ambos objetos Service aceptan paquetes al puerto TCP 80 desde la unión de los rangos de origen de direcciones IP, ya sea 100.10.0.0/16 o 172.16.0.0/24.
  • El segundo objeto Service acepta paquetes para el puerto TCP 90 de 172.16.0.0/24.

El conjunto efectivo de rangos de origen para todos los objetos Service que usan la misma combinación de protocolo y puerto de destino se convierte en todas las direcciones IP si se omite spec.loadBalancerSourceRanges en al menos un objeto Service que usa esa combinación de protocolo y puerto de destino. Por ejemplo, si el segundo objeto Service omitiera spec.loadBalancerSourceRanges, la fuente del segundo firewall sería 0.0.0.0/0, y:

  • Ambos objetos Service aceptarían paquetes en el puerto TCP 80 de la unión de los rangos de origen de direcciones IP, ya sea 100.10.0.0/16 o 0.0.0.0/0. Debido a que el rango 0.0.0.0/0 incluye el rango 100.10.0.0/16, la fuente efectiva para los paquetes en el puerto TCP 80 es cualquier dirección IP.
  • El segundo Objeto Serive acepta paquetes en el puerto TCP 90 desde 0.0.0.0/0 (cualquier dirección IP).

Direcciones IP estáticas

Puedes crear una dirección IP estática y configurar GKE para que asigne esa dirección IP estática a la regla de reenvío del balanceador de cargas. El uso de una dirección IP estática garantiza que la dirección IP del balanceador de cargas permanezca igual, incluso si realizas cambios en el Service LoadBalancer. Sin una dirección IP estática, GKE podría asignar una dirección IP diferente a la regla de reenvío del balanceador de cargas cuando actualizas un objeto Service LoadBalancer. La dirección IP de la regla de reenvío no es la misma que la dirección spec.clusterIP del Service. La dirección ClusterIP de un Service nunca cambia cuando actualizas un Service LoadBalancer.

Parámetros de dirección IP estática

Para indicarle a un Service LoadBalancer que use una dirección IP estática, usa el parámetro spec.loadBalancerIP o la anotación networking.gke.io/load-balancer-ip-addresses. En la versión 1.29 de GKE y versiones posteriores, la anotación tiene prioridad sobre spec.loadBalancerIP si el manifiesto del Service contiene el parámetro y la anotación.

Parámetro o anotación y valor Requisitos y capacidades
spec.loadBalancerIP:
IPv4_ADDRESS

Puedes especificar una dirección IPv4 interna estática para un Service de LoadBalancer interno solo IPv4. Puedes especificar una dirección IPv4 externa estática para un objeto Service LoadBalancer externo solo IPv4. El parámetro funciona con todas las versiones de GKE compatibles.

networking.gke.io/load-balancer-ip-addresses:
IP_ADDRESS_RESOURCE_NAME
  • Para los Services LoadBalancer de pila única, establece el valor de la anotación como el nombre del recurso de dirección IPv4 o IPv6, no en la dirección IP en sí.
  • Para los Services LoadBalancer de doble pila, establece el valor de la anotación como el nombre del recurso de dirección IPv4 estática y el nombre del recurso del rango de direcciones IPv6 estático separados por una coma.

Puedes especificar direcciones IPv4 estáticas, un rango de direcciones IPv6 estáticas o ambos para Services LoadBalancer internos y externos de pila doble, solo IPv4 y solo IPv6. La anotación requiere GKE 1.29 o una versión posterior y los siguientes requisitos adicionales:

  • Para usar esta anotación con un Service LoadBalancer interno, debes crear el Service LoadBalancer interno en un clúster después de habilitar la subdivisión de GKE.
  • Para usar esta anotación con un Service LoadBalancer externo, debes incluir la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del Service cuando crees el Service LoadBalancer externo.

Consideraciones para compartir una dirección IP común

Dos o más Services LoadBalancer pueden hacer referencia a la misma dirección IP estática si la regla de reenvío para cada balanceador de cargas usa una combinación única de dirección IP, protocolo, especificación de puerto y especificación de Niveles de servicio de red, como se indica en la tabla de esta sección. Además:

  • Las direcciones IPv6 estáticas en realidad son rangos de direcciones IPv6 /96, pero GKE solo configura los nodos para que acepten paquetes en la primera dirección IPv6 (/128) en el rango /96.

  • Para que dos o más Service LoadBalancer internos usen la misma dirección IPv4 interna o el rango de direcciones IPv6 interno, la dirección IP estática debe crearse con el propósito SHARED_LOADBALANCER_VIP.

Service LoadBalancer interno Servicio LoadBalancer externo
Especificación de puerto

Las reglas de reenvío para balanceadores de cargas de red de transferencia internos admiten hasta cinco números de puerto discretos o se pueden configurar para usar todos los puertos.

Cuando un Service LoadBalancer interno tiene seis o más spec.ports[] especificados, GKE configura la regla de reenvío para que el balanceador de cargas de red de transferencia interno use todos los puertos.

Cuando una regla de reenvío usa todos los puertos, ninguna otra regla de reenvío (por lo tanto, ningún otro Service LoadBalancer interno) puede usar la misma dirección IP.

GKE crea un balanceador de cargas de red de transferencia externo basado en grupos de destino si el manifiesto del Service LoadBalancer no tiene la anotación cloud.google.com/l4-rbs: "enabled".

Las reglas de reenvío para balanceadores de cargas de red de transferencia externos basados en grupos de destino deben usar rangos de puertos contiguos. El rango de puertos contiguo incluye todos los puertos que necesita el Service, pero el rango también puede incluir puertos adicionales que el Service no usa. Por ejemplo, un Service LoadBalancer externo alimentado por un balanceador de cargas de red de transferencia externo basado en grupos de destino que especifica los puertos 80 y 443 en su manifiesto de Service usa una regla de reenvío del balanceador de cargas con un rango de puertos 80-443. Este rango de puertos evita que otros objetos Service LoadBalancer externos usen los puertos 80, 443 y cualquiera de los números entre el 80 y el 443.

GKE crea un balanceador de cargas de red de transferencia externo basado en servicios de backend si el manifiesto del Service LoadBalancer incluye la anotación cloud.google.com/l4-rbs: "enabled". Las reglas de reenvío para balanceadores de cargas de red de transferencia externos basados en servicios de backend admiten hasta cinco números de puerto discretos, un rango de puertos contiguo o se pueden configurar para usar todos los puertos.

Niveles de servicio de red No configurable: las direcciones internas siempre son de nivel Premium.

Configurable para direcciones IPv4 externas regionales estáticas. Los rangos de direcciones IPv6 externas regionales estáticas solo se pueden crear en el nivel Premium.

La especificación de los niveles de servicio de red de la dirección IP externa estática debe coincidir con una de las siguientes opciones:

  • El nivel especificado en la anotación cloud.google.com/network-tier del manifiesto del Service LoadBalancer, si esa anotación está presente en el manifiesto, o
  • El nivel predeterminado del proyecto, si la anotación cloud.google.com/network-tier está ausente en el manifiesto del Service LoadBalancer.

El nivel predeterminado del proyecto es Premium, a menos que lo hayas configurado de manera diferente.

Subred de LoadBalancer

Puedes configurar un Service LoadBalancer interno para usar una dirección IPv4 efímera o estática, un rango de direcciones IPv6 o ambos, en una subred personalizada ubicada en la misma región y red de VPC que el clúster. Usa una subred personalizada para un Service LoadBalancer interno a fin de realizar las siguientes acciones:

  • Agrupa los balanceadores de cargas de red de transferencia internos creados por los Services LoadBalancer internos de dos o más clústeres de GKE en la misma red de VPC y región.
  • Crea Services LoadBalancer internos cuyos balanceadores de cargas de red de transferencia internos tengan direcciones IPv4 separadas de las direcciones IPv4 del nodo del clúster.
  • En un clúster de pila doble, crea Services LoadBalancer internos cuyos balanceadores de cargas de red de transferencia internos tengan rangos de direcciones IPv6 separados de las direcciones IPv6 del nodo y del Pod del clúster. Es obligatoria una subred LoadBalancer personalizada para admitir Services LoadBalancer internos si la subred del clúster tiene un rango de direcciones IPv6 externas.

Puedes configurar un Service LoadBalancer externo para usar un rango de direcciones IPv6 efímeras o estáticas en una subred personalizada que se encuentre en la misma región y red de VPC que el clúster. Usa una subred personalizada para crear objetos Service LoadBalancer externos cuyos balanceadores de cargas de red de transferencia externos tienen rangos de direcciones IPv6 separados de las direcciones IPv6 del nodo y del Pod del clúster. Es obligatoria una subred LoadBalancer personalizada para admitir Services LoadBalancer externos en un clúster privado de pila doble porque la subred del clúster tiene un rango de direcciones IPv6 interno.

Anotaciones de subred personalizadas

Usa una de las siguientes anotaciones para indicarle a un Service LoadBalancer que use una dirección IP estática o efímera en una subred personalizada. Si un manifiesto de Service LoadBalancer incluye ambas anotaciones, la anotación networking.gke.io/load-balancer-subnet tiene prioridad siempre que se cumplan los requisitos de anotación.

Anotación y valor Requisitos y capacidades
networking.gke.io/internal-load-balancer-subnet:
SUBNET_RESOURCE_NAME

Solo puedes usar la anotación a fin de especificar una subred personalizada para un Service LoadBalancer interno solo IPv4. La anotación funciona con todas las versiones de GKE compatibles.

networking.gke.io/load-balancer-subnet:
SUBNET_RESOURCE_NAME

Puedes especificar una subred personalizada para un objeto Service LoadBalancer interno de solo IPv4, solo IPv6 o de pila doble. Puedes especificar una subred personalizada para un objeto Service LoadBalancer externo solo IPv6 o de pila doble. La anotación requiere GKE 1.29 o una versión posterior y los siguientes requisitos adicionales:

  • Si deseas usar esta anotación a fin de especificar una subred personalizada para un objeto Service LoadBalancer interno, debes crear el Service LoadBalancer interno en un clúster después de habilitar la subdivisión de GKE.
  • Si deseas usar esta anotación a fin de especificar una subred personalizada para un Service LoadBalancer externo, debes incluir la anotación cloud.google.com/l4-rbs: "enabled" en el manifiesto del Service cuando crees el Service LoadBalancer externo.

Subred y dirección IPv4 para un Service LoadBalancer interno

En la siguiente tabla, se describen las especificaciones de subred y las combinaciones de direcciones IPv4 válidas para un Service LoadBalancer interno solo IPv4 o de pila doble.

Dirección IPv4 estática Dirección IPv4 efímera
Subred personalizada
Subred personalizada y dirección IPv4 estática: la dirección IPv4 interna estática debe haberse creado en el rango de direcciones IPv4 principal de la subred personalizada. Subred personalizada y dirección IPv4 efímera: GKE usa una dirección IPv4 interna sin asignar en el rango de direcciones IPv4 principal de la subred personalizada.
Subred del clúster Subred del clúster y dirección IPv4 estática: La dirección IPv4 interna estática debe haberse creado en el rango de direcciones IPv4 principal de la subred del clúster. Subred del clúster y dirección IPv4 efímera: GKE usa una dirección IPv4 interna sin asignar en el rango de direcciones IPv4 principal de la subred del clúster.

Subred y rango de direcciones IPv6 para un Service LoadBalancer interno

En la siguiente tabla, se describen las combinaciones válidas de especificación de subred y rango de direcciones IPv6 para un Service LoadBalancer interno solo IPv6 o de pila doble. Aunque la regla de reenvío IPv6 del balanceador de cargas de red de transferencia interno usa un rango de direcciones IPv6 /96 interno, GKE solo configura nodos para aceptar paquetes cuyos destinos coincidan con la primera dirección IPv6 (/128) del rango /96 de la regla de reenvío.

Rango de direcciones IPv6 estáticas Rango de direcciones IPv6 efímero
Subred personalizada de pila doble
Subred personalizada y rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 internas /96 deben haberse creado en el rango de direcciones IPv6 interno /64 de la subred personalizada. Subred personalizada y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 internas /96 sin asignar del rango de direcciones IPv6 interno /64 de la subred personalizada.
Subred de pila doble del clúster
  • Debe tener un rango de direcciones IPv6 internas (tipo de acceso INTERNAL).
Subred del clúster y el rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 internas /96 deben haberse creado en el rango de direcciones IPv6 interno /64 de la subred del clúster. Subred del clúster y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 internas /96 no asignado del rango de direcciones IPv6 interno /64 de la subred del clúster.

Subred y dirección IPv4 para un Service LoadBalancer externo

Para los Services LoadBalancer externos de pila doble y solo IPv4, la dirección IPv4 externa (ya sea una dirección IPv4 externa estática o una dirección IPv4 externa efímera) no viene desde una subred.

Subred y rango de direcciones IPv6 para un Service LoadBalancer externo

En la siguiente tabla, se describen las combinaciones válidas de especificación de subred y rango de direcciones IPv6 para un Service LoadBalancer externo solo IPv6 o de pila doble. Aunque la regla de reenvío IPv6 del balanceador de cargas de red de transferencia externo usa un rango de direcciones IPv6 /96 externo, GKE solo configura nodos para aceptar paquetes cuyos destinos coincidan con la primera dirección IPv6 (/128) del rango /96 de la regla de reenvío.

Rango de direcciones IPv6 estáticas Rango de direcciones IPv6 efímero
Subred personalizada de pila doble
Subred personalizada y rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 externas estáticas /96 debe haberse creado en el rango de direcciones IPv6 externas /64 de la subred personalizada. Los rangos de direcciones IPv6 externas estáticas solo se pueden crear en el nivel Premium. Subred personalizada y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 externas /96 sin asignar del rango de direcciones IPv6 externas /64 de la subred personalizada.
Subred de pila doble del clúster
  • Debe tener un rango de direcciones IPv6 externas (tipo de acceso EXTERNAL).
Subred del clúster y rango de direcciones IPv6 estáticas: El rango de direcciones IPv6 externas estáticas /96 debe haberse creado en el rango de direcciones IPv6 externas /64 de la subred del clúster. Los rangos de direcciones IPv6 externas estáticas solo se pueden crear en el nivel Premium. Subred del clúster y rango de direcciones IPv6 efímeras: GKE usa un rango de direcciones IPv6 externas /96 sin asignar del rango de direcciones IPv6 externo /64 de la subred del clúster.

Acceso global

Cuando la anotación networking.gke.io/internal-load-balancer-allow-global-access es false o no se especifica para un Service LoadBalancer interno, GKE crea un balanceador de cargas de red de transferencia interno cuya regla de reenvío tiene inhabilitado el acceso global. Cuando el acceso global está inhabilitado, los clientes que necesitan acceder al balanceador de cargas deben estar ubicados en la misma región y red de VPC, o en una red conectada a la red de VPC del clúster.

Cuando la anotación networking.gke.io/internal-load-balancer-allow-global-access es true para un Service LoadBalancer interno, GKE habilita la opción de acceso global en la regla de reenvío del balanceador de cargas de red de transferencia interno. Los clientes ubicados en cualquier región de la red de VPC o una red conectada a la red de VPC del clúster pueden acceder al balanceador de cargas.

Para obtener más información sobre el acceso global a los clientes de una red conectada, consulta:

Todas las reglas de reenvío de puertos

Las reglas de reenvío para balanceadores de cargas de red de transferencia internos admiten cinco números de puerto únicos o todos los puertos.

En los clústeres de GKE con la subdivisión de GKE inhabilitada, un Service LoadBalancer interno solo puede admitir cinco puertos únicos en el spec.ports[].port del Service.

En los clústeres de GKE con la subdivisión de GKE habilitada, un Service LoadBalancer interno solo puede admitir hasta 100 puertos en el spec.ports[].port del Service. Para los Services LoadBalancer internos con entre seis y 100 entradas spec.ports[].port únicas, GKE configura la regla de reenvío del balanceador de cargas de red de transferencia interno para usar todos los puertos desde su creación. El controlador de GKE habilita todos los puertos en la regla de reenvío porque el Service tiene más de cinco puertos. Cuando configuras una regla de reenvío a fin de usar todos los puertos, GKE solo crea reglas de firewall de permiso de entrada para los puertos específicos configurados en spec.ports[].port en el Service.

Para obtener más información sobre las reglas de reenvío del balanceador de cargas de red de transferencia interno y las especificaciones de puertos válidas, consulta Reglas de reenvío y especificaciones de puertos.

Service LoadBalancer de pila doble IPv4/IPv6

Puedes crear un objeto Service LoadBalancer interno o externo que pueda ser de pila única (solo IPv4 o IPv6) o de pila doble. Los objetos Service LoadBalancer de pila única crean una sola regla de reenvío con una dirección IPv4 o IPv6. Los objetos Service LoadBalancer de doble pila crean dos reglas de reenvío: una con una dirección IPv4 y otra con una dirección IPv6. Para crear un Service LoadBalancer de pila doble IPv4/IPv6, impleméntalo en un clúster de pila doble de IPv4/IPv6 y completa cualquiera de las siguientes opciones según el tipo de balanceador de cargas que uses:

Para cada servicio, puedes definir las especificaciones ipFamilyPolicy y ipFamilies. Para obtener más información, consulta Pila doble de IPv4/IPv6.

Restricciones de Service LoadBalancer de pila doble

  • Los objetos Service LoadBalancer con direcciones IPv6 solo son compatibles con los clústeres con tipo de pila ipv4-ipv6. Si deseas obtener más información, consulta Usa una dirección IP de pila doble para un clúster nativo de la VPC.
  • Los objetos Service LoadBalancer creados con una dirección de pila única no se pueden actualizar a servicios de pila doble.

  • Los objetos Service LoadBalancer creados con direcciones de pila doble se pueden cambiar a una sola pila según las siguientes condiciones:

    • Un Service con ipFamilies ["IPv4","IPv6"] se puede cambiar a uno con ipFamilies IPv4, pero no con IPv6.
    • Un Service con ipFamilies ["IPv6","IPv4"] se puede cambiar a uno con ipFamilies IPv6, pero no con IPv4.