Usa un balanceador de cargas TCP/UDP interno

En esta página, se explica cómo crear un balanceador de cargas de TCP/UDP interno de Compute Engine en Google Kubernetes Engine.

Descripción general

El balanceo de cargas TCP/UDP interno permite que los servicios de tu clúster sean accesibles para las aplicaciones fuera de tu clúster que usan la misma red de VPC y se encuentran en la misma región de Google Cloud. Por ejemplo, supongamos que tienes un clúster en la región us-west1 y necesitas hacer que las instancias de VM de Compute Engine que se ejecutan en esa región en la misma red de VPC tengan acceso a uno de sus servicios.

Puedes crear un balanceador de cargas TCP/UDP interno si creas un recurso Servicio con la anotación cloud.google.com/load-balancer-type: "Internal" y la especificación type: LoadBalancer. Las instrucciones y el ejemplo a continuación destacan cómo hacer esto.

Sin el balanceo de cargas de TCP/UDP interno, tendrías que configurar un balanceador de cargas externo y reglas de firewall para que se pueda acceder a la aplicación fuera del clúster.

El balanceo de cargas de TCP/UDP interno crea una dirección IP interna para el Service que recibe tráfico de los clientes en la misma red de VPC y región de procesamiento. Si habilitas el acceso global, los clientes de cualquier región de la misma red de VPC pueden acceder al servicio. Además, los clientes en una red de VPC conectada a la red LoadBalancer mediante el Intercambio de tráfico entre redes de VPC también pueden acceder al servicio.

Precios

Se te cobrará por el modelo de precios de Compute Engine. Para obtener más información, consulta Precios de balanceos de cargas y de reglas de reenvío y la página de Compute Engine en la calculadora de precios de Google Cloud.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

  • Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

  1. Ejecuta gcloud init y sigue las instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

    gcloud init --console-only
  2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
  3. Crea una configuración nueva o selecciona una existente.
  4. Elige un proyecto de Google Cloud.
  5. Elige una zona predeterminada de Compute Engine.

Usa gcloud config

  • Establece tu ID del proyecto predeterminado:
    gcloud config set project project-id
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
    gcloud config set compute/zone compute-zone
  • Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
    gcloud config set compute/region compute-region
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Crea una implementación

En el siguiente manifiesto, se describe una implementación que ejecuta 3 réplicas de una aplicación de Hello World.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

El código fuente y Dockerfile para esta aplicación de muestra están disponibles en GitHub. Como no se especifica ninguna variable de entorno PORT, los contenedores escuchan en el puerto 8080 predeterminado.

Para crear la implementación, crea el archivo my-deployment.yaml desde el manifiesto y, luego, ejecuta el comando siguiente en tu shell o ventana de la terminal:

kubectl apply -f my-deployment.yaml

Crea un balanceador de cargas TCP interno

En las siguientes secciones, se explica cómo crear un balanceador de cargas TCP interno mediante el uso de un servicio.

Escribe el archivo de configuración del servicio

A continuación, se muestra un ejemplo de un servicio que crea un balanceador de cargas TCP interno:

apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    app: hello
spec:
  type: LoadBalancer
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Requisitos mínimos de servicio

El manifiesto debe contener las siguientes características:

  • Un name para el servicio, en este caso ilb-service.
  • La anotación: cloud.google.com/load-balancer-type: "Internal", que especifica que se debe configurar un balanceador de cargas TCP/UDP interno.
  • El tipo type: LoadBalancer.
  • Un campo spec: selector para especificar los pods a los que se orientará el servicio, por ejemplo, app: hello.
  • El port, el puerto sobre el que se expone el servicio, y targetPort, el puerto en el que escuchan los contenedores.

Implementa el servicio

Para crear un balanceador de cargas TCP interno, crea el archivo my-service.yaml desde el manifiesto y, luego, ejecuta el comando siguiente en tu shell o ventana de la terminal:

kubectl apply -f my-service.yaml

Inspecciona el servicio

Después de la implementación, inspecciona el servicio para verificar que se haya configurado correctamente.

Obtén información detallada sobre el servicio:

kubectl get service ilb-service --output yaml

En el resultado, puedes ver la dirección IP del balanceador de cargas interno en status.loadBalancer.ingress. Ten en cuenta que esto es diferente del valor de clusterIP. En este ejemplo, la dirección IP del balanceador de cargas es 10.128.15.193:

