Balanceo de carga nativo de contenedores mediante NEG de zona independientes

En esta página se muestra cómo crear un servicio de Kubernetes respaldado por un grupo de puntos finales de red (NEG) GCE_VM_IP_PORT por zonas en un clúster nativo de VPC de Google Kubernetes Engine (GKE).

Para obtener información sobre las ventajas, los requisitos y las limitaciones del balanceo de carga nativo de contenedores, consulta el artículo Balanceo de carga nativo de contenedores.

Información general

Un NEG representa un grupo de endpoints. GKE admite NEGs independientes de tipo GCE_VM_IP_PORT. GCE_VM_IP_PORT Los NEGs admiten endpoints que usan la dirección IP interna principal de la VM o una dirección IP de uno de sus intervalos de IP de alias.

En el contexto de un clúster nativo de VPC de GKE que usa NEGs independientes, cada endpoint es una dirección IP de Pod y un puerto de destino. Las direcciones IP de los pods proceden del intervalo de IP de alias del nodo para los pods, que a su vez procede del intervalo de direcciones IP secundarias de la subred del clúster para los pods.

GKE proporciona un controlador NEG para gestionar la pertenencia de GCE_VM_IP_PORT NEGs. Puede añadir los NEGs que cree como backends a los servicios de backend de los balanceadores de carga que configure fuera de la API de GKE.

En el siguiente diagrama se describe cómo se corresponden los objetos de la API de Kubernetes con los objetos de Compute Engine.

Ingress con NEGs

Cuando se usan NEGs con Ingress de GKE, el controlador Ingress facilita la creación de todos los aspectos del balanceador de carga. Esto incluye la creación de la dirección IP virtual, las reglas de reenvío, las comprobaciones de estado, las reglas de cortafuegos y más.

Ingress es la forma recomendada de usar el balanceo de carga nativo de contenedores, ya que tiene muchas funciones que simplifican la gestión de los NEGs. Las NEGs independientes son una opción si las NEGs gestionadas por Ingress no se ajustan a tu caso práctico.

NEG independientes

Cuando los NEGs se implementan con balanceadores de carga aprovisionados por cualquier otro elemento que no sea Ingress, se consideran NEGs independientes. Las NEGs independientes se implementan y gestionan a través del controlador de NEG, pero las reglas de reenvío, las comprobaciones del estado y otros objetos de balanceo de carga se implementan manualmente.

Los NEGs independientes no entran en conflicto con el balanceo de carga nativo de contenedores con Ingress habilitado.

En la siguiente ilustración se muestran las diferencias en la forma en que se implementan los objetos de balanceo de carga en cada situación:

Evitar la filtración de NEGs

Con los NEGs independientes, eres responsable de gestionar los ciclos de vida de los NEGs y los recursos que componen el balanceador de carga. Podrías filtrar NEGs de las siguientes formas:

• Cuando se elimina un servicio de GKE, el NEG asociado no se recoge como elemento no utilizado si el servicio de backend sigue haciendo referencia a él. Anula la referencia del NEG del servicio de backend para poder eliminar el NEG.

• Cuando se elimina un clúster, las NEGs independientes no se eliminan en los siguientes casos:

  • El NEG sigue haciendo referencia a un servicio de backend.
  • El proceso de eliminación del clúster cierra el controlador de NEG antes de que el controlador pueda eliminar el NEG.

  Para evitar que se filtren NEGs, anula la referencia del NEG del servicio de backend y elimina todos los NEGs antes de eliminar el clúster.

Si se han filtrado NEGs después de eliminar el clúster o el servicio, puedes eliminar los NEGs con la CLI de Google Cloud.

Casos prácticos de NEGs independientes

Los NEGs independientes tienen varios usos fundamentales. Los NEG independientes son muy flexibles. Esto contrasta con Ingress (que se usa con o sin NEGs), que define un conjunto específico de objetos de balanceo de carga que se han elegido de forma subjetiva para que sean fáciles de usar.

Estos son algunos de los casos prácticos de los NEGs independientes:

Servicios heterogéneos de contenedores y máquinas virtuales

Los NEGs pueden contener direcciones IP de máquinas virtuales y de contenedores. Esto significa que una sola dirección IP virtual puede apuntar a un backend que consta de cargas de trabajo de Kubernetes y que no son de Kubernetes. También se puede usar para migrar cargas de trabajo a un clúster de GKE.

Los NEG independientes pueden apuntar a IPs de VMs, lo que permite configurar manualmente los balanceadores de carga para que apunten a backends compuestos por VMs y contenedores del mismo VIP de servicio.

Controladores de Ingress personalizados

Puedes usar un controlador de Ingress personalizado (o ningún controlador de Ingress) para configurar balanceadores de carga que tengan como destino NEGs independientes.

Usar Cloud Service Mesh con GKE

Puedes usar Cloud Service Mesh con GKE. Cloud Service Mesh usa NEGs independientes para proporcionar balanceo de carga nativo de contenedores a la malla de servicios gestionada.

Usar balanceadores de carga de red de proxy externo con GKE

Puedes usar NEGs independientes para balancear la carga directamente en contenedores con el balanceador de carga de red de proxy externo, que no es compatible de forma nativa con Kubernetes ni GKE.

Recuperación de pods

