Crea un balanceador de cargas externo basado en servicios de backend

Autopilot Standard

En esta página, se muestra cómo implementar un objeto Service LoadBalancer externo que compila un balanceador de cargas de red de transferencia externo regional basado en servicios de backend. Antes de leer esta página, asegúrate de estar familiarizado con los siguientes conceptos:

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

Para obtener más información sobre los balanceadores de cargas de red de transferencia externos regionales en general, consulta Balanceador de cargas de red de transferencia externo regional basado en servicios de backend.

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
• Para usar Google Cloud CLI en esta tarea, instala y, luego, inicializa la gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de 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.

Requisitos

• En este instructivo, se usa spec.loadBalancerClass para crear un balanceador de cargas de red de transferencia externo regional basado en servicios de backend con backends de NEG de GCE_VM_IP. Este instructivo requiere la versión 1.33.1-gke.1779000 o posterior de GKE, ya que spec.loadBalancerClass requiere la versión 1.33.1-gke.1779000 o posterior de GKE. La versión 1.33.1-gke.1779000 o posterior también supera los requisitos mínimos de la versión de GKE para los backends de NEG o la función de balanceador de cargas ponderado.

• Si tu clúster tiene 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. Para obtener más información, consulta el requisito previo de HttpLoadBalancing.

• Para habilitar Cloud Logging en un Service LoadBalancer externo, tu clúster de GKE debe usar la versión 1.36.0-gke.2459000 o una posterior.

• Para usar direcciones IPv6 de Usa tu propia IP (BYOIP) con un Service LoadBalancer externo IPv6 de pila única, tu clúster de GKE debe usar la versión 1.37.1-gke.2097000 o una posterior.

Elige un clúster

Puedes crear un clúster nuevo o elegir uno existente que cumpla con los requisitos.

Crear un clúster nuevo

Autopilot

Para crear un clúster de Autopilot nuevo, sigue estos pasos:

gcloud container clusters create-auto CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

• CLUSTER_NAME es el nombre del clúster nuevo.
• RELEASE_CHANNEL: el nombre del canal de versiones de GKE para el clúster.
• VERSION: Es la versión de GKE que se usa para el clúster.
• COMPUTE_LOCATION: la región de Compute Engine del clúster.

Para inhabilitar la creación automática de reglas de firewall de VPC para los servicios de LoadBalancer, incluye la marca --disable-l4-lb-firewall-reconciliation. Para obtener más información, consulta Reglas de firewall administradas por el usuario para los Services LoadBalancer de GKE.

Standard

Para crear un clúster estándar nuevo, sigue estos pasos:

gcloud container clusters create CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

• CLUSTER_NAME es el nombre del clúster nuevo.
• RELEASE_CHANNEL: el nombre del canal de versiones de GKE para el clúster.
• VERSION: Es la versión de GKE que se usa para el clúster.
• COMPUTE_LOCATION: la región de Compute Engine del clúster.

Para inhabilitar la creación automática de reglas de firewall de VPC para los servicios de LoadBalancer, incluye la marca --disable-l4-lb-firewall-reconciliation. Para obtener más información, consulta Reglas de firewall administradas por el usuario para los Services LoadBalancer de GKE.

Actualiza un clúster existente:

Usa gcloud CLI para actualizar un clúster existente:

gcloud container clusters upgrade CLUSTER_NAME \
    --cluster-version=VERSION \
    --master \
    --location=COMPUTE_LOCATION

Reemplaza lo siguiente:

• CLUSTER_NAME: es el nombre del clúster existente.
• VERSION: Es la versión específica de GKE a la que deseas actualizar el clúster. Para obtener más información, consulta Actualiza el plano de control de forma manual.
• COMPUTE_LOCATION: Es la región de Compute Engine del clúster.

Para inhabilitar la creación automática de reglas de firewall de VPC para los servicios de LoadBalancer, incluye la marca --disable-l4-lb-firewall-reconciliation. Para obtener más información, consulta Reglas de firewall administradas por el usuario para los Services LoadBalancer de GKE.

Implementa una carga de trabajo de muestra

Implementa la siguiente carga de trabajo de ejemplo que proporciona los Pods de entrega para el objeto Service LoadBalancer externo.

1. Guarda el siguiente Deployment de muestra como store-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store
   spec:
     replicas: 20
     selector:
       matchLabels:
         app: store
     template:
       metadata:
         labels:
           app: store
       spec:
         containers:
         - image: registry.k8s.io/echoserver:1.10
           imagePullPolicy: Always
           name: echoserver
           ports:
             - name: http
               containerPort: 8080
           readinessProbe:
             httpGet:
               path: /healthz
               port: 8080
               scheme: HTTP
   

2. Aplica el manifiesto al clúster:

   kubectl apply -f store-deployment.yaml
   

3. Verifica que haya 20 Pods de entrega para el Deployment:

   kubectl get pods
   

   El resultado es similar a lo siguiente:

   NAME                     READY   STATUS    RESTARTS   AGE
   store-cdb9bb4d6-s25vw      1/1     Running   0          10s
   store-cdb9bb4d6-vck6s      1/1     Running   0          10s
   ....
   

Crea el objeto Service LoadBalancer externo

