En esta página, se describen los parámetros para manifiestos de Services que controlan el comportamiento y la configuración de Services LoadBalancer. Antes de leer esta página, 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. El balanceador de cargas usa backends de NEG Para obtener más información, consulta Agrupación de nodos . |
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. El balanceador de cargas usa backends de NEG Para obtener más información, consulta Agrupación de nodos . |
GKE 1.25.5 | ||
| Balanceo de cargas ponderado | networking.gke.io/weighted-load-balancing: "pods-per-node"
Permite que los nodos que tienen más Pods de servicio reciban una mayor proporción de conexiones nuevas en comparación con los nodos que tienen menos Pods de servicio. |
GKE 1.31.0 o versiones posteriores | ||
| Política de tráfico interno | spec.internalTrafficPolicy
Cuando se configura como 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 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). | ||
| Afinidad zonal (versión preliminar) | spec.trafficDistribution
Habilita la afinidad zonal para los Services LoadBalancer internos. La afinidad zonal controla la zona a la que el balanceador de cargas de red de transferencia interno enruta el tráfico entrante para los clientes compatibles cuando es posible una coincidencia zonal. Para usar la afinidad zonal, debes habilitar la subdivisión de GKE. Para obtener más información, consulta Afinidad zonal y distribución del tráfico. |
GKE 1.33.3-gke.1392000 o posterior | ||
| 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 |
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 |
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. |
|
||
| 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 |
GKE 1.19 y versiones posteriores. | ||
| Subred personalizada |
|
(solo se aplica a IPv6) |
|
|
| 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 | GKE configura de forma automática la regla de reenvío para usar todos los puertos si se especifican más de cinco puertos únicos (hasta 100) en |
Versión de GKE 1.18.19-gke.1400 o posterior | ||
| ipFamilyPolicy |
Define cómo GKE asigna direcciones IP a un Service.
Puedes definir 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) |
Define la familia de direcciones IP para asignar Services de pila única o doble. Usa cualquiera de los siguientes valores:
|
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 , 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 |
Local |
Puedes seleccionar un puerto personalizado con |
Reglas de firewall y lista de entidades permitidas de direcciones IP de origen
A menos que hayas configurado un clúster para omitir la creación de reglas de firewall de VPC para los servicios de LoadBalancer, GKE crea una regla de firewall de VPC de permiso de entrada para cada Service.
Cada regla de firewall creada automáticamente 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 Cloudsignifican 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 configura las reglas de firewall para los Services LoadBalancer estableciendo de forma explícita el parámetro de destino en la dirección IP virtual del balanceador de cargas (la regla de reenvío del balanceador de cargas).
- GKE establece el parámetro de destino de la regla de firewall para incluir todos los nodos del clúster.
- 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. Además, GKE configura rutas y reglas dentro del sistema operativo del nodo para limitar las direcciones IP de origen del tráfico balanceado por carga, conkube-proxyyiptables(plano de datos heredado) ocilium-agenty reglas de eBPF (GKE Dataplane V2). Si el objeto Service no incluyeloadBalancerSourceRanges[], GKE establece el parámetro de origen de la regla de firewall en todas las direcciones IP(0.0.0.0/0).
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
|
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:
|
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 individuales o se pueden configurar para usar todos los puertos. Cuando un Service LoadBalancer interno tiene más de cinco Las reglas de reenvío con la misma dirección IP y el mismo protocolo no pueden tener puertos superpuestos. Esto significa que no puedes crear varios objetos Service de tipo Internal LoadBalancer que compartan la misma dirección IP, el mismo protocolo y los mismos puertos. Por ejemplo:
Para obtener más información, consulta Reglas de reenvío de balanceador de cargas de red de transferencia interno que usan una dirección IP común. |
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 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 |
| 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 predeterminado del proyecto es Premium, a menos que lo hayas configurado de manera diferente. |
Reserva de direcciones IP
GKE no reserva las direcciones IP estáticas configuradas con la anotación spec.loadBalancerIP o networking.gke.io/load-balancer-ip-addresses.
Esto significa que la dirección IP que asignes a tu Service se puede liberar cuando se borre el Service.
Para mantener reservada la dirección IP, debes crear manualmente un recurso de dirección en tu proyecto. La dirección IP estática debe tener los siguientes atributos:
- Debe ser solo regional.
- Estar en la misma región que el clúster
- Estar en el mismo nivel de servicio de red que el servicio LoadBalancer
- Tener un nombre que no use el nombre de LoadBalancer, prefijos como
k8s-o el UUID del servicio
Si no reservas la dirección por tu cuenta, los registros del proyecto pueden contener entradas sobre los recursos de direcciones creados y quitados poco después. Esto forma parte del aprovisionamiento normal del servicio y es algo que se debe esperar.
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 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:
|
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
|
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 proviene de 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
|
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:
- Acceso del cliente en la documentación del balanceador de cargas de red de transferencia interno
- Balanceadores de cargas de red de transferencia internos y redes conectadas
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 GKE, un Service Internal LoadBalancer solo puede admitir hasta 100 puertos en el spec.ports[].port del Service. Si un objeto Service de tipo Internal LoadBalancer define hasta cinco puertos, la regla de reenvío incluirá esos puertos específicos. Sin embargo, si el servicio especifica más de cinco puertos, la regla de reenvío se configurará automáticamente para que coincida con todos los puertos. Cuando configuras una regla de reenvío para 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 los objetos Service LoadBalancer internos, debes tener habilitada la subdivisión de GKE. Para obtener más información, consulta Subdivisión del balanceador de cargas interno.
- Para los objetos Service LoadBalancer externos, debes usar un balanceador de cargas de red de transferencia externo basado en servicios de backend. Para obtener más información, consulta Balanceador de cargas de red externo basado en servicios de backend.
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 ipFamiliesIPv4, pero no conIPv6. - Un Service con ipFamilies
["IPv6","IPv4"]se puede cambiar a uno con ipFamiliesIPv6, pero no conIPv4.
- Un Service con ipFamilies