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 una especificación type: LoadBalancer y una anotación. La anotación depende de la versión de tu clúster de GKE.

Para las versiones de GKE 1.17 y posteriores, usa la anotación networking.gke.io/load-balancer-type: "Internal".

Para versiones anteriores, usa la anotación cloud.google.com/load-balancer-type: "Internal".

Sin el balanceo de cargas TCP/UDP interno, tendrías que configurar un balanceador de cargas externo y reglas de firewall para que la aplicación sea accesible 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 de LoadBalancer que usan el Intercambio de tráfico entre redes de VPC también pueden acceder al Service.

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 para clústeres zonales o una región para clústeres regionales o de Autopilot.

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 de Autopilot o regionales, configura 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:
    networking.gke.io/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.
  • Una anotación que especifica un balanceador de cargas de TCP/UDP interno. La anotación depende de la versión de tu clúster de GKE. Para las versiones de GKE 1.17 y posteriores, usa la anotación networking.gke.io/load-balancer-type: "Internal". Para versiones anteriores, usa la anotación cloud.google.com/load-balancer-type: "Internal".
  • 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.

La respuesta 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. Selecciona la implementación que deseas borrar y, luego, haz clic en Borrar.

  3. Cuando se le solicite que confirme la acción, seleccione la casilla de verificación Borrar el escalador automático horizontal del Pod asociado con la implementación seleccionada y, luego, haga clic en Borrar.

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. Selecciona el servicio que quieres borrar y, luego, haz clic en Borrar.

  3. Cuando se te solicite confirmar, haz clic en Borrar.

Usa la subdivisión del balanceador de cargas TCP/UDP interno (vista previa)

La subdivisión de balanceador de cargas interno para GKE mejora la escalabilidad del balanceador de cargas TCP/UDP interno mediante la partición de backends en grupos superpuestos más pequeños. Con la subdivisión, puedes configurar balanceadores de cargas TCP/UDP internos en clústeres con más de 250 nodos.

Puedes habilitar la subdivisión cuando creas un clúster y editas un clúster existente.

Arquitectura

La subdivisión cambia la forma en la que se implementa el balanceador de cargas TCP/UDP interno. Sin la subdivisión, el controlador de GKE coloca todos los nodos de un clúster en uno o más grupos de instancias zonales no administrados, que comparten todos los balanceadores de cargas internos del clúster de GKE. Por ejemplo, todos los balanceadores de cargas TCP/UDP internos en un clúster de GKE de 40 nodos comparten los mismos 40 nodos que los backends.

Con la subdivisión del balanceador de cargas TCP/UDP interno, el controlador de GKE coloca los nodos en GCE_VM_IP zonal network endpoint groups (NEGs). A diferencia de los grupos de instancias, los nodos pueden ser miembros de más de un NEG zonal, y un balanceador de cargas TCP/UDP interno puede hacer referencia a cada uno de los NEG zonales. El controlador de GKE crea un NEG para cada servicio con un subconjunto de los nodos de GKE como miembros. Por ejemplo, un clúster de GKE de 40 nodos puede tener un balanceador de cargas TCP/UDP interno con 25 nodos en un NEG zonal de backend y otro balanceador de cargas TCP/UDP interno con 25 nodos en un NEG zonal de backend diferente.

Cuando habilitas la subdivisión en tu clúster, el controlador de GKE determina automáticamente cómo dividir los nodos en función de externalTrafficPolicy.

Cuando es externalTrafficPolicy=Cluster, la cantidad máxima de backends en el subconjunto es de 25 nodos. El controlador de GKE selecciona los nodos que serán miembros de un subconjunto de forma aleatoria.

Cuando es externalTrafficPolicy=Local, la cantidad máxima de backends en el subconjunto es de 250 nodos. El controlador de GKE selecciona los nodos que serán miembros de un subconjunto al azar de los nodos que alojan los Pods del servicio. Si los Pods de backend para el servicio están programados en más de 250 nodos, un máximo de 250 nodos y los Pods que se ejecutan en estos reciben tráfico del balanceador de cargas interno.

Requisitos y limitaciones