apiVersion: v1
kind: Service
metadata:
  ...
  labels:
    app: hello
  name: ilb-service
  ...
spec:
  clusterIP: 10.0.9.121
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30835
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: hello
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 10.128.15.193

Cualquier pod que tenga la etiqueta app: hello es miembro de este servicio. Estos son los pods que pueden ser los destinatarios finales de las solicitudes enviadas a tu balanceador de cargas interno.

Los clientes llaman al servicio mediante la dirección IP loadBalancer y el puerto TCP especificado en el campo port del manifiesto del servicio. La solicitud se reenvía a uno de los pods miembros en el puerto TCP especificado en el campo targetPort. En el ejemplo anterior, un cliente llama al servicio a la dirección IP 10.128.15.193 en el puerto TCP 80. La solicitud se reenvía a uno de los pods miembros en el puerto TCP 8080. Ten en cuenta que el pod miembro debe tener un contenedor que escuche en el puerto 8080.

El valor nodePort de 30835 es extraño. No es relevante para tu balanceador de cargas interno.

Visualiza la regla de reenvío del balanceador de cargas

Un balanceador de cargas interno se implementa como una regla de reenvío. La regla de reenvío tiene un servicio de backend, que tiene un grupo de instancias.

La dirección del balanceador de cargas interno, 10.128.15.193 en el ejemplo anterior, es la misma que la dirección de la regla de reenvío. Para ver la regla de reenvío que implementa tu balanceador de cargas interno, obtén una lista de todas las reglas de reenvío en tu proyecto:

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

En el resultado, busca la regla de reenvío que tiene la misma dirección que tu balanceador de cargas interno, 10.128.15.193 en este ejemplo.

NAME                          ... IP_ADDRESS  ... TARGET
...
aae3e263abe0911e9b32a42010a80008  10.128.15.193   us-central1/backendServices/aae3e263abe0911e9b32a42010a80008

El resultado muestra el servicio de backend asociado, ae3e263abe0911e9b32a42010a80008 en este ejemplo.

Describe el servicio de backend:

gcloud compute backend-services describe aae3e263abe0911e9b32a42010a80008 --region us-central1

El resultado muestra el grupo de instancias asociado, k8s-ig--2328fa39f4dc1b75 en este ejemplo:

backends:
- balancingMode: CONNECTION
  group: .../us-central1-a/instanceGroups/k8s-ig--2328fa39f4dc1b75
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

Cómo funciona la abstracción del servicio

Cuando una regla de reenvío maneja un paquete, este se reenvía a uno de los nodos del clúster. Estas son las direcciones y el puerto cuando el paquete lleva al nodo del clúster:

Dirección IP de destino Regla de reenvío, 10.128.15.193 en este ejemplo
Puerto TCP de destino Campo port del servicio, puerto 80 en este ejemplo

Ten en cuenta que la regla de reenvío (es decir, tu balanceador de cargas interno) no cambia la dirección IP o el puerto de destino. En cambio, las reglas de iptables en el nodo del clúster enrutan el paquete a un pod apropiado. Las reglas de iptables cambian la dirección IP de destino a una dirección IP del Pod y el puerto de destino al valor targetPort del servicio, puerto 8080 en este ejemplo.

Verifica el balanceador de cargas TCP interno

Establece una conexión SSH a una instancia de VM y ejecuta el siguiente comando:

curl load-balancer-ip

En el ejemplo anterior, load-balancer-ip es la dirección IP de LoadBalancer Ingress.

En la respuesta, se muestra la salida de hello-app:

Hello, world!
Version: 2.0.0
Hostname: hello-app-77b45987f7-pw54n

Ejecutar el comando por fuera de la misma red de VPC o por fuera de la misma región genera un error de tiempo de espera agotado. Si configuras el acceso global, los clientes de cualquier región de la misma red de VPC pueden acceder al balanceador de cargas.

Realiza una limpieza

Puedes borrar la implementación y el servicio con kubectl delete o Cloud Console.

kubectl

Borra la implementación

Para borrar la implementación, ejecuta el siguiente comando:

kubectl delete deployment hello-app

Borra el servicio