1. Exponer la carga de trabajo de muestra creando un Service LoadBalancer externo

   1. Guarda el siguiente manifiesto de Service como store-v1-lb-svc.yaml:

      apiVersion: v1
      kind: Service
      metadata:
        name: store-v1-lb-svc
      spec:
        type: LoadBalancer
        loadBalancerClass: networking.gke.io/l4-regional-external
        selector:
          app: store
        ports:
        - name: tcp-port
          protocol: TCP
          port: 8080
          targetPort: 8080
      

   2. Aplica el manifiesto al clúster:

      kubectl apply -f store-v1-lb-svc.yaml
      

   Ten en cuenta los siguientes puntos sobre este manifiesto de ejemplo:

   • Si tu clúster ejecuta GKE 1.33.1-gke.1779000 a 1.36, debes establecer el campo spec.loadBalancerClass en el valor networking.gke.io/l4-regional-external en el momento en que se aplica el manifiesto por primera vez al clúster. Este campo indica a GKE que cree un balanceador de cargas de red de transferencia externo regional basado en servicios de backend. En GKE 1.37 y versiones posteriores, esta configuración es el comportamiento predeterminado y el campo no es obligatorio. Los balanceadores de cargas de red de transferencia externos regionales basados en servicios de backend son obligatorios para admitir funciones como el tráfico IPv6 y el balanceo de cargas ponderado.

   • GKE usa backends de NEG de GCE_VM_IP o backends de grupos de instancias no administrados, según la versión del clúster. En los clústeres con la versión 1.32.2-gke.1652000, el balanceador de cargas de red de transferencia externo regional basado en servicios de backend usa NEG GCE_VM_IP. En las versiones anteriores, el balanceador de cargas de red de transferencia externo regional basado en servicios de backend usa grupos de instancias no administrados.

   • Este campo spec.loadBalancerClass es inmutable y se debe establecer cuando creas el Service. Debido a que este campo es inmutable, no puedes agregarlo ni modificarlo en el manifiesto de un Service LoadBalancer existente. Cualquier intento de hacerlo generará un error y la actualización del Service fallará.

   • Para crear un Service IPv6 de pila única en un clúster de pila doble, establece el valor del campo spec.ipFamilyPolicy en SingleStack y el valor del campo spec.ipFamilies en IPv6. En un clúster IPv6 de pila única, estos son los valores predeterminados y puedes omitirlos. Para obtener más información, consulta Servicios de LoadBalancer de IPv6.

Crea un Service LoadBalancer externo en un clúster IPv6 de pila única

Vista previa

Este producto o función está sujeto a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles “tal como están” y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Cuando creas un Service LoadBalancer externo IPv6 de pila única en un clúster IPv6 de pila única o un clúster de pila doble, la subred que usa el balanceador de cargas depende de si la subred del nodo del clúster usa un tipo de acceso IPv6 EXTERNAL o INTERNAL. En un clúster de pila doble, debes establecer el valor del campo spec.ipFamilyPolicy en SingleStack y el valor del campo spec.ipFamilies en IPv6 (en un clúster de IPv6 de pila única, estos son los valores predeterminados y puedes omitirlos). Los objetos Service LoadBalancer externos IPv6 siempre usan un balanceador de cargas de red de transferencia externo regional basado en servicios de backend en el nivel Premium. En los siguientes ejemplos, se establece el campo spec.loadBalancerClass en networking.gke.io/l4-regional-external de forma explícita, aunque esta variante del balanceador de cargas es la predeterminada en la versión 1.37 y posteriores de GKE:

• Clústeres con nodos externos (tipo de acceso GUA EXTERNAL): Si los nodos del clúster se ejecutan en una subred externa con direcciones de unidifusión global (GUA), el balanceador de cargas externo usa automáticamente la subred de nodos existente. Crea tu Service sin anotaciones de subred personalizadas:

  apiVersion: v1
  kind: Service
  metadata:
    name: ext-ipv6-svc
  spec:
    type: LoadBalancer
    loadBalancerClass: networking.gke.io/l4-regional-external
    ipFamilyPolicy: SingleStack
    ipFamilies:
    - IPv6
    selector:
      app: store
    ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  

• Clústeres con nodos internos (tipo de acceso ULA INTERNAL): Si los nodos de tu clúster se ejecutan en una subred interna con direcciones de unidifusión locales únicas (ULA), un balanceador de cargas externo no puede usar esa subred directamente. Debes aprovisionar una subred IPv6 externa (EXTERNAL) dedicada y hacer referencia a ella con la anotación networking.gke.io/load-balancer-subnet en tu Service:

  1. Crea una subred IPv6 externa dedicada:

     gcloud compute networks subnets create SUBNET_NAME \
         --stack-type=ipv6_only \
         --ipv6-access-type=EXTERNAL \
         --network=NETWORK_NAME \
         --region=COMPUTE_REGION
     

     Reemplaza lo siguiente:

     • SUBNET_NAME: El nombre de la subred que se creará.
     • NETWORK_NAME: Es el nombre de la red de VPC en la que creas esta subred.
     • COMPUTE_REGION: Es la región de Compute Engine para la subred.

  2. Crea el Service que haga referencia al nombre de tu subred dedicada en la anotación networking.gke.io/load-balancer-subnet:

     apiVersion: v1
     kind: Service
     metadata:
       name: ext-ipv6-svc
       annotations:
         networking.gke.io/load-balancer-subnet: SUBNET_NAME
     spec:
       type: LoadBalancer
       loadBalancerClass: networking.gke.io/l4-regional-external
       ipFamilyPolicy: SingleStack
       ipFamilies:
       - IPv6
       selector:
         app: store
       ports:
       - protocol: TCP
         port: 8080
         targetPort: 8080
     

1. Verifica la dirección IP asignada al Service:

   kubectl get svc ext-ipv6-svc
   

   El resultado confirma que las columnas CLUSTER-IP y EXTERNAL-IP (una dirección GUA pública) están propagadas:

   NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP                      PORT(S)        AGE
   ext-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c401   2600:1900:4000:2714:8000:0:0:0   80:31114/TCP   51s
   

Para obtener más información, consulta Servicios de LoadBalancer con IPv6.

