Crea un balanceador de cargas interno

En esta página, se explica cómo crear un balanceador de cargas de red de transferencia interno o un balanceador de cargas interno en Google Kubernetes Engine (GKE). Para crear un balanceador de cargas de red de transferencia externo, aprende a Crear un Service de tipo LoadBalancer.

Usa la subdivisión del balanceador de cargas de red de transferencia interno

Los balanceadores de cargas de red de transferencia internos permiten que los clientes dentro de la red de VPC de tu clúster y los clientes en redes conectadas a la red de VPC de tu clúster puedan acceder a los Services del clúster. No es necesario que los clientes estén ubicados en tu clúster. Por ejemplo, se puede acceder a un objeto Service LoadBalancer interno para las instancias de máquina virtual (VM) que se encuentran en la red de VPC del clúster.

Usa la subdivisión de GKE

La subdivisión de GKE mejora la escalabilidad de los objetos Service LoadBalancer internos porque usa grupos de extremos de red (NEG) de GCE_VM_IP como backends en lugar de grupos de instancias. Cuando la subdivisión de GKE está habilitada, GKE crea un NEG por zona de procesamiento por cada objeto Service LoadBalancer interno. Los extremos miembros en el NEG son las direcciones IP de los nodos que tienen al menos uno de los Pods de entrega del objeto Service. Para obtener más información sobre la subdivisión de GKE, consulta Agrupación de nodos.

Requisitos y limitaciones

La subdivisión de GKE tiene los siguientes requisitos y limitaciones:

  • Puedes habilitar la subdivisión en clústeres estándar nuevos y existentes en la versión de GKE 1.18.19-gke.1400 y versiones posteriores. La subdivisión de GKE no se puede inhabilitar una vez habilitada.
  • La subdivisión de GKE está inhabilitada en los clústeres de Autopilot.
  • La subdivisión de GKE requiere que el complemento HttpLoadBalancing esté habilitado. Este complemento está habilitado de forma predeterminada. En los clústeres de Autopilot, no puedes inhabilitar este complemento necesario.
  • Se aplican cuotas para los grupos de extremos de red. Google Cloud crea un NEG GCE_VM_IP por Service de LoadBalancer interno por zona.
  • Se aplican cuotas para las reglas de reenvío, los servicios de backend y las verificaciones de estado. Para obtener más información, consulta Cuotas y límites.
  • La subdivisión de GKE no se puede usar con la anotación para compartir un servicio de backend entre varios balanceadores de cargas, alpha.cloud.google.com/load-balancer-backend-share.
  • Debes tener la versión 345.0.0 de Google Cloud CLI o una posterior.

Antes de comenzar

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

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Habilita la subdivisión de GKE en un clúster estándar nuevo

Puedes crear un clúster Standard con la subdivisión de GKE habilitada a través de Google Cloud CLI, la consola de Google Cloud o Terraform. Un clúster creado con la subdivisión de GKE habilitada siempre usa la subdivisión de GKE.

Console

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. Configura tu clúster como desees.

  4. En el panel de navegación, en Clúster, haz clic en Redes.

  5. Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.

  6. Haz clic en Crear.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

  • CLUSTER_NAME es el nombre del clúster nuevo.
  • VERSION: la versión de GKE, que debe ser 1.18.19-gke.1400 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.19-gke.1400 o posterior.
  • COMPUTE_LOCATION: la ubicación de Compute Engine para el clúster.

Para usar una red o subred no predeterminadas, ejecuta el siguiente comando:

  gcloud container clusters create CLUSTER_NAME \
      --cluster-version=VERSION \
      --network NETWORK_NAME \
      --subnetwork SUBNETWORK_NAME \
      --enable-l4-ilb-subsetting \
      --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

  • SUBNET_NAME: es el nombre de la subred nueva. En las versiones de GKE 1.22.4-gke.100 y posteriores, puedes especificar una subred en un proyecto diferente mediante la URL de recurso completamente calificada para este campo. Puedes obtener la URL del recurso completamente calificado mediante el comando gcloud compute networks subnets describe.
  • NETWORK_NAME: es el nombre de la red de VPC para la subred.

