Parámetros de Services LoadBalancer

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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, debes familiarizarte 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
Balanceadores de cargas TCP/UDP internos networking.gke.io/load-balancer-type: "Internal"

Indica a GKE que cree un balanceador de cargas TCP/UDP interno.

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

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

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

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

GKE 1.24+
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 relevante cuando spec.externalTrafficPolicy es 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.
Dirección IP estática spec.loadBalancerIP

Especifica una dirección IP estática asignada a la regla de reenvío del balanceador de cargas.

Todas las versiones compatibles.
Niveles de servicio de red metadata:annotations: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: SUBNET_NAME

Especifica una subred en la red de VPC y la región del clúster que se usará para la dirección IP de la regla de reenvío del balanceador de cargas TCP/UDP interno.

Vista previa en GKE 1.17+ y 1.16.8-gke.10+. Disponibilidad general en GKE 1.17.9-gke.600+
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

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 externo o un balanceador de cargas TCP/UDP 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 para las etiquetas de destino asignadas a 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. 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 los paquetes que coinciden con el protocolo y los puertos de destino de ese objeto Service en todas las siguientes direcciones IP de destino:

  • Todas las direcciones IP del Pod en el clúster, y
  • Todas las direcciones IP del nodo en el clúster, y
  • Todas las direcciones IP de las reglas de reenvío de cualquiera de los objetos Service de tipo LoadBalancer del clúster.

Aunque las reglas de firewall no limitan los destinos de las direcciones IP, las siguientes condiciones limitan el comportamiento del tráfico:

  • Las reglas de reenvío creadas para los objetos Service de tipo LoadBalancer solo enrutan paquetes si esos paquetes coinciden con el protocolo de la regla de reenvío, la dirección IP de destino y los puertos.
  • Los nodos rechazan los paquetes, a menos que coincidan con una combinación válida de dirección IP y puerto. Las combinaciones válidas de direcciones IP y puertos son las siguientes:

    • Una dirección IP del Pod y un containerPort para un contenedor de ese Pod.
    • Una dirección IP de nodo y un nodePort.
    • Una dirección IP de la regla de reenvío y el spec.ports[].port del objeto Service de tipo LoadBalancer.
  • Las políticas de red te permiten personalizar aún más la forma en que los nodos permiten o rechazan los paquetes.

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).

Dirección IP estática

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. Esto garantiza que la dirección IP del balanceador de cargas permanezca igual, incluso si realizas cambios en el Service LoadBalancer. Sin esta anotación, la dirección IP que GKE asigna a la regla de reenvío de un balanceador de cargas de red externo o un balanceador de cargas TCP/UDP interno puede cambiar cuando actualizas un Service LoadBalancer.

A fin de mantener una dirección IP coherente, puedes especificar una dirección IPv4 estática para uno o más objetos Service de tipo LoadBalancer mediante el parámetro spec.loadBalancerIP.

Cuando dos o más Services LoadBalancer hacen referencia a la misma spec.loadBalancerIP, cada Service LoadBalancer debe usar una combinación única de protocolos y puertos según estas reglas:

Interno Externo
Regla de reenvío La regla de reenvío para un balanceador de cargas TCP/UDP interno debe usar una combinación única de dirección IP interna, protocolo y puerto. La regla de reenvío de un balanceador de cargas de red externo debe usar una combinación única de dirección IP externa, protocolo y rango de puertos.
Intervalo de puerto

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 TCP/UDP 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.

El rango de puertos incluye todos los puertos que necesita el Service, pero a menudo también puede incluir más números de puertos que no usa el Service.

Por ejemplo, un Service LoadBalancer externo alimentado por un balanceador de cargas de red externo basado en grupos de destino que especifica los puertos 80 y 443 en su manifiesto de Service debe usar una regla de reenvío que asigne el rango de puertos de 80-443. Este rango de puertos evita que otros Services LoadBalancer externos usen cualquiera de los puertos entre el 80 y el 443.

Región de la dirección IP estática El balanceador de cargas TCP/UDP interno requiere una dirección IPv4 interna regional en la misma región que el clúster. El balanceador de cargas de red externo requiere una dirección IPv4 externa regional en la misma región que el clúster.
Niveles de servicio de red de direcciones IP estáticas No configurable porque todas las direcciones internas son del nivel Premium.

La dirección IP externa estática que reservas para la regla de reenvío del balanceador de cargas de red externo debe usar el mismo nivel que se especifica en la anotación metadata:annotations:cloud.google.com/network-tier del manifiesto del Service.

Si la anotación metadata:annotations:cloud.google.com/network-tier no está presente, la dirección IP externa estática que reservas para la regla de reenvío del balanceador de cargas de red externo debe usar el nivel predeterminado del proyecto (Premium, a menos que se configure de manera diferente).

Requisitos adicionales de las direcciones IP estáticas La dirección IP interna estática que reservas para la regla de reenvío del balanceador de cargas TCP/UDP interno debe tener un propósito SHARED_LOADBALANCER_VIP y provenir de uno de los siguientes rangos de direcciones IP de subred:
  • Si el manifiesto del Service especifica una subred personalizada con la anotación networking.gke.io/internal-load-balancer-subnet, la dirección IP interna estática que reservas debe provenir del rango de direcciones IPv4 principal de esa subred personalizada.
  • Si el controlador de servicio no especifica ninguna subred personalizada, la dirección IP interna estática que reservas debe provenir del rango de direcciones IPv4 principal de la subred del clúster.
No aplicable

Subred personalizada

Para los Services LoadBalancer internos, puedes especificar cualquier subred existente, en la misma red de VPC y región que el clúster, mediante la anotación networking.gke.io/internal-load-balancer-subnet:

   metadata:annotations: networking.gke.io/internal-load-balancer-subnet: SUBNET_NAME

GKE selecciona una dirección IPv4 interna para la regla de reenvío del balanceador de cargas a partir del rango de direcciones IPv4 principal de la subred especificada. Para obtener más información, consulta las reglas de reenvío del balanceador de cargas de TCP/UDP interno.

Crear la regla de reenvío del balanceador de cargas en una subred diferente es útil en los siguientes casos:

  • Separar la dirección IP del balanceador de cargas del rango de direcciones IP para los nodos es útil en las opciones de configuración de firewall de salida aplicables a los clientes que se conectan a los Services y nodos del clúster.

  • Agrupar Services de uno o más clústeres en la misma red de VPC y región en un rango de direcciones IP común.

Cuando especificas un Service LoadBalancer interno sin la anotación networking.gke.io/internal-load-balancer-subnet, GKE selecciona la dirección IP del balanceador de cargas del rango de direcciones IPv4 principal de la subred del clúster. La regla de reenvío del balanceador de cargas y los nodos del clúster usan el mismo rango de direcciones IPv4 principal de la subred.

Puedes crear una subred personalizada para los balanceadores de cargas internos en las siguientes versiones de GKE:

  • Vista previa en GKE 1.17 o superior y 1.16.8-gke.10 o superior
  • Disponibilidad general en GKE 1.17.9-gke.600+

Para obtener más información sobre cómo asignar una dirección IP estática dentro del rango de direcciones IPv4 principal de una subred, consulta Dirección IP estática.

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 TCP/UDP 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 TCP/UDP 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 cómo el acceso global se aplica a los clientes en una red conectada, consulta lo siguiente:

Todas las reglas de reenvío de puertos

Las reglas de reenvío para balanceadores de cargas TCP/UDP 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 TCP/UDP interno a fin de 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 TCP/UDP interno y las especificaciones de puertos válidas, consulta Reglas de reenvío y especificaciones de puertos.