Usa tus propias direcciones IPv6 (BYOIPv6)

En GKE versión 1.37.1-gke.2097000 y posteriores, puedes configurar un objeto Service LoadBalancer externo IPv6 de pila única para usar trae tus propias direcciones IPv6 (BYOIPv6) desde un subprefijo IPv6 regional de un prefijo público delegado (PDP) en modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

Antes de crear el Service, asegúrate de cumplir con los siguientes requisitos:

• Tu clúster ejecuta la versión 1.37.1-gke.2097000 o una posterior de GKE. El clúster puede ser de pila única IPv6 o de pila doble (el Service debe ser de pila única IPv6 en ambos casos), y la subred del clúster puede tener un tipo de acceso IPv6 INTERNAL o EXTERNAL; no se requiere un rango de subred IPv6 externo porque el rango de direcciones proviene del prefijo delegado público.
• Tienes un subprefijo IPv6 regional en modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION con una longitud de prefijo asignable de /96 y el estado ANNOUNCED, en la misma región que tu clúster. Para obtener instrucciones, consulta Crea subprefijos IPv6.

• El agente de servicio de GKE ([e-mail]) tiene el rol de administrador de IP pública de Compute (roles/compute.publicIpAdmin) en el proyecto que posee el prefijo delegado público. Para otorgar el rol, ejecuta el siguiente comando:

  gcloud projects add-iam-policy-binding PDP_PROJECT_ID \
      --member="serviceAccount:[e-mail]" \
      --role="roles/compute.publicIpAdmin"
  

  Reemplaza lo siguiente:

  • PDP_PROJECT_ID: Es el ID del proyecto al que pertenece el prefijo público delegado.
  • PROJECT_NUMBER: Es el número del proyecto que contiene tu clúster.

• El Service es un Service IPv6 de pila única (spec.ipFamilyPolicy: SingleStack y spec.ipFamilies: ["IPv6"]) que establece el campo spec.loadBalancerClass en networking.gke.io/l4-regional-external y usa el nivel Premium. Los servicios de pila doble, los servicios IPv4 y el nivel Estándar no son compatibles con BYOIPv6.

• El Service no incluye la anotación networking.gke.io/load-balancer-subnet, que no se puede combinar con la anotación networking.gke.io/ip-collection-v6.

Elige si deseas asignar un rango de direcciones BYOIPv6 externas efímeras o usar un rango de direcciones BYOIPv6 externas estáticas reservadas:

• Rango de direcciones BYOIPv6 externas efímeras: Agrega la anotación networking.gke.io/ip-collection-v6 al manifiesto de Service y configúrala en la URL completa del recurso o la ruta de acceso parcial del recurso de tu subprefijo regional:

  apiVersion: v1
  kind: Service
  metadata:
    name: ext-byoipv6-svc
    annotations:
      networking.gke.io/ip-collection-v6: "projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME"
  spec:
    type: LoadBalancer
    loadBalancerClass: networking.gke.io/l4-regional-external
    ipFamilyPolicy: SingleStack
    ipFamilies:
    - IPv6
    selector:
      app: store
    ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080
  

  Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto que contiene el prefijo secundario.
  • REGION: Es la región del clúster.
  • SUB_PREFIX_NAME: Es el nombre de tu subprefijo regional en el modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

  Si más adelante cambias la anotación networking.gke.io/ip-collection-v6, GKE vuelve a crear la regla de reenvío de IPv6 con una dirección nueva del prefijo nuevo, lo que interrumpe brevemente el tráfico al Service. Si quitas la anotación, el Service vuelve a una dirección proporcionada por Google desde una subred con un rango de IPv6 externo. Si la subred de tu clúster tiene un rango de IPv6 interno, agrega la anotación networking.gke.io/load-balancer-subnet al mismo tiempo.

• Rango de direcciones BYOIPv6 externas estáticas: Reserva un rango de direcciones IPv6 externas estáticas regionales /96 del subprefijo y haz referencia a él con la anotación networking.gke.io/load-balancer-ip-addresses:

  1. Crea un rango de direcciones IPv6 externas estáticas regionales a partir de tu subprefijo:

     gcloud compute addresses create STATIC_BYOIPV6_NAME \
         --region=REGION \
         --ip-version=IPV6 \
         --endpoint-type=NETLB \
         --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME
     

     Reemplaza lo siguiente:

     • STATIC_BYOIPV6_NAME: Es un nombre para el recurso de dirección IPv6 estática.
     • REGION: Es la región del clúster.
     • PROJECT_ID: Es el ID del proyecto que contiene el prefijo secundario.
     • SUB_PREFIX_NAME: Es el nombre de tu subprefijo regional en el modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

     La anotación networking.gke.io/ip-collection-v6 es opcional cuando usas un rango de direcciones BYOIPv6 externas estáticas. Si configuras esta anotación, debe hacer referencia al mismo prefijo secundario del que reservaste el rango de direcciones.

  2. Haz referencia al nombre del recurso de dirección IPv6 estática reservada en el manifiesto del Service:

     apiVersion: v1
     kind: Service
     metadata:
       name: ext-static-byoipv6-svc
       annotations:
         networking.gke.io/load-balancer-ip-addresses: STATIC_BYOIPV6_NAME
     spec:
       type: LoadBalancer
       loadBalancerClass: networking.gke.io/l4-regional-external
       ipFamilyPolicy: SingleStack
       ipFamilies:
       - IPv6
       selector:
         app: store
       ports:
       - name: tcp-port
         protocol: TCP
         port: 80
         targetPort: 8080
     

Para obtener más información, consulta Usa tus propias direcciones IPv6 (BYOIPv6).

Habilita el balanceo de cargas ponderado