Terraform

Para crear un clúster Standard con la subdivisión de GKE habilitada a través de Terraform, consulta el siguiente ejemplo:

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

Si deseas obtener más información sobre el uso de Terraform, consulta Compatibilidad con Terraform para GKE.

Habilita la subdivisión de GKE en un clúster estándar existente

Puedes habilitar la subdivisión de GKE para un clúster estándar existente con la CLI de gcloud o la consola de Google Cloud. No puedes inhabilitar la subdivisión de GKE después de habilitarla.

Consola

  1. En la consola de Google Cloud, ve a la página Google Kubernetes Engine.

    Ir a Google Kubernetes Engine

  2. En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.

  3. En Herramientas de redes, junto al campo Subdivisión de balanceadores de cargas internos L4, haz clic en Habilitar la subdivisión de balanceadores de cargas internos L4.

  4. Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.

  5. Haz clic en Save Changes.

gcloud

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

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster

La habilitación de la subdivisión de GKE no interrumpe los Services LoadBalancer internos existentes. Si deseas migrar los objetos Service LoadBalancer internos existentes para usar servicios de backend con NEG GCE_VM_IP como backends, debes implementar un manifiesto de Service de reemplazo. Para obtener más detalles, consulta Agrupación de nodos en la documentación de conceptos del objeto Service LoadBalancer.

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

  1. 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: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

  2. Aplica el manifiesto al clúster:

    kubectl apply -f ilb-deployment.yaml

Crea un objeto Service LoadBalancer interno

En el siguiente ejemplo, se crea un objeto Service LoadBalancer interno mediante el puerto TCP 80. GKE implementa un balanceador de cargas de red de transferencia interno cuya regla de reenvío usa el puerto 80, pero luego reenvía el tráfico a los pods de backend en el puerto 8080:

  1. 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: 80
    targetPort: 8080

    El manifiesto debe contener las siguientes características:

    • Un name para el objeto Service LoadBalancer interno, en este caso ilb-svc.
    • Una anotación que especifica que necesitas un objeto Service LoadBalancer interno. Para las versiones de GKE 1.17 y posteriores, usa la anotación networking.gke.io/load-balancer-type: "Internal" como se muestra en el manifiesto de ejemplo. Para versiones anteriores, usa cloud.google.com/load-balancer-type: "Internal" en su lugar.
    • El tipo type: LoadBalancer.
    • Un campo spec: selector para especificar los pods a los que se orientará el servicio, por ejemplo, app: hello.
    • Información del puerto:
      • port representa el puerto de destino en el que la regla de reenvío del balanceador de cargas de red de transferencia interno recibe paquetes.
      • El targetPort debe coincidir con un containerPort definido en cada Pod de entrega.
      • No es necesario que los valores port y targetPort sean los mismos. Los nodos siempre realizan NAT de destino y cambian la dirección IP de la regla de reenvío del balanceador de cargas de destino y port a una dirección IP de Pod de destino y targetPort. Para obtener más detalles, consulta Traducción de direcciones de red de destino en nodos en la documentación de conceptos del objeto Service LoadBalancer.

    El manifiesto puede contener lo siguiente:

    • spec.ipFamilyPolicy y ipFamilies para definir cómo GKE asigna direcciones IP al Service. GKE admite Objetos Service LoadBalancer de IP de pila única (solo IPv4 o solo IPv6) o de pila doble. Un objeto Service LoadBalancer de doble pila se implementa con dos reglas de reenvío del balanceador de cargas de red de transferencia interno separadas: una para el tráfico IPv4 y otra para el tráfico IPv6. El objeto Service LoadBalancer de pila doble de GKE está disponible en la versión 1.29 o posterior. Para obtener más información, consulta Services de pila doble de IPv4/IPv6.

    Para obtener más información, consulta los parámetros del objeto Service LoadBalancer.

  2. Aplica el manifiesto al clúster:

    kubectl apply -f ilb-svc.yaml

  3. Obtén información detallada sobre el servicio:

    kubectl get service ilb-svc --output yaml

    El resultado es similar a este:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"ingress":true}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
    networking.gke.io/load-balancer-type: Internal
    service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
    service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
    service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
    service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
    service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
  creationTimestamp: "2022-07-22T17:26:04Z"
  finalizers:
  - gke.networking.io/l4-ilb-v2
  - service.kubernetes.io/load-balancer-cleanup
  name: ilb-svc
  namespace: default
  resourceVersion: "51666"
  uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