Los gates de preparación son una función de extensibilidad de Kubernetes que permite inyectar señales o comentarios adicionales en PodStatus para que el pod pueda pasar al estado Ready. El controlador de NEG gestiona una comprobación de disponibilidad personalizada para asegurarse de que la ruta de red completa desde el balanceador de carga de Compute Engine hasta el pod funciona correctamente. Las comprobaciones de disponibilidad de los pods en GKE se explican en el artículo sobre el balanceo de carga nativo de contenedores.

Ingress con NEGs implementa y gestiona comprobaciones del estado de Compute Engine en nombre del balanceador de carga. Sin embargo, los NEGs independientes no hacen suposiciones sobre las comprobaciones de estado de Compute Engine, ya que se espera que se implementen y gestionen por separado. Las comprobaciones del estado de Compute Engine siempre deben configurarse junto con el balanceador de carga para evitar que se envíe tráfico a los backends que no estén listos para recibirlo. Si no hay ningún estado de comprobación del estado asociado al NEG (normalmente, porque no se ha configurado ninguna comprobación del estado), el controlador del NEG marcará el valor de la puerta de disponibilidad del pod como True cuando se programe su endpoint correspondiente en el NEG.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

• Asegúrate de que tienes un clúster nativo de VPC. Tu clúster debe tener habilitado el complemento HttpLoadBalancing. Los nuevos clústeres de GKE tienen el complemento HttpLoadBalancing habilitado de forma predeterminada.

  Para crear un clúster estándar, consulta Crear un clúster nativo de VPC. Los clústeres de Autopilot son nativos de VPC de forma predeterminada.

Usar NEGs independientes

En las siguientes instrucciones se explica cómo usar NEGs independientes con un balanceador de carga HTTP externo en GKE.

Debe crear los siguientes objetos:

• Una despliegue que crea y gestiona pods.
• Un servicio que crea un NEG.
• Un balanceador de carga creado con la API de Compute Engine. Esto es diferente a usar NEGs con Ingress, en cuyo caso Ingress crea y configura un balanceador de carga por ti. Con los NEGs independientes, eres responsable de asociar el NEG y el servicio de backend para conectar los pods al balanceador de carga. El balanceador de carga consta de varios componentes, que se muestran en el siguiente diagrama:

Crear un despliegue

En los siguientes manifiestos de ejemplo se especifican implementaciones que ejecutan tres instancias de un servidor HTTP en contenedores. El servidor HTTP responde a las solicitudes con el nombre de host del servidor de aplicaciones, el nombre del pod en el que se ejecuta el servidor.

Te recomendamos que uses cargas de trabajo que utilicen la señal de disponibilidad de los pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Guarda este manifiesto como neg-demo-app.yaml y, a continuación, crea el Deployment ejecutando el siguiente comando:

kubectl apply -f neg-demo-app.yaml

Crea un servicio

El siguiente manifiesto especifica un servicio en el que:

• Cualquier pod con la etiqueta run: neg-demo-app es miembro de este servicio.
• El servicio tiene un campo ServicePort con el puerto 80.
• La anotación cloud.google.com/neg especifica que el puerto 80 se asociará a un NEG. El campo opcional name especifica que el NEG se llamará NEG_NAME. Si se omite el campo name, se generará automáticamente un nombre único. Consulta cómo nombrar NEGs para obtener más información.
• Cada pod miembro debe tener un contenedor que esté escuchando en el puerto TCP 9376.

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Sustituye NEG_NAME por el nombre del NEG. El nombre del NEG debe ser único en su región.

Guarda este manifiesto como neg-demo-svc.yaml y, a continuación, crea el servicio ejecutando el siguiente comando:

kubectl apply -f neg-demo-svc.yaml

Se crea un NEG en los minutos posteriores a la creación del servicio.

Tipos de servicio

Aunque en este ejemplo se usa un servicio ClusterIP, los cinco tipos de servicios admiten NEGs independientes. Te recomendamos que uses el tipo predeterminado, ClusterIP.

Asignar nombres a los NEGs

En las versiones 1.18.18-gke.1200 y posteriores de GKE, puedes especificar un nombre personalizado para los NEGs o GKE puede generar un nombre automáticamente. Las versiones anteriores de GKE solo admiten nombres de NEG generados automáticamente.

GKE crea un NEG en cada zona que usa el clúster. Todos los NEG usan el mismo nombre.

Especificar un nombre

Si especificas un nombre de NEG personalizado, se simplifica la configuración del balanceador de carga, ya que conoces el nombre y las zonas de los NEGs de antemano. Los nombres de los NEG personalizados deben cumplir los siguientes requisitos:

• Ser único en la zona del clúster (en el caso de los clústeres zonales) o en la región (en el caso de los clústeres regionales).

• No debe coincidir con el nombre de ningún NEG que no haya creado el controlador de NEG de GKE.

• No debe contener guiones bajos.

Usa el campo name en la anotación cloud.google.com/neg del servicio para especificar un nombre de NEG:

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'

Sustituye NEG_NAME por el nombre del NEG. El nombre del NEG debe ser único en su región.

Usar un nombre generado automáticamente

Los nombres de los NEG generados automáticamente son únicos. Para usar un nombre generado automáticamente, omite el campo name:

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

El nombre generado automáticamente tiene el siguiente formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Asignar puertos a varios NEGs

Un servicio puede escuchar en más de un puerto. Por definición, los NEGs solo tienen una dirección IP y un puerto. Esto significa que, si especifica un servicio con varios puertos, se creará un NEG para cada puerto.