Para borrar el servicio, ejecuta el siguiente comando:

kubectl delete service ilb-service

Console

Borra la implementación

Para borrar la implementación, sigue estos pasos:

  1. Visita el menú Cargas de trabajo de Google Kubernetes Engine en Cloud Console.

    Visitar el menú Cargas de trabajo

  2. En el menú, selecciona la carga de trabajo deseada.

  3. Haz clic en Borrar.

  4. Haz clic en Borrar en el menú de diálogo de confirmación.

Borra el servicio

Para borrar el servicio, sigue estos pasos:

  1. Visita el menú de Servicios de Google Kubernetes Engine en Cloud Console.

    Visitar el menú Servicios.

  2. En el menú, selecciona el servicio deseado.

  3. Haz clic en Borrar.

  4. Haz clic en Borrar en el menú de diálogo de confirmación.

Consideraciones para los Ingress existentes

No puedes tener un balanceador de cargas TCP/UDP interno ni un Ingress que use el modo de balanceo UTILIZATION. Para usar tanto un Ingress como un balanceo de cargas TCP/UDP interno, el Ingress debe usar el modo de balanceo RATE.

Si tu clúster tiene un recurso de Ingress existente creado con Kubernetes versión 1.7.1 o una anterior, no es compatible con balanceadores de cargas TCP/UDP internos. Los recursos BackendService anteriores que crearon los objetos de recursos Ingress de Kubernetes se crearon sin especificación de modo de balanceo. Según la configuración predeterminada, la API usó el modo de balanceo UTILIZATION para los balanceadores de cargas de HTTP. Sin embargo, los balanceadores de cargas internos TCP/UDP no se pueden apuntar a grupos de instancias con otros balanceadores de carga mediante UTILIZATION.

Determina tu modo de balanceo de Ingress

Para determinar cuál es tu modo de balanceo de Ingress, ejecuta los siguientes comandos desde tu shell o ventana de la terminal:

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

Estos comandos exportan una variable de shell, GROUPNAME, que recupera el nombre del grupo de instancias de tu clúster. Luego, los recursos backend service de Compute Engine de tu proyecto se sondean y los resultados se reducen en función de los contenidos de $GROUPNAME.

El resultado es similar al siguiente:

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

Si el resultado muestra entradas RATE o no se muestra ninguna, los balanceadores de cargas internos son compatibles y no se necesita ninguna acción adicional.

Si el resultado muestra entradas marcadas con UTILIZATION, tus Ingress no son compatibles.

Para actualizar los recursos de Ingress y que sean compatibles con un balanceador de cargas TCP/UDP interno, puedes crear un clúster nuevo que ejecute la versión 1.7.2 de Kubernetes o superior y, luego, migrar tus servicios a ese clúster.

Parámetros de servicio

Los siguientes parámetros son compatibles con los servicios LoadBalancer internos de GKE.

Función Descripción general Campo de servicio Compatibilidad con la versión de GKE
Política de tráfico externo local Configura si el tráfico externo tiene balanceo de cargas en los nodos de GKE. spec:externalTrafficPolicy:Local GKE 1.14 o superior
Rangos de origen del balanceador de cargas Configura reglas de firewall opcionales en GKE y en la VPC para permitir solo ciertos rangos de origen. spec:loadBalancerSourceRanges Todas las versiones compatibles
IP del balanceador de cargas Especifica una IP para los balanceadores de cargas. spec:loadBalancerIP Todas las versiones compatibles
Subred del balanceador de cargas Especifica desde qué subred el balanceador de cargas debe aprovisionar una IP de forma automática. metadata:annotations: networking.gke.io/internal-load-balancer-subnet Beta en GKE 1.17 o superior y 1.16.8-gke.10 o superior
Acceso global Permite que los clientes en todas las regiones de GCP puedan acceder al VIP del balanceador de cargas de TCP/UDP metadata:annotations: networking.gke.io/internal-load-balancer-allow-global-access Versión Beta en GKE 1.16+
GA en GKE 1.7.9-gke.600+
Todos los puertos La capacidad del balanceador de cargas de TCP/UDP para reenviar todos los puertos, en lugar de puertos específicos N/A Sin asistencia nativa

Política de tráfico externo