spec:
  allocateLoadBalancerNodePorts: true
  clusterIP: 10.88.2.141
  clusterIPs:
  - 10.88.2.141
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: tcp-port
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 10.128.15.245

    El resultado tiene los siguientes atributos:

    • La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno se incluye en status.loadBalancer.ingress. Esta dirección IP es diferente del valor de clusterIP. En este ejemplo, la dirección IP de la regla de reenvío del balanceador de cargas es 10.128.15.245.
    • Cualquier Pod que tenga la etiqueta app: ilb-deployment es un Pod de entrega para este Service. Estos son los Pods que reciben paquetes enrutados por el balanceador de cargas de red de transferencia interno.
    • Los clientes llaman al Service mediante esta dirección IP de loadBalancer y el puerto de destino TCP especificado en el campo port del manifiesto del Service. Para obtener detalles completos sobre cómo se enrutan los paquetes una vez que un nodo los recibe, consulta Procesamiento de paquetes.
    • GKE asignó un nodePort al objeto Service. En este ejemplo, se asigna el puerto 30521. El nodePort no es relevante para el balanceador de cargas de red de transferencia interno.

  4. Inspecciona el grupo de extremos de red de Service:

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

    El resultado es similar a este:

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

    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 Services que no usan la subdivisión de GKE.

Verifica los componentes del balanceador de cargas de red de transferencia interno

La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno es 10.128.15.245 en el ejemplo incluido en la sección Crea un Service LoadBalancer interno. Puedes ver que esta regla de reenvío se incluye en la lista de reglas de reenvío del proyecto del clúster mediante Google Cloud CLI:

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

El resultado incluye la regla de reenvío del balanceador de cargas de red de transferencia interno relevante, su dirección IP y el servicio de backend al que hace referencia la regla de reenvío (en este ejemplo, k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).

NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r

Puedes describir el servicio de backend del balanceador de cargas mediante Google Cloud CLI:

gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

Reemplaza COMPUTE_REGION por la región de procesamiento del servicio de backend.

El resultado incluye el NEG GCE_VM_IP de backend o los NEGs para el Service (en este ejemplo, k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r):

backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

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=COMPUTE_ZONE

Reemplaza lo siguiente:

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

Para determinar la lista de nodos en buen estado para un balanceador de cargas de red de transferencia interno, usa el siguiente comando:

gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

Reemplaza lo siguiente:

  • SERVICE_NAME: el nombre del servicio de backend. Este valor es el mismo que el nombre del grupo de extremos de red creado por el controlador de GKE.
  • COMPUTE_REGION: es la región de procesamiento del servicio de backend en la que se operará.

Prueba la conectividad al balanceador de cargas de red de transferencia interno

Establece una conexión SSH a una instancia de VM en la misma red de VPC y en la misma región que el clúster, luego, ejecuta el siguiente comando:

curl LOAD_BALANCER_IP:80

Reemplaza LOAD_BALANCER_IP por la dirección IP de la regla de reenvío del balanceador de cargas.

La respuesta muestra la salida de ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Solo se puede acceder al balanceador de cargas de red de transferencia interno dentro de la misma red de VPC (o una red conectada). De forma predeterminada, la regla de reenvío del balanceador de cargas tiene inhabilitado el acceso global, por lo que las VMs de cliente, los túneles de Cloud VPN o los adjuntos de Cloud Interconnect (VLAN) deben estar ubicados en la misma región que el balanceador de cargas de red de transferencia interno. Para admitir clientes en todas las regiones, puedes habilitar el acceso global en la regla de reenvío del balanceador de cargas si incluyes la anotación de acceso global en el manifiesto del objeto Service.

Borra el objeto Service LoadBalancer interno y los recursos del balanceador de cargas

