Crea un balanceador de cargas interno

Autopilot estándar

En esta página, se muestra cómo implementar un Service LoadBalancer interno que compila un balanceador de cargas de red de transferencia interno. Antes de leer esta página, asegúrate de estar familiarizado con lo siguiente:

• Acerca de los Services LoadBalancer
• Parámetros de objeto Service LoadBalancer de GKE

Para obtener más información sobre los balanceadores de cargas de red de transferencia internos en general, consulta la descripción general del balanceador de cargas de red de transferencia interno.

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 la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de la gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

• Asegúrate de tener un clúster de Autopilot o Standard existente. Para crear un clúster nuevo, consulta Crea un clúster de Autopilot.

Requisitos

• En este instructivo, se usa spec.loadBalancerClass para crear un balanceador de cargas de red de transferencia interno con backends de NEG de GCE_VM_IP. Este instructivo requiere la versión 1.33.1-gke.1779000 de GKE o una posterior, ya que spec.loadBalancerClass requiere la versión 1.33.1-gke.1779000 de GKE o una posterior.

• La afinidad zonal requiere la versión 1.33.3-gke.1392000 de GKE o una posterior.

• Tu clúster debe tener habilitada la subdivisión de GKE:

  • La subdivisión de GKE está habilitada de forma predeterminada en los clústeres que ejecutan la versión 1.36 y versiones posteriores. En estas versiones, el subconjunto está activo independientemente del valor de la marca de subconjunto del clúster.

  • En las versiones de GKE compatibles anteriores a la versión 1.36, debes habilitar la subdivisión de GKE de forma explícita. Puedes habilitar la subdivisión de GKE cuando creas un clúster nuevo o actualizas un clúster existente. Una vez habilitada, la subdivisión de GKE no se puede inhabilitar. Para obtener más información, consulta Cómo verificar y habilitar el subconjunto de GKE.

• Si tu clúster está en una versión anterior a la 1.36, el complemento HttpLoadBalancing debe estar habilitado en tu clúster. Este complemento está habilitado de forma predeterminada.

Verifica y habilita la subdivisión de GKE

Asegúrate de que la subdivisión de GKE esté habilitada:

• La subdivisión de GKE siempre está habilitada en la versión 1.36 y posteriores de GKE.

• Puedes habilitar la subdivisión de GKE de forma manual en clústeres estándar y de Autopilot nuevos y existentes que ejecuten la versión 1.18.19-gke.1400 y versiones posteriores de GKE, pero antes de la versión 1.36 de GKE. No puedes inhabilitar la subdivisión de GKE después de habilitarla.

Para obtener información sobre por qué es importante la subdivisión de GKE, consulta Consideraciones especiales para los objetos Service LoadBalancer internos.

Para determinar si el subconjunto de GKE está habilitado, ejecuta el siguiente comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Reemplaza lo siguiente:

• CLUSTER_NAME: el nombre del clúster
• LOCATION : Es la zona o región del clúster.

El resultado del comando muestra la versión del plano de control del clúster seguida de True o False para el atributo networkConfig.enableL4ilbSubsetting. Interpreta el resultado de la siguiente manera:

• Si la versión del plano de control es 1.36 o posterior, el subconjunto de GKE se habilita independientemente de si el atributo networkConfig.enableL4ilbSubsetting es True o False.
• Si la versión del plano de control es anterior a la 1.36, haz lo siguiente:
  • True significa que la subdivisión de GKE está habilitada.
  • False significa que la subdivisión de GKE está inhabilitada.

Para habilitar la subdivisión de GKE en un clúster que ejecuta la versión de GKE 1.18.19-gke.1400 y versiones posteriores, pero anterior a la versión 1.36 de GKE, usa la gcloud CLI o la Google Cloud consola.

Console

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 \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Reemplaza lo siguiente:

• CLUSTER_NAME: el nombre del clúster
• LOCATION : Es la zona o región del clúster.

La habilitación de la subdivisión de GKE (con la gcloud CLI, la consola deGoogle Cloud o la actualización del clúster a la versión 1.36 o posterior) no modifica los Services LoadBalancer internos existentes. Si deseas migrar un objeto Service LoadBalancer interno existente para usar backends de NEG GCE_VM_IP, debes implementar un manifiesto de Service de reemplazo.

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

1. (Opcional) Inhabilita la creación automática de reglas de firewall de VPC:

   Si bien GKE crea automáticamente reglas de firewall de VPC para permitir el tráfico a tu balanceador de cargas interno, tienes la opción de inhabilitar la creación automática de reglas de firewall de VPC y administrar las reglas de firewall por tu cuenta. Solo puedes inhabilitar las reglas de firewall de VPC si habilitaste la subdivisión de GKE para tu Service LoadBalancer interno. Sin embargo, administrar las reglas de firewall de VPC es opcional y puedes confiar en las reglas automáticas.

   Antes de inhabilitar la creación automática de reglas de firewall de VPC, asegúrate de definir reglas de permiso que permitan que el tráfico llegue a tu balanceador de cargas y a los Pods de la aplicación.

   Para obtener más información sobre cómo administrar las reglas de firewall de VPC, consulta Administra la creación automática de reglas de firewall y, para inhabilitar la creación automática de reglas de firewall, consulta Reglas de firewall administradas por el usuario para los servicios de LoadBalancer de GKE.