El formato de la anotación cloud.google.com/neg es el siguiente:

cloud.google.com/neg: '{
   "exposed_ports":{
      "SERVICE_PORT_1":{},
      "SERVICE_PORT_2":{},
      "SERVICE_PORT_3":{},
      ...
   }
 }'

En este ejemplo, cada instancia de SERVICE_PORT_N es un número de puerto distinto que hace referencia a los puertos de servicio del servicio. Por cada puerto de servicio que se indique, el controlador de NEG crea un NEG en cada zona que ocupa el clúster.

Recuperar estados de NEG

Usa el siguiente comando para obtener los estados de los servicios del clúster:

kubectl get service neg-demo-svc -o yaml

El resultado debería ser similar al siguiente:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

En este resultado, cada elemento de la asignación network-endpoint-groups es un puerto de servicio (como SERVICE_PORT_1) y el nombre de los NEGs gestionados correspondientes (como NEG_NAME_1). La lista zones contiene todas las zonas (como ZONE_1) que tienen un NEG.

El resultado debería ser similar al siguiente:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

En este ejemplo, la anotación muestra que el puerto de servicio 80 está expuesto a NEGs llamados k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

Validar la creación de un NEG

Se crea un NEG en los minutos posteriores a la creación del servicio. Si hay pods que coincidan con la etiqueta especificada en el manifiesto de servicio, al crearse, el NEG contendrá las IPs de los pods.

Hay dos formas de verificar que el NEG se ha creado y se ha configurado correctamente. En GKE 1.18.6-gke.6400 y versiones posteriores, un recurso personalizado ServiceNetworkEndpointGroup almacena información de estado sobre los NEGs creados por el controlador de servicio. En versiones anteriores, debe inspeccionar los NEGs directamente.

Recurso ServiceNetworkEndpointGroup

Para enumerar los NEGs de un clúster, obtén todos los recursos ServiceNetworkEndpointGroup:

kubectl get svcneg

Para observar el estado de un NEG, comprueba el estado del recurso ServiceNetworkEndpointGroup:

kubectl get svcneg NEG_NAME -o yaml

Sustituye NEG_NAME por el nombre del NEG que quieras inspeccionar.

El resultado de este comando incluye una sección de estado que puede contener mensajes de error. Algunos errores se registran como eventos de servicio. Para obtener más información, consulta el objeto Service:

kubectl describe service SERVICE_NAME

Sustituye SERVICE_NAME por el nombre del servicio correspondiente.

Para verificar que el controlador NEG está sincronizando correctamente el NEG, comprueba el campo status del recurso ServiceNetworkEndpointGroup para ver si hay una condición con type:Synced. La hora de la sincronización más reciente se encuentra en el campo status.lastSyncTime.

Los recursos ServiceNetworkEndpointGroup solo están disponibles en GKE 1.18 y versiones posteriores.

Inspeccionar NEGs directamente

Para verificar que el NEG existe, enumera los NEGs de tu proyecto Trusted Cloud y busca un NEG que coincida con el servicio que has creado. El nombre del NEG tiene el siguiente formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Usa el siguiente comando para enumerar los NEGs:

gcloud compute network-endpoint-groups list

El resultado debería ser similar al siguiente:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Esta salida muestra que el SIZE de NEG es 3, lo que significa que tiene tres endpoints que corresponden a los tres pods de la implementación.

Identifica los endpoints individuales con el siguiente comando:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Sustituye NEG_NAME por el nombre del NEG del que quieras mostrar los endpoints individuales.

En la salida se muestran tres endpoints, cada uno de los cuales tiene una dirección IP de Pod y un puerto:

INSTANCE                                           IP_ADDRESS  PORT
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

Asociar un balanceador de carga de aplicación externo a NEGs independientes

Puedes usar los NEG como backend de un balanceador de carga de aplicaciones externo mediante la API Compute Engine.

1. Crea una regla de cortafuegos. Los balanceadores de carga necesitan acceder a los endpoints del clúster para realizar comprobaciones del estado. Este comando crea una regla de cortafuegos para permitir el acceso:

   gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
      --network=NETWORK_NAME \
      --action=allow \
      --direction=ingress \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --rules=tcp:9376
   

   Haz los cambios siguientes:

   • NETWORK_NAME: la red en la que se ejecuta el clúster.
   • GKE_NODE_NETWORK_TAGS: las etiquetas de red de los nodos de GKE.

   Si no has creado etiquetas de red personalizadas para tus nodos, GKE generará automáticamente etiquetas por ti. Para buscar estas etiquetas generadas, ejecuta el siguiente comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Sustituye INSTANCE_NAME por el nombre de la instancia de VM de Compute Engine que ejecuta el nodo de GKE. Por ejemplo, el resultado de la sección anterior muestra los nombres de las instancias en la columna INSTANCE de los nodos de GKE.

   En el caso de los clústeres estándar, también puedes ejecutar gcloud compute instances list para enumerar todas las instancias de tu proyecto.

2. Crea una dirección IP virtual global para el balanceador de carga:

   gcloud compute addresses create hostname-server-vip \
       --ip-version=IPV4 \
       --global
   

3. Crea una comprobación del estado. El balanceador de carga usa este valor para detectar la actividad de los endpoints individuales de NEG.

   gcloud compute health-checks create http http-basic-check \
       --use-serving-port
   