Para distribuir las conexiones nuevas de forma proporcional a los nodos según la cantidad de Pods de entrega, preparados y no finalizados que haya en cada nodo, habilita el balanceo de cargas ponderado agregando la anotación networking.gke.io/weighted-load-balancing: "pods-per-node" al manifiesto del Service.

1. Agrega la anotación networking.gke.io/weighted-load-balancing: "pods-per-node" al manifiesto del Service store-v1-lb-svc.yaml y asegúrate de establecer también el valor externalTrafficPolicy: Local para que se vea de la siguiente manera:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1-lb-svc
     annotations:
       networking.gke.io/weighted-load-balancing: "pods-per-node"
   spec:
     type: LoadBalancer
     loadBalancerClass: networking.gke.io/l4-regional-external
     externalTrafficPolicy: Local
     selector:
       app: store
     ports:
     - name: tcp-port
       protocol: TCP
       port: 8080
       targetPort: 8080
   

2. Aplica el manifiesto al clúster:

   kubectl apply -f store-v1-lb-svc.yaml
   

Ten en cuenta lo siguiente sobre este ejemplo de balanceo de cargas ponderado:

• El manifiesto de Service usa externalTrafficPolicy: Local. Si no necesitas habilitar el balanceo de cargas ponderado, también puedes usar externalTrafficPolicy: Cluster. Para obtener detalles sobre cómo externalTrafficPolicy define la agrupación de nodos, qué nodos pasan sus verificaciones de estado del balanceador de cargas y cómo se procesan los paquetes, consulta Conceptos del objeto Service LoadBalancer.

• Si habilitas el balanceo de cargas ponderado, GKE no te impide usar externalTrafficPolicy: Cluster, pero externalTrafficPolicy: Cluster inhabilita de forma eficaz el balanceo de cargas ponderado, ya que el paquete se puede enrutar, después del balanceador de cargas, a un nodo diferente.

También puedes habilitar el balanceo de cargas ponderado en un Service LoadBalancer externo existente con kubectl edit svc service-name. El comando kubectl edit abre el manifiesto del Service del balanceador de cargas existente en el editor de texto configurado, en el que puedes modificar el manifiesto y guardar los cambios. Cuando edites un Service LoadBalancer externo existente, ten en cuenta los siguientes puntos:

• El Service LoadBalancer externo existente debe haber dado como resultado la creación de un balanceador de cargas de red de transferencia externo regional basado en servicios de backend. Para los clústeres que ejecutan versiones de GKE anteriores a la 1.37, este requisito significa que el Service LoadBalancer externo existente debe tener el campo spec.loadBalancerClass establecido en networking.gke.io/l4-regional-external cuando el manifiesto se aplicó por primera vez al clúster.

  Agregar la anotación networking.gke.io/weighted-load-balancing: "pods-per-node" a un Service LoadBalancer externo existente que usa un balanceador de cargas de red de transferencia externo regional basado en grupos de destino no tiene ningún efecto.

• Cuando actualices el manifiesto del Service LoadBalancer externo existente, asegúrate de establecer el valor externalTrafficPolicy: Local. El uso de externalTrafficPolicy: Cluster inhabilita de manera eficaz el balanceo de cargas ponderado, ya que el paquete se puede enrutar, después del balanceador de cargas, a un nodo diferente.

Inhabilita el balanceo de cargas ponderado

Para distribuir conexiones nuevas a los nodos, sin importar cuántos Pods de entrega haya en cada nodo, inhabilita el balanceo de cargas ponderado quitando la anotación networking.gke.io/weighted-load-balancing: "pods-per-node" del manifiesto del Service.

Nota: Cuando habilitas o inhabilitas el balanceo de cargas ponderado, se borra la tabla de seguimiento de conexiones del balanceador de cargas. Es posible que las conexiones existentes se enruten a nodos diferentes, lo que hará que esos nodos envíen paquetes de restablecimiento de TCP. Como práctica recomendada, habilita o inhabilita el balanceo de cargas ponderado cuando se pueda tolerar un breve período de interrupciones de la conexión.

Habilita el registro para los servicios de backend

Puedes habilitar, inhabilitar y ver registros para un balanceador de cargas de red de transferencia externo regional basado en servicios de backend.

Para configurar Cloud Logging, crea un recurso personalizado L4LBConfig que especifique tu configuración de registro. El recurso L4LBConfig está vinculado a un Service de Kubernetes en el manifiesto del Service. Después de aplicar el manifiesto, el controlador de GKE configura el registro para el servicio de backend. Si no vinculas un recurso L4LBConfig al Service, el controlador deja de administrar la configuración de registro y deja el servicio de backend en su último estado conocido. Para obtener más información, consulta Información sobre el comportamiento de la inercia.

Puedes configurar los siguientes campos:

• enabled: Si se establece en true, habilita el registro para este Service y los registros están disponibles en Cloud Logging. De lo contrario, el registro se inhabilita para este Service.
• sampleRate: Especifica un valor de 0 a 1,000,000 (predeterminado), en el que 0 significa que no se registra ningún paquete y 1,000,000 significa que se registra el 100% de los paquetes. El campo sampleRate es opcional y solo es relevante si el valor del campo enable se establece en true.
• optionalMode: Controla qué campos de metadatos opcionales se incluyen en los registros generados para el balanceador de cargas. El campo acepta uno de los siguientes valores de cadena:
  • EXCLUDE_ALL_OPTIONAL: Es el parámetro de configuración predeterminado si no se especifica optionalMode. Cuando se establece, no se incluyen campos opcionales en los registros, lo que proporciona el formato de registro más conciso.
  • INCLUDE_ALL_OPTIONAL: Habilita el registro para todos los campos opcionales disponibles, lo que proporciona las entradas de registro más detalladas.
  • CUSTOM: Especifica una lista personalizada de campos opcionales que se incluyen en los registros. Con el modo CUSTOM, también debes usar el parámetro optionalFields para proporcionar una lista separada por comas de los campos que deseas.