2. 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
      spec:
        type: LoadBalancer
        # Request an internal load balancer.
        loadBalancerClass: networking.gke.io/l4-regional-internal
        # Evenly route external traffic to all endpoints.
        externalTrafficPolicy: Cluster
        # Prioritize routing traffic to endpoints that are in the same zone.
        trafficDistribution: PreferClose
        selector:
          app: ilb-deployment
        # Forward traffic from TCP port 80 to port 8080 in backend Pods.
        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.
      • El campo spec.loadBalancerClass establecido en el valor networking.gke.io/l4-regional-internal para especificar un objeto Service LoadBalancer interno, como se muestra en el manifiesto de ejemplo.
      • 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.

      • spec.trafficDistribution (vista previa) para definir cómo GKE enruta el tráfico entrante. Para habilitar la afinidad zonal, establece el valor de este campo en PreferSameZone. La afinidad zonal significa que GKE prioriza el enrutamiento del tráfico que se origina en una zona hacia los nodos y los Pods dentro de esa misma zona. Si no hay Pods en buen estado disponibles en esa zona, el tráfico se enruta a otra zona. Para las versiones de clúster anteriores a la 1.35.0-gke.1811000, usa PreferClose como valor. La afinidad zonal requiere que se habilite la subdivisión de GKE.

        Nota: También puedes habilitar o inhabilitar la afinidad zonal en un servicio LoadBalancer interno existente con el comando kubectl edit svc service-name. El comando kubectl edit abre el manifiesto del servicio del balanceador de cargas existente en el editor de texto configurado, en el que puedes agregar o quitar el parámetro spec.trafficDistribution y guardar los cambios. Es posible que el tráfico se interrumpa brevemente cuando modifiques este parámetro.

      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
       # Kubernetes automatically allocates a port on the node during the
       # process of implementing a Service of type LoadBalancer.
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     trafficDistribution: PreferSameZone
     type: LoadBalancer
   status:
     # IP address of the load balancer forwarding rule.
     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

En esta sección, se muestra cómo verificar los componentes clave de tu balanceador de cargas de red de transferencia interno.

• Verifica que el Service esté en ejecución:

  kubectl get service SERVICE_NAME --output yaml
  

  Reemplaza SERVICE_NAME por el nombre del manifiesto del servicio.

  Si habilitaste la afinidad zonal, el resultado incluye el parámetro spec.trafficDistribution. El valor de este campo se establece en PreferSameZone o PreferClose si la versión del clúster es anterior a 1.35.0-gke.1811000.

• Verifica la dirección IP de la regla de reenvío 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. Verifica que esta regla de reenvío se incluya en la lista de reglas de reenvío del proyecto del clúster con 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
  

• Describe el servicio de backend del balanceador de cargas con 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.

  Si habilitaste la afinidad zonal, haz lo siguiente:

  • El campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover debe establecerse en el valor ZONAL_AFFINITY_SPILL_CROSS_ZONE.
  • El campo networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio debe establecerse en 0 o no incluirse.

  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
  networkPassThroughLbTrafficPolicy:
    zonalAffinity:
      spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
  protocol: TCP
  ...
  

  Si inhabilitaste la afinidad zonal, el campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover debe establecerse en ZONAL_AFFINITY_DISABLED o no incluirse. Ten en cuenta que la afinidad zonal se inhabilita automáticamente si tu clúster se encuentra en una versión anterior a la 1.33.3-gke.1392000.

• Determina la lista de nodos en un subconjunto para un servicio:

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

• Determina la lista de nodos en buen estado para un balanceador de cargas de red de transferencia interno:

  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

Ejecuta el siguiente comando en la misma región que el clúster:

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 el Deployment y el Service con kubectl delete o laGoogle Cloud consola.

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

Console

Borra la implementación

Para borrar la implementación, sigue estos pasos:

1. Accede a la página Cargas de trabajo de 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 Service 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 regla de reenvío puede tener hasta cinco puertos (contiguos o no contiguos) o se puede configurar para que coincida con el tráfico y lo reenvíe en todos los puertos. Si un objeto Service de tipo LoadBalancer interno define más de cinco puertos, la regla de reenvío se establecerá automáticamente para que coincida con todos los 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
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use an IP address that you create.
     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
   spec:
     type: LoadBalancer
     # Request an internal load balancer.
     loadBalancerClass: networking.gke.io/l4-regional-internal
     # Use the same IP address that you used for the TCP Service.
     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
   

Problemas conocidos

Error durante la creación del balanceador de cargas en el nivel Estándar

Cuando creas un balanceador de cargas de red de transferencia interno en un proyecto con el nivel de red predeterminado del proyecto configurado como Estándar, aparece el siguiente mensaje de error:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Para resolver este problema en las versiones de GKE anteriores a 1.23.3-gke.900, configura el nivel de red predeterminado del proyecto como Premium.

Este problema se resuelve en las versiones 1.23.3-gke.900 y posteriores de GKE cuando la subdivisión de GKE está habilitada.

El controlador de GKE crea balanceadores de cargas de red de transferencia internos en el nivel de red Premium, incluso si el nivel de red predeterminado del proyecto está configurado en Estándar.

¿Qué sigue?

• Consulta la descripción general de la red GKE.
• Más información sobre el balanceador de cargas de Compute Engine.
• Obtén información para crear un clúster nativo de la VPC.
• Soluciona problemas de balanceo de cargas en GKE.
• Más información sobre el agente de enmascaramiento de IP.
• Obtén información sobre cómo configurar redes autorizadas.