4. Crea un servicio de backend que especifique que se trata de un balanceador de carga de aplicación externo global:

   gcloud compute backend-services create my-bes \
       --protocol HTTP \
       --health-checks http-basic-check \
       --global
   

5. Crea un mapa de URLs y un proxy de destino para el balanceador de carga. Este ejemplo es muy sencillo porque la aplicación serve_hostname que se usa en esta guía tiene un solo endpoint y no incluye URLs.

   gcloud compute url-maps create web-map \
       --default-service my-bes
   

   gcloud compute target-http-proxies create http-lb-proxy \
       --url-map web-map
   

6. Crea una regla de reenvío. Esto es lo que crea el balanceador de carga.

   gcloud compute forwarding-rules create http-forwarding-rule \
       --address=HOSTNAME_SERVER_VIP \
       --global \
       --target-http-proxy=http-lb-proxy \
       --ports=80
   

   Sustituye HOSTNAME_SERVER_VIP por la dirección IP que quieras usar en el balanceador de carga. Si omite --address, GKE asignará automáticamente una dirección IP efímera.

   También puedes reservar una dirección IP externa estática nueva.

Check Point

Estos son los recursos que has creado hasta ahora:

• Una dirección IP virtual externa
• Las reglas de reenvío
• Las reglas de cortafuegos
• Proxy HTTP de destino
• El mapa de URLs de la comprobación del estado de Compute Engine
• El servicio de backend
• Comprobación del estado de Compute Engine

La relación entre estos recursos se muestra en el siguiente diagrama:

Estos recursos juntos forman un balanceador de carga. En el paso siguiente, añadirá back-ends al balanceador de carga.

Una de las ventajas de los NEGs independientes que se muestran aquí es que los ciclos de vida del balanceador de carga y del backend pueden ser completamente independientes. El balanceador de carga puede seguir funcionando después de que se elimine la aplicación, sus servicios o el clúster de GKE. Puede añadir y quitar NEGs o varios NEGs del balanceador de carga sin cambiar ninguno de los objetos del balanceador de carga de frontend.

Añadir backends al balanceador de carga

Usa gcloud compute backend-services add-backend para conectar el NEG al balanceador de carga añadiéndolo como backend del servicio de backend my-bes:

gcloud compute backend-services add-backend my-bes \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 5

Haz los cambios siguientes:

• NEG_NAME: nombre del grupo de endpoints de red. El nombre es el que especificaste al crear el NEG o un nombre generado automáticamente. Si no has especificado un nombre para el NEG, consulta las siguientes instrucciones para encontrar el nombre generado automáticamente.
• NEG_ZONE: la zona en la que se encuentra tu grupo de endpoints de red. Sigue las instrucciones que se indican a continuación para encontrar este valor.

Usa este comando para obtener el nombre y la ubicación del NEG:

gcloud compute network-endpoint-groups list

El resultado debería ser similar al siguiente:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

En este ejemplo, el nombre del NEG es k8s1-70aa83a6-default-my-service-80-c9710a6f.

Se pueden añadir varias NEGs al mismo servicio de backend. Los servicios backend globales, como my-bes, pueden tener backends de NEG en diferentes regiones, mientras que los servicios backend regionales deben tener backends en una sola región.

Validar que el balanceador de carga funciona

Hay dos formas de validar que el balanceador de carga que ha configurado funciona:

• Comprueba que la comprobación del estado esté configurada correctamente y que indique que el estado es correcto.
• Accede a la aplicación y verifica su respuesta.

Verificar comprobaciones del estado

Comprueba que el servicio de backend esté asociado a la comprobación de estado y a los grupos de endpoints de red, y que los endpoints individuales estén en buen estado.

Usa este comando para comprobar que el servicio de backend está asociado a tu comprobación de estado y a tu grupo de puntos finales de red:

gcloud compute backend-services describe my-bes --global

El resultado debería ser similar al siguiente:

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

A continuación, comprueba el estado de los endpoints individuales:

gcloud compute backend-services get-health my-bes --global

La sección status: de la salida es similar a la siguiente:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Acceder a la aplicación

Accede a la aplicación a través de la dirección IP del balanceador de carga para confirmar que todo funciona correctamente.

Primero, obtén la dirección IP virtual del balanceador de carga:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

El resultado incluirá una dirección IP. A continuación, envía una solicitud a esa dirección IP (34.98.102.37 en este ejemplo):

curl 34.98.102.37

La respuesta de la aplicación serve_hostname debe ser neg-demo-app.

Asociar un balanceador de carga de aplicaciones interno a NEGs independientes

Puedes usar NEGs para configurar un balanceador de carga de aplicaciones interno para los servicios que se ejecutan en pods de GKE independientes.

Configurar la subred de solo proxy

La subred de solo proxy es para todos los balanceadores de carga de aplicaciones internos regionales de la región del balanceador de carga.

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=lb-network \
    --range=10.129.0.0/23

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Configurar reglas de cortafuegos

En este ejemplo se usan las siguientes reglas de cortafuegos:

• fw-allow-ssh: una regla de entrada aplicable a las instancias que se van a balancear, que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puede elegir un intervalo de IPs de origen más restrictivo para esta regla. Por ejemplo, puedes especificar solo los intervalos de direcciones IP del sistema desde el que inicias sesiones SSH. En este ejemplo se usa la etiqueta de destino allow-ssh para identificar las VMs a las que se aplica la regla de cortafuegos.