Puedes borrar los objetos Deployment y Service con kubectl delete o la consola de Google Cloud.

kubectl

Borra la implementación

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

kubectl delete deployment ilb-deployment

Borra el servicio

Para borrar el servicio, ejecuta el siguiente comando:

kubectl delete service ilb-svc

Consola

Borra la implementación

Para borrar la implementación, sigue estos pasos:

  1. Ve a la página Cargas de trabajo en la consola de Google Cloud.

    Ir a 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. Ve a la página Ingress y servicios en la consola de Google Cloud.

    Ir a Ingress y Service

  2. Selecciona el servicio que quieres borrar y, luego, haz clic en Borrar.

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

IP compartida

El balanceador de cargas de red de transferencia 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.
  • Cada regla de reenvío que comparte la misma dirección IP debe usar una combinación única de protocolos y puertos. Por lo tanto, cada objeto Service LoadBalancer interno debe usar un conjunto único de protocolos y puertos.
  • 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 red de transferencia internos y estos 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.

    Si tu clúster y la red de VPC están en el mismo proyecto, haz lo siguiente:

    gcloud compute addresses create IP_ADDR_NAME \
    --project=PROJECT_ID \
    --subnet=SUBNET \
    --addresses=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP

    Si tu clúster está en un proyecto de servicio de VPC compartida, pero usa una red de VPC compartida en un proyecto host, haz lo siguiente:

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

    Reemplaza lo siguiente:

    • IP_ADDR_NAME: un nombre para el objeto de dirección IP
    • SERVICE_PROJECT_ID: el ID del proyecto de servicio
    • PROJECT_ID: el ID de tu proyecto (proyecto único)
    • HOST_PROJECT_ID: el ID del proyecto host de la VPC compartida
    • COMPUTE_REGION: es la región de procesamiento que contiene la subred compartida.
    • IP_ADDRESS: una dirección IP interna sin usar del rango de direcciones IP principal de la subred seleccionada Si omites especificar una dirección IP, Google Cloud selecciona una dirección IP interna sin usar del rango de direcciones IP principal de la subred seleccionada. Para determinar una dirección seleccionada de forma automática, deberás ejecutar gcloud compute addresses describe.
    • SUBNET: 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. Reemplaza IP_ADDRESS por la dirección IP que elegiste en el paso anterior.

    apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: IP_ADDRESS
  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 el IP_ADDRESS que especificaste en el paso anterior.

    apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: IP_ADDRESS
  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 el IP_ADDRESS compartido, que en este ejemplo es 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

Restricciones y límites

Restricciones para los balanceadores de cargas de red de transferencia internos

  • Para los clústeres que ejecutan Kubernetes versión 1.7.4 o superior, pueden usar balanceadores de cargas internos con subredes modo personalizado además de las subredes en modo automático
  • Los clústeres que ejecutan Kubernetes versión 1.7.X y posteriores admiten el uso de una dirección IP reservada para el balanceador de cargas de red de transferencia interno si creas la dirección IP reservada con la marca --purpose establecida en SHARED_LOADBALANCER_VIP. Para obtener instrucciones paso a paso, consulta Habilita IP compartida. GKE solo conserva la dirección IP de un balanceador de cargas de red de transferencia interno si el Service hace referencia a una dirección IP interna con ese propósito. De lo contrario, GKE podría cambiar la dirección IP del balanceador de cargas (spec.loadBalancerIP) si el servicio se actualiza (por ejemplo, si se cambian los puertos).
  • Incluso si la dirección IP del balanceador de cargas cambia (consulta el punto anterior), el spec.clusterIP permanece constante.

Restricciones para balanceadores de cargas de UDP internos

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

Problemas conocidos

Tiempo de espera de conexión cada 10 minutos

Los servicios LoadBalancer internos creados con subdivisión pueden observar interrupciones del tráfico cada 10 minutos, aproximadamente. Este error se corrigió en las siguientes versiones:

  • 1.18.19-gke.1700 y posteriores
  • 1.19.10-gke.1000 y posteriores
  • 1.20.6-gke.1000 y posteriores

¿Qué sigue?