• optionalFields: Es una cadena de nombres de campos separados por comas. Define los campos de metadatos opcionales exactos que deseas incluir en los registros generados. Este campo solo se usa cuando optionalMode se establece en CUSTOM; de lo contrario, se ignoran todos los valores.

Para configurar Cloud Logging, crea el recurso L4LBConfig en el mismo espacio de nombres que el recurso Service. En el siguiente ejemplo de manifiesto de L4LBConfig, se habilita Cloud Logging y se establece la tasa de muestreo en el 50% de las solicitudes para un Service de balanceador de cargas determinado.

1. Guarda el siguiente manifiesto como svc-l4lb-config.yaml:

   apiVersion: networking.gke.io/v1
   kind: L4LBConfig
   metadata:
     name: svc-l4lb-config
     namespace: default
   spec:
     logging:
       enabled: true # must be included
       sampleRate: 500000
       optionalMode: "INCLUDE_ALL_OPTIONAL"
   

2. Aplica el manifiesto L4LBConfig a tu clúster:

   kubectl apply -f svc-l4lb-config.yaml
   

3. Agrega la anotación networking.gke.io/l4lb-config al manifiesto del Service store-v1-lb-svc.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1-lb-svc
     annotations:
       cloud.google.com/l4-rbs: "enabled"
       networking.gke.io/l4lb-config: "svc-l4lb-config"
   spec:
     type: LoadBalancer
     selector:
       app: store
     ports:
       - name: tcp-port
         protocol: TCP
         port: 8080
         targetPort: 8080
   

4. Aplica el manifiesto del Service a tu clúster:

   kubectl apply -f store-v1-lb-svc.yaml
   

Verifica el objeto Service LoadBalancer externo y sus componentes

1. Verifica que el Service esté en ejecución:

   kubectl get svc store-v1-lb-svc
   

   El resultado es similar a lo siguiente:

   NAME               TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
   store-v1-lb-svc   LoadBalancer   10.44.196.160     35.193.28.231   8080:32466/TCP   11m
   

   GKE asignó una EXTERNAL_IP para el balanceador de cargas de red de transferencia externo regional.

   Nota: GKE puede tardar unos minutos en asignar una dirección IP externa antes de que el balanceador de cargas esté listo para entregar tu aplicación.