• fw-allow-health-check: una regla de entrada, aplicable a las instancias con balanceo de carga, que permite todo el tráfico TCP de los sistemas de comprobación de estado (en 130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las instancias a las que se debe aplicar. Trusted Cloud

• fw-allow-proxies: una regla de entrada aplicable a las instancias con balanceo de carga que permite el tráfico TCP en el puerto 9376 de los proxies gestionados del balanceador de carga HTTP(S) interno. En este ejemplo se usa la etiqueta de destino load-balanced-backend para identificar las instancias a las que se debe aplicar.

Sin estas reglas de cortafuegos, la regla denegar predeterminada de entrada bloquea el tráfico entrante a las instancias de backend.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

Configurar el balanceador de carga

En la dirección IP de la regla de reenvío, usa una subred de backend. Si intenta usar la subred de solo proxy, no podrá crear la regla de reenvío.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Pruebas

Crea una instancia de VM en la zona para probar la conectividad:

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Inicia sesión en la instancia de cliente para comprobar que se puede acceder a los servicios HTTP(S) de los back-ends mediante la dirección IP de la regla de reenvío del balanceador de carga de aplicaciones interno y que el tráfico se está balanceando entre los endpoints del NEG.

Conéctate a cada instancia de cliente mediante SSH:

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

Verifica que la IP esté sirviendo su nombre de host:

curl 10.1.2.199

Para probar HTTPS, ejecuta el siguiente comando:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

La marca -k hace que curl omita la validación del certificado.

Ejecuta 100 solicitudes y confirma que se han balanceado.

En HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Para HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Asociar un balanceador de carga de red con proxy externo a NEGs independientes

Puedes usar NEGs independientes para balancear la carga directamente a los contenedores con el balanceador de carga de red del proxy externo, que no es compatible de forma nativa con Kubernetes ni con GKE. Los balanceadores de carga de red de proxy están diseñados para el tráfico TCP únicamente, con o sin SSL. Si el tráfico es HTTP o HTTPS, te recomendamos que uses un balanceador de carga de aplicaciones.

1. Crea una regla de cortafuegos para permitir las comprobaciones del estado.

   Los balanceadores de carga necesitan acceder a los endpoints del clúster para realizar comprobaciones de estado. El siguiente comando crea una regla de cortafuegos para permitir el acceso:

   gcloud compute firewall-rules create allow-tcp-lb-and-health \
      --network=NETWORK_NAME \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --allow tcp:9376
   

   Haz los cambios siguientes:

   • NETWORK_NAME: la red en la que se ejecuta el clúster.
   • GKE_NODE_NETWORK_TAGS: las etiquetas de red de los nodos de GKE.

   Si no ha creado etiquetas de red personalizadas para sus nodos, GKE las generará automáticamente. Para buscar estas etiquetas generadas, ejecuta el siguiente comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Sustituye INSTANCE_NAME por el nombre de la instancia de VM de Compute Engine que ejecuta el nodo de GKE. Por ejemplo, el resultado de la sección Inspeccionar NEGs directamente muestra los nombres de las instancias en la columna INSTANCE de los nodos de GKE.

   En los clústeres estándar, también puedes ejecutar el comando gcloud compute instances list para enumerar todas las instancias de tu proyecto.

   En los clústeres de Autopilot, debes orientar la cuenta de servicio del clúster en lugar de las etiquetas de red.

   Sustituye la marca --target-tags=GKE_NODE_NETWORK_TAGS por --target-service-accounts=SERVICE_ACCOUNT_EMAIL. Te recomendamos que uses una cuenta de servicio personalizada con el número mínimo de privilegios necesarios para el clúster.

2. Crea una dirección IP virtual global para el balanceador de carga:

   gcloud compute addresses create tcp-lb-static-ipv4 \
      --ip-version=IPV4 \
      --global
   

3. Define una comprobación del estado para los endpoints de backend.

   El balanceador de carga usa comprobaciones de estado para detectar la actividad de los puntos finales individuales de la NEG.

   gcloud compute health-checks create tcp my-tcp-health-check \
      --use-serving-port
   

4. Crea un servicio de backend con afinidad de sesión.

   Este servicio de backend especifica que se trata de un balanceador de carga de red de proxy externo con CLIENT_IP afinidad de sesión:

   gcloud compute backend-services create my-tcp-lb \
      --load-balancing-scheme EXTERNAL_MANAGED \
      --global-health-checks \
      --global \
      --protocol TCP \
      --health-checks my-tcp-health-check \
      --timeout 5m \
      --session-affinity=CLIENT_IP
   

5. Crea un proxy TCP de destino para el balanceador de carga.

   Si quieres activar el encabezado de proxy, asígnale el valor PROXY_V1 en lugar de NONE.

   gcloud beta compute target-tcp-proxies create my-tcp-lb-target-proxy \
       --backend-service my-tcp-lb \
       --proxy-header NONE
   

6. Crea una regla de reenvío para enrutar el tráfico.

   Esta regla de reenvío crea el balanceador de carga.

    gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
       --load-balancing-scheme EXTERNAL_MANAGED \
       --global \
       --target-tcp-proxy my-tcp-lb-target-proxy \
       --address tcp-lb-static-ipv4 \
       --ports 80
   

Verificar la creación de recursos del balanceador de carga

Has creado los siguientes recursos:

• Una dirección IP virtual externa
• La regla de reenvío
• La regla de cortafuegos
• El proxy de destino
• El servicio de backend
• Comprobación del estado de Compute Engine

La dirección IP virtual externa está conectada a la regla de reenvío, que dirige el tráfico permitido por la regla de cortafuegos al proxy de destino. A continuación, el proxy de destino se comunica con el servicio de backend, que se comprueba periódicamente mediante la comprobación de estado. La relación entre estos recursos se muestra en el siguiente diagrama:

Estos recursos juntos forman un balanceador de carga. En el paso siguiente, añadirá back-ends al balanceador de carga.

Una de las ventajas de los NEG independientes que se muestran aquí es que los ciclos de vida del balanceador de carga y del backend pueden ser completamente independientes. El balanceador de carga puede seguir funcionando después de que se elimine la aplicación, sus servicios o el clúster de GKE. Puede añadir y quitar NEGs o varios NEGs del balanceador de carga sin cambiar ninguno de los objetos del balanceador de carga de frontend.

Añadir NEGs independientes como backends al balanceador de carga

Usa gcloud compute backend-services add-backend para conectar el NEG al balanceador de carga añadiéndolo como backend del servicio de backend my-tcp-lb:

gcloud compute backend-services add-backend my-tcp-lb \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode CONNECTION \
    --max-connections 100

Haz los cambios siguientes:

• NEG_NAME: nombre del grupo de endpoints de red. El nombre es el que especificaste al crear el NEG o un nombre generado automáticamente. Si no has especificado un nombre para el NEG, consulta las siguientes instrucciones para encontrar el nombre generado automáticamente.
• NEG_ZONE: la zona en la que se encuentra tu grupo de endpoints de red. Sigue las instrucciones que se indican a continuación para encontrar este valor.

Para obtener el nombre y la ubicación de los NEGs, usa este comando:

gcloud compute network-endpoint-groups list

El resultado debería ser similar al siguiente:

NAME: k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
LOCATION: us-central1-a
ENDPOINT_TYPE: GCE_VM_IP_PORT
SIZE: 3

En este ejemplo, el nombre del NEG es kk8s1-65a95e90-default-neg-demo-svc-80-663a85e4 y la zona es us-central1-a.

Se pueden añadir varias NEGs al mismo servicio de backend. Los servicios de backend globales, como my-tcp-lb, pueden tener backends de NEG en diferentes regiones, mientras que los servicios de backend regionales deben tener backends en una sola región.

Verificar la configuración y la conectividad del balanceador de carga

Hay dos formas de validar que el balanceador de carga que ha configurado funciona:

• Comprueba que la comprobación del estado esté configurada correctamente y que indique que el estado es correcto.
• Accede a la aplicación y verifica su respuesta.

Verificar comprobaciones del estado

Comprueba que el servicio de backend esté asociado a la comprobación de estado y a los grupos de endpoints de red, y que los endpoints individuales estén en buen estado.

Para comprobar que el servicio backend está asociado a tu comprobación de estado y a tu grupo de endpoints de red, usa este comando:

gcloud compute backend-services describe my-tcp-lb --global

El resultado debería ser similar al siguiente:

backends:
- balancingMode: CONNECTION
  group: ... /networkEndpointGroups/k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
  maxConnections: 100
...
healthChecks:
- ... /healthChecks/my-tcp-health-check
...
name: my-tcp-lb
...

A continuación, comprueba el estado de los endpoints individuales:

gcloud compute backend-services get-health my-tcp-lb --global

La sección status: de la salida es similar a la siguiente:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Verificar la conectividad de la aplicación

Para verificar que el balanceador de carga funciona correctamente, accede a la aplicación a través de la dirección IP externa del balanceador de carga.

1. Obtén la dirección IP externa del balanceador de carga:

   Para obtener la dirección IP externa que has reservado para el balanceador de carga, usa el siguiente comando:

   gcloud compute addresses describe tcp-lb-static-ipv4 --global | grep "address:"
   

   Este comando muestra la dirección IP.

2. Envía una solicitud a la dirección IP:

   Usa el comando curl para enviar una solicitud a la dirección IP externa.

   curl EXTERNAL_IP_ADDRESS
   

   Sustituye EXTERNAL_IP_ADDRESS por la dirección IP que has obtenido en el paso anterior:

   La respuesta de la aplicación serve_hostname debe empezar por neg-demo-app.

Implementar servicios heterogéneos (máquinas virtuales y contenedores)

Los balanceadores de carga pueden ser front-ends de cargas de trabajo mixtas de Kubernetes y no Kubernetes. Esto podría formar parte de una migración de máquinas virtuales a contenedores o de una arquitectura permanente que se beneficie de un balanceador de carga compartido. Para ello, puede crear balanceadores de carga que se dirijan a diferentes tipos de back-ends, incluidos los NEG independientes.

VMs y contenedores en el mismo servicio de backend

En este ejemplo se muestra cómo crear un NEG que apunte a una VM que ya esté ejecutando una carga de trabajo y cómo añadir este NEG como otro backend de un backendService. De esta forma, un único balanceador de carga equilibra la carga entre las VMs y los contenedores de GKE.

En este ejemplo se amplía el ejemplo anterior, que usa un balanceador de carga HTTP externo.

Como todos los puntos finales se agrupan por el mismo backendService, los puntos finales de la VM y del contenedor se consideran el mismo servicio. Esto significa que la coincidencia de host o de ruta tratará todos los back-ends de forma idéntica en función de las reglas del mapa de URLs.

Cuando usas un NEG como backend de un servicio de backend, todos los demás backends de ese servicio de backend también deben ser NEGs. No puedes usar grupos de instancias y NEGs como backends en el mismo servicio de backend. Además, los contenedores y las VMs no pueden existir como endpoints en el mismo NEG, por lo que siempre deben configurarse con NEGs independientes.

1. Despliega una máquina virtual en Compute Engine con este comando:

   gcloud compute instances create vm1 \
       --zone=COMPUTE_ZONE \
       --network=NETWORK \
       --subnet=SUBNET \
       --image-project=cos-cloud \
       --image-family=cos-stable --tags=vm-neg-tag
   

   Haz los cambios siguientes:

   • COMPUTE_ZONE: el nombre de la zona.
   • NETWORK: el nombre de la red.
   • SUBNET: nombre de la subred asociada a la red.

2. Despliega una aplicación en la VM:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
   

   Este comando implementa en la VM la misma aplicación de ejemplo que se ha usado en el ejemplo anterior. Para simplificar, la aplicación se ejecuta como un contenedor Docker, pero no es esencial. El comando iptables es necesario para permitir el acceso del firewall al contenedor en ejecución.

3. Valida que la aplicación esté sirviendo en el puerto 9376 e informa de que se está ejecutando en vm1:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="curl -s localhost:9376"
   

   El servidor debe responder con vm1.

4. Crea un NEG para usarlo con el endpoint de la VM. Los contenedores y las VMs pueden ser endpoints de NEG, pero un mismo NEG no puede tener endpoints de VMs y de contenedores.

   gcloud compute network-endpoint-groups create vm-neg \
       --subnet=SUBNET \
       --zone=COMPUTE_ZONE
   

5. Vincula el endpoint de la VM al NEG:

   gcloud compute network-endpoint-groups update vm-neg \
       --zone=COMPUTE_ZONE \
       --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
   

   Sustituye VM_PRIMARY_IP por la dirección IP principal de la VM.

6. Confirma que el NEG tiene el endpoint de la VM:

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
       --zone COMPUTE_ZONE
   

7. Asocia el NEG al servicio de backend con el mismo comando que usaste para añadir un backend de contenedor:

   gcloud compute backend-services add-backend my-bes
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

8. Abre el cortafuegos para permitir la comprobación del estado de la VM:

   gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
       --network=NETWORK \
       --action=allow \
       --direction=ingress \
       --target-tags=vm-neg-tag \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp:9376
   

9. Valida que el balanceador de carga reenvía el tráfico tanto al nuevo backend vm1 como al backend de contenedor actual enviando tráfico de prueba:

   for i in `seq 1 100`; do curl ${VIP};echo; done
   

   Deberías ver respuestas de los endpoints del contenedor (neg-demo-app) y de la VM (vm1).

Máquinas virtuales y contenedores para diferentes servicios de backend

En este ejemplo se muestra cómo crear un NEG que apunte a una VM que ya esté ejecutando una carga de trabajo y cómo añadir este NEG como backend a un backendService nuevo. Esto es útil en los casos en los que los contenedores y las VMs son servicios diferentes, pero necesitan compartir el mismo balanceador de carga de nivel 7, como si los servicios compartieran la misma dirección IP o el mismo nombre de dominio.

En este ejemplo se amplía el ejemplo anterior, que tiene un backend de VM en el mismo servicio de backend que el backend de contenedor. En este ejemplo, se reutiliza esa VM.

Como los endpoints de contenedor y de VM se agrupan en servicios de backend independientes, se consideran servicios diferentes. Esto significa que el mapa de URLs coincidirá con los back-ends y dirigirá el tráfico a la máquina virtual o al contenedor en función del nombre de host.

En el siguiente diagrama se muestra cómo una única dirección IP virtual se corresponde con dos nombres de host, que a su vez se corresponden con un servicio de backend basado en contenedores y un servicio de backend basado en VMs.

En el siguiente diagrama se muestra la arquitectura descrita en la sección anterior:

1. Crea un servicio de backend para la VM:

   gcloud compute backend-services create my-vm-bes \
      --protocol HTTP \
      --health-checks http-basic-check \
      --global
   

2. Asocia el NEG de la VM, vm-neg, al servicio de backend:

   gcloud compute backend-services add-backend my-vm-bes \
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

3. Añade una regla de host al mapa de URLs para dirigir las solicitudes del host container.example.com al servicio de backend del contenedor:

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=container-path --default-service=my-bes \
       --new-hosts=container.example.com --global
   

4. Añade otra regla de host al mapa de URLs para dirigir las solicitudes de vm.example.com host al servicio de backend de la VM:

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=vm-path --default-service=my-vm-bes \
       --new-hosts=vm.example.com --global
   

5. Valida que el balanceador de carga envía tráfico al backend de la VM en función de la ruta solicitada:

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   Sustituye VIRTUAL_IP por la dirección IP virtual.

Limitaciones de los NEGs independientes

• Los errores de validación de las anotaciones se muestran al usuario a través de eventos de Kubernetes.
• Las limitaciones de los NEGs también se aplican a los NEGs independientes.
• Los NEGs independientes no funcionan con las redes antiguas.
• Los NEGs independientes solo se pueden usar con servicios de red compatibles, como Cloud Service Mesh y los tipos de balanceadores de carga compatibles.

Solución de problemas

En esta sección se describen los pasos para solucionar problemas habituales que pueden surgir con los NEGs independientes.

No se ha configurado ningún NEG independiente

Síntoma: no se crea ningún NEG.

Posible solución:

• Consulta los eventos asociados al servicio y busca mensajes de error.
• Verifica que la anotación NEG independiente tenga el formato JSON correcto y que los puertos expuestos coincidan con los puertos de la especificación del servicio.
• Verifica la anotación de estado de NEG y comprueba si los puertos de servicio esperados tienen los NEGs correspondientes.
• Verifica que se hayan creado los NEGs en las zonas esperadas con el comando gcloud compute network-endpoint-groups list.
• Si usas la versión 1.18 de GKE o una posterior, comprueba si existe el recurso svcneg del servicio. Si es así, comprueba la Initialized condición para ver si hay información sobre errores.
• Si usas nombres de NEG personalizados, asegúrate de que cada nombre de NEG sea único en su región.

El tráfico no llega a los endpoints

Síntoma: errores 502 o conexiones rechazadas.

Posible solución:

• Una vez configurado el servicio, los nuevos endpoints se podrán alcanzar generalmente después de adjuntarlos al NEG, siempre que respondan a las comprobaciones de estado.
• Si, transcurrido ese tiempo, el tráfico sigue sin llegar a los endpoints y se devuelve el código de error 502 para HTTP(S) o se rechazan las conexiones de los balanceadores de carga TCP o SSL, comprueba lo siguiente:
  • Verifica que las reglas de cortafuegos permitan el tráfico TCP entrante a tus endpoints desde los siguientes intervalos: 130.211.0.0/22 y 35.191.0.0/16.
  • Verifica que tus endpoints estén en buen estado con la CLI de Google Cloud o llamando a la API getHealth en backendService o a la API listEndpoints en el NEG con el parámetro showHealth definido como SHOW.

Lanzamiento detenido

Síntoma: la implementación de una actualización se detiene y el número de réplicas actualizadas no coincide con el número de réplicas elegido.

Posible solución:

Las comprobaciones del estado de la implementación están fallando. Es posible que la imagen del contenedor sea incorrecta o que la comprobación de estado esté mal configurada. La sustitución gradual de pods espera hasta que el pod recién iniciado supere su puerta de disponibilidad. Esto solo ocurre si el pod responde a las comprobaciones del estado del balanceador de carga. Si el pod no responde o si la comprobación de estado está mal configurada, no se podrán cumplir las condiciones de la puerta de disponibilidad y no se podrá continuar con el lanzamiento.

• Si usas kubectl 1.13 o una versión posterior, puedes comprobar el estado de las readiness gates de un pod con el siguiente comando:

  kubectl get my-Pod -o wide
  

  Consulta la columna READINESS GATES (Puertas de preparación).

  Esta columna no existe en kubectl 1.12 ni en versiones anteriores. Un pod marcado como en estado READY puede tener una puerta de disponibilidad fallida. Para verificarlo, usa el siguiente comando:

  kubectl get my-pod -o yaml
  

  Los readiness gates y su estado se muestran en el resultado.

• Verifica que la imagen del contenedor de la especificación del pod de tu Deployment funcione correctamente y pueda responder a las comprobaciones de estado.

• Verifica que las comprobaciones de estado estén configuradas correctamente.

El NEG no se recoge como elemento residual

Síntoma: sigue existiendo un NEG que debería haberse eliminado.

Posible solución:

• El NEG no se recoge como elemento no utilizado si un servicio de backend hace referencia a él. Consulta más información sobre cómo evitar que se filtren NEGs.
• Si usas la versión 1.18 o una posterior, puedes buscar eventos en el recurso ServiceNetworkEndpointGroup mediante el procedimiento de negociación de servicios.
• Comprueba si un servicio sigue necesitando el NEG. Consulta el recurso svcneg del servicio que corresponde al NEG y comprueba si existe una anotación Service.

El NEG no está sincronizado con el servicio

Síntoma: los endpoints esperados (IP de pod) no existen en el NEG, el NEG no está sincronizado o se produce el error Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description.

Posible solución:

Si usas GKE 1.18 o una versión posterior, consulta el recurso svcneg para obtener información:

• Comprueba el valor de status.lastSyncTime para verificar si el NEG se ha sincronizado recientemente.
• Comprueba la condición Synced para ver si se han producido errores en la sincronización más reciente.

Si usas GKE 1.19.9 o una versión posterior, comprueba si existe un NEG cuyo nombre y zona coincidan con el nombre y la zona del NEG que el controlador de NEG de GKE necesita crear. Por ejemplo, es posible que se haya creado un NEG con el nombre que necesita usar el controlador de NEG mediante la CLI de gcloud o la Trusted Cloud consola en la zona del clúster (o en una de las zonas del clúster). En este caso, debes eliminar el NEG antes de que el controlador del NEG pueda sincronizar sus endpoints. El controlador de NEG se encarga de crear y gestionar los NEG independientes.

Siguientes pasos

• Información general sobre los grupos de puntos finales de red por zonas
• Servicios de backend
• Crear comprobaciones del estado
• Usar proxies de destino
• Usar reglas de reenvío