La externalTrafficPolicy es una opción de servicio estándar que define cómo y si el tráfico entrante a un nodo de GKE tiene balanceo de cargas. Cluster es la política predeterminada, pero a menudo se usa Local para conservar la IP de origen del tráfico que ingresa a un nodo del clúster. Local inhabilita de manera eficaz el balanceo de cargas en el nodo del clúster para que el tráfico que recibe un pod local vea la dirección de origen original.

externalTrafficPolicy es compatible con los servicios de LoadBalancer internos (a través del balanceador de cargas de TCP/UDP), pero el comportamiento del balanceo de cargas depende del origen del tráfico y de la política de tráfico configurada.

Para el tráfico originado por fuera del clúster a un balanceador de cargas de TCP/UDP, tendrá el siguiente comportamiento si hay, al menos, un pod en buen estado del servicio en el clúster:

  • Política Cluster: El tráfico se balanceará a cualquier nodo de GKE en buen estado en el clúster y, luego, kube-proxy lo enviará a un nodo con el pod.
  • Política Local: Los nodos que no tienen uno de los pods del backend aparecerán en mal estado para el balanceador de cargas de TCP/UDP. El tráfico solo se enviará a uno de los nodos del clúster restantes que tenga el pod. Kube-proxy no vuelve a enrutar el tráfico y, en su lugar, se enviará directamente al pod local con su información de encabezado de IP intacta.

Si el tráfico a una IP de servicio LoadBalancer determinada proviene de un nodo de GKE dentro del clúster, existe un comportamiento de tráfico diferente. En la siguiente tabla, se resume el comportamiento del tráfico proveniente de un nodo o pod dentro del clúster destinado a un pod miembro de un servicio LoadBalancer:

externalTrafficPolicy ¿Pod miembro del servicio que se ejecuta en el mismo nodo donde se origina el tráfico? Comportamiento del tráfico
Clúster Los paquetes se entregan a cualquier pod miembro, ya sea en el nodo o en otro diferente.
Clúster No Los paquetes se entregan a cualquier pod miembro, que debe estar en un nodo diferente.
Local Los paquetes se entregan a cualquier pod miembro en el mismo nodo.
Local No

Kubernetes versión 1.14 y anteriores: los paquetes se descartan.

Kubernetes versión 1.15 y posterior: Los paquetes se entregan a cualquier pod miembro, que debe estar en un nodo diferente.

Rangos de origen del balanceador de cargas

El arreglo spec: loadBalancerSourceRanges especifica uno o más rangos de direcciones IP internas. loadBalancerSourceRanges restringe el tráfico a través del balanceador de cargas a las IP especificadas en este campo. Con esta configuración, kube-proxy crea las reglas de iptables correspondientes en los nodos de Kubernetes. GKE también crea de forma automática una regla de firewall en tu red de VPC. Si omites este campo, tu servicio acepta el tráfico de cualquier dirección IP (0.0.0.0/0).

Para obtener más información sobre la especificación del servicio, consulta la referencia de la API de servicio.

IP del balanceador de cargas

spec: loadBalancerIP habilita la opción de elegir una dirección IP específica para el balanceador de cargas. Otro balanceador de cargas TCP/UDP interno o servicio no debe usar la dirección IP. Si se omite, se asigna una IP efímera. Para obtener más información, consulta Reserva una dirección IP interna estática.

Subred del balanceador de cargas (Beta)

De forma predeterminada, GKE implementará un balanceador de cargas de TCP/UDP interno mediante el rango de subred de nodo. Un usuario puede especificar la subred servicio por servicio mediante la anotación networking.gke.io/internal-load-balancer-subnet. Esto es útil para firewalls independientes de las IP del balanceador de cargas de las IP de nodo o para compartir la misma subred de servicio en varios clústeres de GKE. Este parámetro solo es relevante para los servicios de LoadBalancer de TCP/UDP interno.

La subred debe existir antes de que el recurso de servicio haga referencia a ella, ya que GKE no administra el ciclo de vida de la subred. La subred también debe estar en la misma VPC y región que el clúster de GKE. En este paso, se crea por fuera de la banda de GKE:

gcloud compute networks subnets create gke-vip-subnet \
    --network=default \
    --range=10.23.0.0/24 \
    --region=us-central1