2. Prueba la conexión al balanceador de cargas:

   curl EXTERNAL_IP:PORT
   

   Reemplaza lo siguiente:

   • EXTERNAL_IP: Es la dirección IP asignada para el balanceador de cargas de red de transferencia externo regional.
   • PORT: Es el número de puerto asignado para el balanceador de cargas de red de transferencia externo regional.

   El resultado es similar a lo siguiente:

   Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd
   
   Pod Information:
     -no pod information available-
   
   Server values:
     server_version=nginx: 1.13.3 - lua: 10008
   
   Request Information:
     client_address=10.128.0.50
     method=GET
     real path=/
     query=
     request_version=1.1
     request_scheme=http
     request_uri=EXTERNAL_IP
   
   Request Headers:
     accept=*/*
     host=EXTERNAL_IP
     user-agent=curl/7.81.0
   
   Request Body:
     -no body in request-
   
   

3. Verifica el objeto Service LoadBalancer y su conjunto de anotaciones que describen sus recursos deGoogle Cloud :

   kubectl describe svc store-v1-lb-svc
   

   El resultado es similar a lo siguiente:

   Name:                     store-v1-lb-svc
   Namespace:                default
   Labels:                   <none>
   Annotations:              cloud.google.com/neg-status: {"network_endpoint_groups":{"0":"k8s2-qvveq1d8-default-my-service-ext-5s55db85"},"zones":["us-central1-c"]} #This annotation appears in the output only if the service uses NEG backends.
                             networking.gke.io/weighted-load-balancing: pods-per-node #This annotation appears in the output only if weighted load balancing is enabled.
                             service.kubernetes.io/backend-service: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                             service.kubernetes.io/firewall-rule: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                             service.kubernetes.io/firewall-rule-for-hc: k8s2-qvveq1d8-default-my-service-ext-5s55db85-fw
                             service.kubernetes.io/healthcheck: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                             service.kubernetes.io/tcp-forwarding-rule: a808124abf8ce406ca51ab3d4e7d0b7d
   Selector:                 app=store
   Type:                     LoadBalancer
   IP Family Policy:         SingleStack
   IP Families:              IPv4
   IP:                       10.18.102.23
   IPs:                      10.18.102.23
   LoadBalancer Ingress:     35.184.160.229
   Port:                     tcp-port  8080/TCP
   TargetPort:               8080/TCP
   NodePort:                 tcp-port  31864/TCP
   Endpoints:                10.20.1.28:8080,10.20.1.29:8080
   Session Affinity:         None
   External Traffic Policy:  Local
   HealthCheck NodePort:     30394
   
   Events:
     Type    Reason                Age                    From                     Message
     ----    ------                ----                   ----                     -------
     Normal  ADD                   4m55s                  loadbalancer-controller  default/my-service-ext
   

   Hay varios campos que indican que un balanceador de cargas de red de transferencia externo regional basado en servicios de backend y sus recursos de Google Cloud se crearon correctamente:

   • Campo Events. Este campo está vacío cuando el Service LoadBalancer y sus recursos se crearon de forma correcta. Si se produjo un error, aparecerá aquí.

   • Lista de Annotations habilitada: GKE agrega la siguiente lista de anotaciones de solo lectura al manifiesto de Service. Cada anotación cuyo nombre comienza con service.kubernetes.io/ se usa para indicar el nombre de un recurso deGoogle Cloud creado como parte del balanceador de cargas o para admitirlo.

     • La anotación networking.gke.io/weighted-load-balancing: pods-per-node indica que se aplicó el balanceo de cargas ponderado y que el balanceador de cargas distribuye el tráfico a los Pods de backend según la cantidad de Pods que se ejecutan en cada nodo.
     • La anotación service.kubernetes.io/backend-service indica el nombre del servicio de backend del balanceador de cargas.
     • La anotación service.kubernetes.io/healthcheck indica el nombre de la verificación de estado del balanceador de cargas que usa el servicio de backend.
     • La anotación service.kubernetes.io/tcp-forwarding-rule o service.kubernetes.io/udp-forwarding-rule indica el nombre de la regla de reenvío del balanceador de cargas.
     • La anotación service.kubernetes.io/firewall-rule indica el nombre de la regla de firewall creada para permitir el tráfico hacia los nodos del clúster. Los rangos de origen para esta regla de firewall se pueden personalizar con spec.loadBalancerSourceRanges[]. Si deseas obtener detalles adicionales sobre las reglas de firewall para los Services LoadBalancer, consulta las Reglas de firewall y la lista de direcciones IP de origen permitidas.
     • La anotación service.kubernetes.io/firewall-rule-for-hc indica el nombre de la regla de firewall requerida para las verificaciones de estado del balanceador de cargas.

     • La anotación cloud.google.com/neg-status indica los NEG que usa el balanceador de cargas y sus zonas. Esta anotación solo está presente cuando se cumplen las siguientes condiciones:

       • El clúster ejecutaba la versión 1.32.2-gke.1652000 o una posterior de GKE cuando se aplicó el manifiesto al clúster.
       • El campo spec.loadBalancerClass que se estableció en el valor networking.gke.io/l4-regional-external estaba presente en el manifiesto del Service cuando se aplicó al clúster.

4. Verifica que se hayan creado los recursos del balanceador de cargas y las reglas de firewall para el objeto Service LoadBalancer externo:

   • Para ver la regla de reenvío, ejecuta el siguiente comando:

       gcloud compute forwarding-rules describe FWD_RULE_NAME \
         --region=REGION_NAME
     

     Reemplaza lo siguiente:

     • FWD_RULE_NAME: el nombre de la regla de reenvío que proporcionan las anotaciones de solo lectura service.kubernetes.io/tcp-forwarding-rule o service.kubernetes.io/udp-forwarding-rule. Para verificar estas anotaciones, ejecuta kubectl describe svc SERVICE_NAME.
     • REGION_NAME: Es la región de Google Cloud que contiene el clúster. Para los clústeres zonales, la región contiene la zona que usa el clúster.

   • Para ver el servicio de backend, ejecuta el siguiente comando:

     gcloud compute backend-services describe BACKEND_SERVICE_NAME \
       --region=REGION_NAME
     

     Reemplaza lo siguiente:

     • BACKEND_SERVICE_NAME: el nombre del servicio de backend que proporciona la anotación de solo lectura service.kubernetes.io/backend-service. Para verificar esta anotación de solo lectura, ejecuta kubectl describe svc SERVICE_NAME.
     • REGION_NAME: Es la región de Google Cloud que contiene el clúster. Para los clústeres zonales, la región contiene la zona que usa el clúster.

   • Para ver la verificación de estado del balanceador de cargas, ejecuta el siguiente comando:

     gcloud compute health-checks describe HEALTH_CHECK_NAME \
       --region=REGION_NAME
     

     Reemplaza lo siguiente:

     • HEALTH_CHECK_NAME: el nombre de la verificación de estado del balanceador de cargas. El nombre de la verificación de estado se proporciona mediante la anotación service.kubernetes.io/healthcheck de solo lectura. Para verificar esta anotación de solo lectura, ejecuta kubectl describe svc SERVICE_NAME.
     • REGION_NAME: Es la región de Google Cloud que contiene el clúster. Para los clústeres zonales, la región contiene la zona que usa el clúster.

   • Para ver las reglas de firewall, ejecuta los siguientes comandos:

     gcloud compute firewall-rules describe FIREWALL_RULE_NAME
     

     gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME
     

     Reemplaza lo siguiente:

     • FIREWALL_RULE_NAME: Es el nombre de la regla de firewall que permite el tráfico al balanceador de cargas. El nombre de esta regla de firewall se proporciona con la anotación de solo lectura service.kubernetes.io/firewall-rule. Para verificar esta anotación de solo lectura, ejecuta kubectl describe svc SERVICE_NAME.
     • HEALTH_CHECK_FIREWALL_RULE_NAME: el nombre de la regla de firewall que permite las verificaciones de estado de los backends del balanceador de cargas (los nodos del clúster). El nombre de esta regla de firewall se proporciona con la anotación de solo lectura service.kubernetes.io/firewall-rule-for-hc. Para verificar esta anotación de solo lectura, ejecuta kubectl describe svc SERVICE_NAME.

   • Para ver los NEG del balanceador de cargas, ejecuta el siguiente comando:

     gcloud compute network-endpoint-groups describe NEG_NAME \
       --zone=ZONE_NAME
     

     Reemplaza lo siguiente:

     • NEG_NAME: el nombre del NEG del balanceador de cargas. El nombre del NEG se proporciona con la anotación cloud.google.com/neg-status de solo lectura. Para verificar esta anotación de solo lectura, ejecuta el comando kubectl describe svc SERVICE_NAME. La anotación contiene datos estructurados con información sobre los nombres y las zonas de NEG que usa el balanceador de cargas. En el caso de los clústeres zonales, esta anotación contiene información sobre un NEG. En el caso de los clústeres regionales, esta anotación contiene información sobre un NEG en cada zona en la que se encuentra el clúster.
     • ZONE_NAME: Es la zona de Google Cloud que contiene el NEG.

5. Verifica que se haya habilitado Cloud Logging para el servicio de backend:

   kubectl get svc SERVICE_NAME --output yaml
   

   Reemplaza lo siguiente:

   • SERVICE_NAME: el nombre del servicio de backend.

   En el resultado, asegúrate de que el campo Status.Conditions tenga Type: LoggingConfigManaged y Reason: Reconciled.

Borra el Service LoadBalancer externo

Para borrar el Service LoadBalancer externo de store-v1-lb-svc de muestra, usa el siguiente comando:

kubectl delete service store-v1-lb-svc

GKE quita automáticamente todos los recursos del balanceador de cargas que creó para el Service LoadBalancer externo.

Migra a backends de NEG de GCE_VM_IP

Los objetos Service LoadBalancer externos crean balanceadores de cargas de red de transferencia externos regionales basados en servicios de backend si se crean en GKE 1.37 o versiones posteriores, especifican el valor networking.gke.io/l4-regional-external para el campo spec.loadBalancerClass o incluyen la anotación cloud.google.com/l4-rbs: "enabled". Según la versión de GKE del clúster, GKE usa grupos de extremos de red GCE_VM_IP o grupos de instancias no administrados como backends:

• Si el manifiesto del Service se aplicó a un clúster que ejecuta la versión 1.32.2-gke.1652000 o posterior de GKE, el balanceador de cargas de red de transferencia externo regional resultante usa backends de grupo de extremos de red (NEG) GCE_VM_IP.

• Si el manifiesto del Service se aplicó a un clúster que ejecuta una versión anterior de GKE, el balanceador de cargas de red de transferencia externo regional resultante usa backends de grupos de instancias no administrados.

Para obtener más información, consulta Agrupación de nodos en Acerca de los objetos Service LoadBalancer.

Puedes crear un nuevo Service LoadBalancer externo con la tecnología de un balanceador de cargas de red de transferencia externo regional basado en servicios de backend que use backends de NEG GCE_VM_IP si tu Service existente usa uno de los siguientes balanceadores de cargas:

• Un balanceador de cargas de red de transferencia externo regional basado en servicios de backend con backends de grupos de instancias
• Un balanceador de cargas de red de transferencia externo regional basado en grupos de destino

Nota: El cambio a un balanceador de cargas de red de transferencia externo regional basado en servicios de backend que use backends de NEG GCE_VM_IP requiere unos minutos de tiempo de inactividad para reemplazar el Service.

Para conservar una dirección IPv4 externa cuando cambias a un balanceador de cargas de red de transferencia externo regional basado en servicios de backend que usa backends de NEG GCE_VM_IP (los Services LoadBalancer externos IPv6 no requieren esta migración), haz lo siguiente:

1. Si aún no lo hiciste, actualiza tu clúster a la versión 1.32.2-gke.1652000 o posterior de GKE.

2. Identifica el Service LoadBalancer externo que deseas cambiar a un balanceador de cargas de red de transferencia externo regional basado en servicios de backend con backends de NEG GCE_VM_IP. Describe el Service con el siguiente comando:

   kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
   

   Reemplaza lo siguiente:

   • SERVICE_NAME: Es el nombre del Service de LoadBalancer externo existente.

   • SERVICE_NAMESPACE: Es el espacio de nombres del Service de LoadBalancer externo existente.

   En el resultado del comando, anota la dirección IPv4 externa del balanceador de cargas que aparece después de LoadBalancer Ingress.

3. Recupera el manifiesto del Service para el Service de LoadBalancer existente:

   • Es mejor si tienes el manifiesto de Service original que aplicaste al clúster en el pasado. Por ejemplo, puedes tener esto en un repositorio de control de código fuente.

   • Si no tienes el manifiesto de Service original, haz lo siguiente:

     • Ejecuta el siguiente comando para obtener una copia YAML del manifiesto del Service que representa la implementación actual del balanceador de cargas:

       kubectl get svc SERVICE_NAME -n SERVICE_NAMESPACE -o yaml
       

     • Copia el manifiesto YAML en un editor de texto. Quita el atributo status y los siguientes atributos metadata:

       • Todas las anotaciones siguientes:
         • La anotación kubectl.kubernetes.io/last-applied-configuration
         • Todas las anotaciones que comienzan con service.kubernetes.io
       • creationTimestamp
       • finalizers
       • resourceVersion
       • uid

   • Asegúrate de que el manifiesto incluya el campo spec.loadBalancerClass establecido en el valor networking.gke.io/l4-regional-external. Si migras desde un balanceador de cargas de red de transferencia externo regional basado en un grupo de destino, se debe agregar el campo.

   Guarda el archivo de manifiesto y toma nota de dónde lo guardaste. En el resto de este procedimiento, se hace referencia a la ruta en la que guardaste el manifiesto como MANIFEST_FILE_PATH.

4. Configura un recurso de dirección IPv4 externa estática para que contenga la dirección IPv4 externa que usa el balanceador de cargas existente:

   gcloud compute addresses create IP_ADDRESS_NAME --region=CLUSTER_REGION --addresses LB_EXTERNAL_IP
   

   Reemplaza lo siguiente:

   • IP_ADDRESS_NAME: Es el nombre de la dirección IP externa estática. El nombre debe cumplir con las convenciones de nombres para los recursos de Compute Engine.

   • CLUSTER_REGION: Es la región que contiene el clúster. En el caso de los clústeres zonales, esta es la región que contiene la zona del clúster.

   • LB_EXTERNAL_IP: Es la dirección IPv4 externa que usa el balanceador de cargas actual, que se determinó en el segundo paso de este procedimiento.

5. Verifica que se haya creado el recurso de dirección IPv4 externa estática:

   gcloud compute addresses describe IP_ADDRESS_NAME --region=CLUSTER_REGION
   

   Reemplaza las variables como se indica en el paso anterior.

6. Borra el Service existente:

   kubectl delete svc SERVICE_NAME -n SERVICE_NAMESPACE
   

7. Agrega la siguiente anotación al archivo de manifiesto del Service MANIFEST_FILE_PATH:

   networking.gke.io/load-balancer-ip-addresses: IP_ADDRESS_NAME
   

   Para obtener más información sobre esta anotación, consulta Direcciones IP estáticas en los parámetros del Service LoadBalancer.

8. Aplica el manifiesto de Service actualizado al clúster:

   kubectl apply -f MANIFEST_FILE_PATH
   

9. Libera el recurso de dirección IPv4 estática (opcional).

   gcloud compute addresses delete IP_ADDRESS_NAME --region=CLUSTER_REGION
   

Solucionar problemas

En esta sección, se describen los problemas que puedes encontrar cuando configuras un objeto Service LoadBalancer externo basado en un servicio de backend.

Política de tráfico externo incorrecta para el balanceo de cargas ponderado

Si no configuras el valor externalTrafficPolicy: Local cuando habilitas el balanceo de cargas ponderado, es posible que recibas un evento de advertencia cuando describas el Service con el siguiente comando:

kubectl describe svc store-v1-lb-svc`

Events:
  Type     Reason                   Age      From                     Message
  ----     ------                   ----     ----                     -------
  Warning  UnsupportedConfiguration 4m55s    loadbalancer-controller  Weighted load balancing by pods-per-node has no effect with External Traffic Policy: Cluster.

Para habilitar de forma eficaz el balanceo de cargas ponderado, debes establecer el valor de externalTrafficPolicy: Local.

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

Si un Service LoadBalancer externo IPv6 muestra un evento SyncExternalLoadBalancerFailed con el mensaje Network tier Standard is not supported for IPv6 External Load Balancer, quita la anotación cloud.google.com/network-tier: Standard del manifiesto del Service. Los Services de LoadBalancer externos IPv6 solo se admiten en el nivel Premium.

Errores cuando configuras tus propias direcciones IPv6 (BYOIPv6)

Cuando configuras Usa tus propias direcciones IPv6 (BYOIPv6) para un Service LoadBalancer externo, es posible que veas eventos de advertencia SyncExternalLoadBalancerFailed cuando ejecutes el comando kubectl describe service SERVICE_NAME. El mensaje de evento comienza con Error ensuring Resource for L4 External LoadBalancer, err: seguido de uno de los siguientes errores:

• networking.gke.io/ip-collection-v6 is currently only supported for IPv6-only Services: Asegúrate de que el manifiesto de Service especifique spec.ipFamilyPolicy: SingleStack y spec.ipFamilies: ["IPv6"].
• static IPv6 address "ADDRESS_NAME" is a BYOIP address from IP collection "SUB_PREFIX", which is currently only supported for IPv6-only Services: Asegúrate de que el manifiesto de Service especifique spec.ipFamilyPolicy: SingleStack y spec.ipFamilies: ["IPv6"]. Este error indica que el Service es de pila doble o IPv4, pero hace referencia a una dirección BYOIPv6 estática.
• cannot specify both networking.gke.io/load-balancer-subnet ("SUBNET") and networking.gke.io/ip-collection-v6 ("SUB_PREFIX") for LoadBalancer: Quita la anotación networking.gke.io/load-balancer-subnet del manifiesto del Service cuando uses la anotación networking.gke.io/ip-collection-v6.
• invalid networking.gke.io/ip-collection-v6 "VALUE": expected projects/PROJECT/regions/REGION/publicDelegatedPrefixes/NAME o invalid networking.gke.io/ip-collection-v6 "VALUE": the public delegated prefix must be in the cluster region REGION: establece la anotación en la URL completa del recurso o la ruta de acceso parcial del recurso (projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME) de un prefijo secundario en la misma región que tu clúster. No se acepta un nombre de subprefijo sin formato.
• reserved address ("ADDRESS_NAME") is not valid, err: ipCollection mismatch, expected "SUB_PREFIX_A", actual: "SUB_PREFIX_B": Asegúrate de que la anotación networking.gke.io/ip-collection-v6 coincida con el prefijo público delegado que usaste para reservar la dirección IPv6 estática, o bien omite la anotación networking.gke.io/ip-collection-v6 cuando uses la anotación networking.gke.io/load-balancer-ip-addresses.
• googleapi: Error 403: Required 'compute.publicDelegatedPrefixes.use' permission for 'SUB_PREFIX', forbidden: Otorga el rol de administrador de IP pública de Compute (roles/compute.publicIpAdmin) al agente de servicio de GKE ([e-mail]) en el proyecto que posee el prefijo público delegado. GKE necesita este permiso cada vez que sincroniza el Service, por lo que no quites el rol después de que GKE cree el Service.

¿Qué sigue?

• Para obtener una descripción general de estos objetos Service LoadBalancer, consulta objetos Service LoadBalancer.
• Para obtener una descripción de los parámetros de los servicios de balanceador de cargas, consulta Parámetros de los servicios de balanceador de cargas.
• Soluciona problemas de balanceo de cargas en GKE.