La subdivisión para GKE tiene los requisitos y las limitaciones que se mencionan a continuación:

  • Puedes habilitar la subdivisión en clústeres nuevos y existentes en la versión de GKE 1.18 y versiones posteriores.
  • El clúster debe tener habilitado el complemento HttpLoadBalancing. Este complemento está habilitado de forma predeterminada. Un clúster que inhabilitó este complemento no puede usar la subdivisión.
  • Versión 322.0.0 y posterior del SDK de Cloud.
  • La subdivisión no se puede usar con clústeres de Autopilot.
  • Se aplican cuotas para los grupos de extremos de red. Google Cloud crea 1 NEG por balanceador de cargas TCP/UDP interno por zona.
  • La subdivisión no se puede inhabilitar una vez habilitada en un clúster.
  • La subdivisión no se puede usar con la anotación para compartir servicios de backend, alpha.cloud.google.com/load-balancer-backend-share.

Habilita la subdivisión del balanceador de cargas interno en un clúster nuevo

Para crear un clúster con la subdivisión del balanceador de cargas interno habilitada, especifica la opción --enable-l4-ilb-subsetting:

gcloud beta container clusters create CLUSTER_NAME \
  --cluster-version VERSION \
  --enable-l4-ilb-subsetting
  {--zone ZONE_NAME | --region REGION_NAME}

Reemplaza lo siguiente:

  • CLUSTER_NAME es el nombre del clúster nuevo.
  • VERSION: la versión de GKE, que debe ser 1.18 o posterior. También puedes usar la opción --release-channel para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.18 o posterior.
  • ZONE_NAME o REGION_NAME: la ubicación del clúster. Estos argumentos son mutuamente excluyentes. Para obtener más información, consulta Tipos de clústeres.

Habilita la subdivisión del balanceador de cargas interno en un clúster existente

Para habilitar la subdivisión del balanceador de cargas interno en un clúster existente, especifica la opción --enable-l4-ilb-subsetting:

gcloud beta container clusters update CLUSTER_NAME \
  --enable-l4-ilb-subsetting

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster

Verifica la subdivisión del balanceador de cargas interno

A fin de verificar que la subdivisión del balanceador de cargas interno funcione correctamente para el clúster, realiza los siguientes pasos:

  1. Implementar una carga de trabajo.

    En el siguiente manifiesto, se describe una implementación que ejecuta una imagen de contenedor de aplicación web de muestra. Guarda el manifiesto como ilb-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ilb-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: ilb-deployment
      template:
        metadata:
          labels:
            app: ilb-deployment
        spec:
          containers:
          - name: hello-app
            image: gcr.io/google-samples/hello-app:1.0
    
  2. Aplica el manifiesto al clúster:

    kubectl apply -f ilb-deployment.yaml
    
  3. Crea un servicio.

    En el siguiente manifiesto, se describe un servicio que crea un balanceador de cargas interno en el puerto TCP 8080. Guarda el manifiesto como ilb-svc.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: ilb-svc
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      externalTrafficPolicy: Cluster
      selector:
        app: ilb-deployment
      ports:
      - name: tcp-port
        protocol: TCP
        port: 8080
        targetPort: 8080
    
  4. Aplica el manifiesto al clúster:

    kubectl apply -f ilb-svc.yaml
    
  5. Inspecciona el servicio:

    kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
    

    El resultado es similar al siguiente:

    {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["us-central1-c"]}
    

    La respuesta indica que GKE creó un grupo de extremos de red llamado k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Esta anotación está presente en los servicios del tipo LoadBalancer que utilizan la subdivisión de GKE y no está presente en los servicios que no usan la subdivisión.

Soluciona problemas

A fin de determinar la lista de nodos en el subconjunto de un servicio, usa el siguiente comando:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
  --zone ZONE

Reemplaza lo siguiente:

  • NEG_NAME: el nombre del grupo de extremos de red que crea el controlador de GKE.
  • ZONE: la zona del grupo de extremos de red en la que se operará.

Parámetros de servicio

Para obtener más información sobre los parámetros de los balanceadores de cargas que puedes configurar, consulta Configura el balanceo de cargas TCP/UDP. Además, los Service de LoadBalancer internos admiten los siguientes parámetros adicionales:

Función Descripción general Campo de servicio Compatibilidad con la versión de GKE
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+ y 1.16.8-gke.10+
GA en GKE 1.17.9-gke.600+
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 Beta en GKE 1.16+
GA en GKE 1.17.9-gke.600+

Subred del balanceador de cargas

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.9-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. Si creas la dirección IP interna estática en una VPC compartida, debes crear la dirección IP en el mismo proyecto de servicio que la instancia que usará la dirección IP, aunque el valor de la dirección IP vendrá del rango de IP disponibles en una subred compartida seleccionada de la red de VPC compartida. Consulta Reserva una IP interna estática en la página Aprovisiona la VPC compartida para obtener más información.

  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

    Si reservas una IP estática en el proyecto que contiene la red, ejecuta el siguiente comando:

    gcloud compute addresses create IP_ADDR_NAME \
    --project PROJECT_ID \
    --subnet SUBNET \
    --region REGION
    --purpose SHARED_LOADBALANCER_VIP
    

    Si reservas una IP estática en el proyecto de servicio de una VPC compartida, ejecuta el siguiente comando:

    gcloud compute addresses create IP_ADDR_NAME \
    --project SERVICE_PROJECT_ID \
    --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
    --region REGION
    --purpose SHARED_LOADBALANCER_VIP
    

    Reemplaza lo siguiente:

    • IP_ADDR_NAME por un nombre para el objeto de dirección IP
    • SERVICE_PROJECT_ID por el ID del proyecto de servicio
    • PROJECT_ID con el ID de tu proyecto (proyecto único)
    • HOST_PROJECT_ID por el ID del proyecto host de VPC compartida
    • REGION por la región que contiene la subred compartida
    • SUBNET por el nombre de la subred compartida
  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:
        networking.gke.io/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:
        networking.gke.io/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 (vista previa)

Las reglas de reenvío internas admiten hasta cinco puertos por regla de reenvío o un parámetro opcional --ports=ALL que reenvíe todos los puertos en la regla de reenvío.

Requisitos

Todos los puertos de GKE tienen los requisitos y las limitaciones que se describen a continuación:

  • Solo se admite cuando --enable-l4-ilb-subsetting está habilitado.
  • Solo se admite con los servicios del balanceador de cargas interno.
  • Admite cualquier cantidad de puertos en un máximo de 100 rangos de puertos contiguos.

El controlador de GKE habilita de forma automática todos los puertos en la regla de reenvío cuando un servicio tiene más de cinco puertos. Por ejemplo, el siguiente manifiesto de servicio tiene seis puertos configurados en dos rangos contiguos:

apiVersion: v1
kind: Service
metadata:
  name: all-ports
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 8081
    targetPort: 8081
    name: 8081-to-8081
    protocol: TCP
  - port: 8082
    targetPort: 8082
    name: 8082-to-8082
    protocol: TCP
  - port: 8083
    targetPort: 8083
    name: 8083-to-8083
    protocol: TCP
  - port: 9001
    targetPort: 9001
    name: 9001-to-9001
    protocol: TCP
  - port: 9002
    targetPort: 9002
    name: 9002-to-9002
    protocol: TCP
  - port: 9003
    targetPort: 9003
    name: 9003-to-9003
    protocol: TCP

El controlador de GKE habilita todos los puertos en la regla de reenvío porque el servicio tiene más de cinco puertos. Sin embargo, el controlador de GKE solo crea puertos de firewall para los puertos especificados en el servicio. Los firewalls de VPC bloquean todas las demás reglas.

Restricciones para balanceadores de cargas TCP/UDP internos

  • Para los clústeres que ejecutan Kubernetes versión 1.7.3 y anteriores, solo puedes usar balanceadores de cargas 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 networking.gke.io/load-balancer-type: Internal crean un balanceador de cargas interno que se orienta 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.

La cantidad máxima de nodos en un clúster de GKE con un balanceador de cargas interno es 250. Para quitar esta limitación, habilita la subdivisión de balanceador de cargas interno. De lo contrario, si habilitaste el ajuste de escala automático para el clúster, debes asegurarte de que el ajuste de escala automático no escale el clúster más allá de los 250 nodos.

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

¿Qué sigue?