La siguiente definición de servicio usa internal-load-balancer-subnet para hacer referencia a la subred por nombre. De forma predeterminada, se elegirá de forma automática una IP disponible de la subred. También puedes especificar loadBalancerIP, pero debe ser parte de la subred a la que se hace referencia.

Existen varias formas de compartir esta subred del balanceador de cargas interno para lograr diferentes casos prácticos:

  • Varias subredes para grupos de servicios en el mismo clúster
  • Una única subred para todos los servicios de un clúster
  • Una única subred compartida entre varios clústeres y varios servicios
apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-subnet: "gke-vip-subnet"
  labels:
    app: hello
spec:
  type: LoadBalancer
  loadBalancerIP: 10.23.0.15
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Acceso global

El acceso global es un parámetro opcional para los servicios de LoadBalancer interno que permite que los clientes de cualquier región de tu red de VPC accedan al balanceador de cargas de TCP/UDP interno. Sin acceso global, el tráfico que se origina en los clientes de tu red de VPC debe estar en la misma región que el balanceador de cargas. El acceso global permite que los clientes de cualquier región accedan al balanceador de cargas. Las instancias de backend deben estar ubicadas en la misma región que el balanceador de cargas.

El acceso global se habilita por servicio mediante la siguiente anotación: networking.gke.io/internal-load-balancer-allow-global-access: "true".

El acceso global no es compatible con las redes heredadas. Se aplican costos normales de tráfico interregional cuando se usa el acceso global en todas las regiones. Consulta Precios de red a fin de obtener información sobre los precios de red para la salida entre regiones. El acceso global está disponible en versión Beta en los clústeres de GKE 1.16+ y GA en 1.17.7-gke.600+.

IP compartida (Beta)

El balanceador de cargas de TCP/UDP interno permite el uso compartido de una dirección IP virtual entre varias reglas de reenvío. Esto es útil para expandir la cantidad de puertos simultáneos en la misma IP o aceptar tráfico de UDP y TCP en la misma IP. Permite un máximo de 50 puertos expuestos por dirección IP. Las IP compartidas se admiten de forma nativa en los clústeres de GKE con servicios de LoadBalancer internos. Cuando se implementa, el campo loadBalancerIP del servicio se usa para indicar qué IP se debe compartir entre los servicios.

Limitaciones

Una IP compartida para varios balanceadores de cargas tiene las siguientes limitaciones y capacidades:

  • Cada servicio (o regla de reenvío) puede tener un máximo de cinco puertos.
  • Un máximo de diez servicios (reglas de reenvío) pueden compartir una dirección IP. Esto da como resultado un máximo de 50 puertos por IP compartida.
  • Las tuplas de protocolo o de puerto no se pueden superponer entre los servicios que comparten la misma IP.
  • Se admite una combinación de servicios de solo TCP y de solo UDP en la misma IP compartida. Sin embargo, no puedes exponer ambos puertos de TCP y UDP en el mismo servicio.

Habilita la IP compartida

Si deseas habilitar que los servicios de LoadBalancer internos compartan una IP común, sigue estos pasos:

  1. Crea una IP interna estática con --purpose SHARED_LOADBALANCER_VIP. Se debe crear una dirección IP con esta finalidad para habilitar su capacidad de ser compartida.

  2. Implementa hasta diez servicios de LoadBalancer internos mediante esta IP estática en el campo loadBalancerIP. El controlador del servicio de GKE concilia los balanceadores de cargas de TCP/UDP internos y se implementan mediante la misma IP de frontend.

En el siguiente ejemplo, se muestra cómo hacer esto con el fin de admitir varios puertos de TCP y UDP en la misma IP del balanceador de cargas interno.

  1. Crea una IP estática en la misma región en la que se encuentra el clúster de GKE. La subred debe ser la misma que usa el balanceador de cargas. De forma predeterminada, es la misma subred que usan las IP del nodo del clúster de GKE.

    gcloud beta compute addresses create internal-10-128-2-98 \
        --region=us-central1 \
        --subnet=default \
        --addresses=10.128.2.98 \
        --purpose=SHARED_LOADBALANCER_VIP
    
  2. Guarda la siguiente configuración del servicio de TCP en un archivo llamado tcp-service.yaml y, luego, impleméntala en el clúster. Usa la IP compartida 10.128.2.98.

    apiVersion: v1
    kind: Service
    metadata:
      name: tcp-service
      namespace: default
      annotations:
        cloud.google.com/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: 10.128.2.98
      selector:
        app: myapp
      ports:
      - name: 8001-to-8001
        protocol: TCP
        port: 8001
        targetPort: 8001
      - name: 8002-to-8002
        protocol: TCP
        port: 8002
        targetPort: 8002
      - name: 8003-to-8003
        protocol: TCP
        port: 8003
        targetPort: 8003
      - name: 8004-to-8004
        protocol: TCP
        port: 8004
        targetPort: 8004
      - name: 8005-to-8005
        protocol: TCP
        port: 8005
        targetPort: 8005
    
  3. Aplica esta definición de servicio en el clúster:

    kubectl apply -f tcp-service.yaml
    
  4. Guarda la siguiente configuración del servicio de UDP en un archivo llamado udp-service.yaml y, luego, impleméntala. También usa la IP compartida 10.128.2.98.

    apiVersion: v1
    kind: Service
    metadata:
      name: udp-service
      namespace: default
      annotations:
        cloud.google.com/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: 10.128.2.98
      selector:
        app: my-udp-app
      ports:
      - name: 9001-to-9001
        protocol: UDP
        port: 9001
        targetPort: 9001
      - name: 9002-to-9002
        protocol: UDP
        port: 9002
        targetPort: 9002
    
  5. Aplica este archivo en el clúster:

    kubectl apply -f udp-service.yaml
    
  6. Para validar que la VIP se comparta entre las reglas de reenvío del balanceador de cargas, enuméralas y filtra la IP estática. Esto muestra que hay una regla de reenvío de UDP y una de TCP que escuchan en siete puertos diferentes en la dirección IP compartida 10.128.2.98.

    gcloud compute forwarding-rules list | grep 10.128.2.98
    ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
    acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
    

Todos los puertos

Si creas un balanceador de cargas de TCP/UDP interno mediante un servicio anotado, no hay manera de configurar una regla de reenvío que use todos los puertos. Sin embargo, si creas un balanceador de cargas TCP/UDP interno de forma manual, puedes elegir el grupo de instancias de los nodos de Google Kubernetes Engine como backend. Los servicios de Kubernetes de type: NodePort están disponibles a través de ILB.

Restricciones para balanceadores de cargas de TCP/UDP internos

  • Para los clústeres que ejecutan Kubernetes versión 1.7.3 y anteriores, solo puedes usar balanceadores de cargas de TCP/UDP internos con subredes de modo automático, pero con Kubernetes versión 1.7.4 y posterior, también puedes usar balanceadores de cargas internos con subredes de modo personalizado, además de las subredes de modo automático.
  • Para clústeres que ejecutan Kubernetes versión 1.7.X o posterior, mientras el clusterIP permanece sin cambios, los balanceadores de cargas TCP/UDP internos no pueden usar direcciones IP reservadas. El campo spec.loadBalancerIP aún se puede definir con una dirección IP no usada para asignar una IP interna específica. Los cambios realizados en los puertos, los protocolos o la afinidad de sesión pueden hacer que estas direcciones IP cambien.

Restricciones para balanceadores de cargas UDP internos

  • Los balanceadores de cargas UDP internos no son compatibles con sessionAffinity: ClientIP.

Límites

Un servicio de Kubernetes con type: Loadbalancer y la anotación cloud.google.com/load-balancer-type: Internal crean un ILB que apunta al servicio de Kubernetes. La cantidad de esos servicios está limitada por la cantidad de reglas de reenvío internas que puedes crear en una red de VPC. Para obtener más información, consulta los Límites por red.

En un clúster de GKE, una regla de reenvío interna apunta a todos los nodos del clúster. Cada nodo en el clúster es una VM de backend para el ILB. El número máximo de VM de backend en un ILB es de 250, sin importar cómo se asocian las VM con los grupos de instancias. Por lo tanto, el número máximo de nodos en un clúster de GKE con un ILB es 250. Si habilitaste el ajuste de escala automático para tu clúster, debes asegurarte de que el ajuste de escala automático no escala tu clúster más allá de los 250 nodos.

Para obtener más información sobre estos límites, consulta Cuotas de recursos de VPC.

Próximos pasos