Balanceo de cargas nativo del contenedor mediante NEG zonales independientes

En esta página, se muestra cómo crear un Service de Kubernetes con el respaldo de un grupo de extremos de red (NEG) zonal GCE_VM_IP_PORT en un clúster nativo de la VPC de Google Kubernetes Engine (GKE).

Para obtener información sobre los beneficios, los requisitos y las limitaciones del balanceo de cargas nativo del contenedor, consulta Balanceo de cargas nativo del contenedor.

Descripción general

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

En el contexto de un clúster nativo de la VPC de GKE con NEG independientes, cada extremo es una dirección IP de Pod y un puerto de destino. Las direcciones IP de Pod se originan del rango de IP de alias del nodo para los Pods, que proviene del rango de direcciones IP secundario de la subred de los Pods del clúster.

GKE proporciona un controlador de NEG para administrar la membresía de los NEG de GCE_VM_IP_PORT. Puedes agregar los NEG que crea como backends a los servicios de backend para los balanceadores de cargas que configuras 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 NEG

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

Ingress es la forma recomendada de usar el balanceo de cargas nativo del contenedor, ya que tiene muchas funciones que simplifican la administración de los NEG. También, existe la opción de los NEG independientes si los NEG que administra Ingress no sirven para tu caso de uso.

NEG independientes

Cuando los NEG se implementan con balanceadores de cargas y no es Ingress el que los aprovisiona, se consideran NEG independientes. Los NEG independientes se implementan y administran a través del controlador de NEG, pero las reglas de reenvío, las verificaciones de estado y otros objetos de balanceo de cargas se implementan de forma manual.

Los NEG independientes no entran en conflicto con el balanceo de cargas nativo del contenedor habilitado de Ingress.

En la siguiente ilustración, se muestran las distintas formas en que se implementan los objetos de balanceo de cargas en cada situación:

Evita filtraciones de NEG

Con los NEG independientes, eres responsable de administrar los ciclos de vida de los NEG y los recursos que conforman el balanceador de cargas. Puedes filtrar NEG de las siguientes maneras:

• Cuando se borra un servicio de GKE, el NEG asociado no se recolectará como elemento no utilizado si un servicio de backend aún hace referencia a este NEG. Quita la referencia del NEG del servicio de backend para permitir la eliminación del NEG.
• Cuando se borra un clúster, no se borran los NEG independientes.

Casos de uso de NEG independientes

Los NEG independientes tienen varios usos críticos. Son muy flexibles. Esto contrasta con Ingress (este se usa con o sin NEG), que define un conjunto específico de objetos de balanceo de cargas que se eligieron de una manera bien definida para facilitar su uso.

Los casos prácticos para los NEG independientes incluyen los siguientes:

Servicios heterogéneos de contenedores y VM

Los NEG pueden contener direcciones IP de contenedores y VM. Esto significa que una sola dirección IP virtual puede apuntar a un backend que consta de cargas de trabajo de Kubernetes y de cargas de trabajo que no son de Kubernetes. Esto también se puede usar para migrar las cargas de trabajo existentes a un clúster de GKE.

Los NEG independientes pueden apuntar a las IP de VM, lo que permite configurar de forma manual los balanceadores de cargas para que apunten a backends que se componen por VM y contenedores de la misma VIP de servicio.

Controladores de Ingress personalizados

Puedes usar un controlador de Ingress personalizado (o que no sea de Ingress) para configurar balanceadores de cargas que se dirigen a los NEG independientes.

Usa Cloud Service Mesh con GKE

Puedes usar Cloud Service Mesh con GKE. Cloud Service Mesh usa NEG independientes para proporcionar balanceo de cargas nativo del contenedor para la malla de servicios administrados.

Usa balanceadores de cargas de red del proxy externos con GKE

Puedes usar NEG independientes para balancear las cargas directamente a los contenedores con el balanceador de cargas de red de proxy externo que no es compatible de forma nativa con Kubernetes/GKE.

Preparación del pod

Las Puertas de preparación son una función de extensibilidad de Kubernetes que permite la inserción de comentarios o indicadores adicionales en el PodStatus para permitir que el pod pase al estado Listo. El controlador de NEG administra una puerta de preparación personalizada para garantizar que toda la ruta de red, desde el balanceador de cargas de Compute Engine hasta el pod, sea funcional. Las puertas de preparación de pods en GKE se explican en el balanceo de cargas nativo del contenedor.

Ingress con NEG implementa y administra las verificaciones de estado de Compute Engine en nombre del balanceador de cargas. Sin embargo, los NEG independientes no realizan suposiciones sobre las verificaciones de estado de Compute Engine porque se espera que se implementen y administren por separado. Las verificaciones de estado de Compute Engine siempre deben configurarse junto con el balanceador de cargas a fin de evitar que el tráfico se envíe a los backends que no estén listos para recibir. Si no hay un estado de verificación de estado asociado con el NEG (por lo general, porque no se configuró ninguna verificación de estado), el controlador de NEG marcará el valor de la puerta de preparación de Pods como Verdadero cuando se programe su extremo correspondiente en NEG.

Requisitos

Tu clúster debe ser nativo de VPC. Si quieres obtener más información, consulta Cómo crear un clúster nativo de la VPC.

El clúster debe tener el complemento HttpLoadBalancing habilitado. Los clústeres de GKE tienen el complemento HttpLoadBalancing habilitado de forma predeterminada.

Antes de comenzar

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

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

Usa NEG independientes

En las siguientes instrucciones, se muestra cómo usar los NEG independientes con un balanceador de cargas de HTTP externo en GKE.

Debes crear los siguientes objetos:

• Un Deployment{track-name="k8sLink" track-type="concept"} que crea y administra Pods.
• Un Service que crea un NEG
• Un balanceador de cargas creado con la API de Compute Engine. Esto difiere del uso de NEG con Ingress, en cuyo caso Ingress es el que crea y configura un balanceador de cargas. Con los NEG independientes, eres el responsable de asociar el NEG y el servicio de backend para conectar los pods al balanceador de cargas. El balanceador de cargas consta de varios componentes, que se muestran en el siguiente diagrama:

Crea un clúster nativo de la VPC

Los clústeres de Autopilot son nativos de la VPC de forma predeterminada, por lo que puedes pasar a Implementa una carga de trabajo.

Para los clústeres estándar, crea un clúster nativo de la VPC en la zona us-central1-a:

gcloud container clusters create neg-demo-cluster \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a

Crear una implementación

En los siguientes manifiestos de ejemplo, se especifican implementaciones que ejecutan tres instancias de un servidor HTTP alojado en contenedor. 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.

Recomendamos que uses cargas de trabajo que utilicen comentarios de preparación de 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, luego, crea la implementación con la ejecución del siguiente comando:

kubectl apply -f neg-demo-app.yaml

Crea un Service

El siguiente manifiesto especifica un objeto Service en el que:

• Cualquier Pod que tenga la etiqueta run: neg-demo-app es miembro de este Service.
• El Service tiene un campo ServicePort con el puerto 80.
• La anotación cloud.google.com/neg especifica que el puerto 80 se asociará con un NEG. En el campo opcional name, se especifica que el NEG se llamará NEG_NAME. Si se omite el campo name, se generará un nombre único de forma automática. Consulta cómo cambiar el nombre de los NEG para obtener más detalles.
• Cada Pod miembro debe tener un contenedor que escuche 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

Reemplaza NEG_NAME con el nombre para el NEG. El nombre de NEG debe ser único en su región.

Guarda este manifiesto como neg-demo-svc.yaml y crea el Service con la ejecución del siguiente comando:

kubectl apply -f neg-demo-svc.yaml

Un NEG se crea en pocos minutos durante la creación del Service.

Tipos de servicios

Si bien en este ejemplo se usa un Service ClusterIP, los cinco tipos de Service admiten NEG independientes. Recomendamos el tipo predeterminado, ClusterIP.

Nombra NEG

En 1.18.18-gke.1200 y versiones posteriores de GKE, puedes especificar un nombre personalizado para los NEG o GKE puede generar un nombre de forma automática. 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.

Especifica un nombre

La especificación de un nombre de NEG personalizado simplifica la configuración del balanceador de cargas porque conoces de forma anticipada el nombre y las zonas de los NEG. Los nombres de NEG personalizados deben cumplir los siguientes requisitos:

• Deben ser únicos en la zona del clúster para los clústeres zonales o en la región para los clústeres regionales.

• No deben coincidir con el nombre de ningún NEG existente que no haya creado el controlador de NEG de GKE.
• No debe incluir guiones bajos.

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

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

Reemplaza NEG_NAME con el nombre para el NEG. El nombre de NEG debe ser único en su región.

Usa un nombre generado automáticamente

Se garantiza que los nombres de NEG generados automáticamente serán únicos. Para usar un nombre generado automáticamente, omite el campo name como sigue:

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

El nombre generado automáticamente tiene el siguiente formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Mapea puertos a varios NEG

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

A continuación, se muestra el formato de la anotación cloud.google.com/neg:

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 existentes del Service. Para cada puerto de servicio enumerado, el controlador de NEG crea un NEG en cada zona que ocupa el clúster.

Recupera estados de NEG

Usa el siguiente comando para recuperar los estados de los objetos Service del clúster:

kubectl get service neg-demo-svc -o yaml

El resultado es similar a este:

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 NEG administrados correspondientes (como NEG_NAME_1). La lista zones contiene todas las zonas (como ZONE_1) que tienen un NEG en ella.

El resultado es 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 los NEG llamados k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

Valida la creación de NEG

Un NEG se crea en pocos minutos durante la creación del Service. Si hay pods que coinciden con la etiqueta que se especifica en el manifiesto de Service, el NEG contendrá las IP de los pods después de su creación.

Hay dos maneras de verificar que el NEG se haya creado y esté configurado correctamente. En GKE 1.18.6-gke.6400 y versiones posteriores, un recurso personalizado ServiceNetworkEndpointGroup almacena información de estado sobre los NEG que creó el controlador de servicio. En versiones anteriores, debes inspeccionar los NEG directamente.

El recurso ServiceNetworkEndpointGroup

Genera una lista de todos los NEG en un clúster mediante la obtención de todos los recursos ServiceNetworkEndpointGroup:

kubectl get svcneg

Observa el estado de un NEG mediante la verificación del estado del recurso ServiceNetworkEndpointGroup:

kubectl get svcneg NEG_NAME -o yaml

Reemplaza NEG_NAME por el nombre del NEG individual que deseas inspeccionar.

El resultado de este comando incluye una sección de estado que puede contener mensajes de error. Algunos errores se informan como un evento de Service. Puedes obtener más detalles si consultas el objeto de Service:

kubectl describe service SERVICE_NAME

Reemplaza SERVICE_NAME con el nombre del Service correspondiente.

Para verificar que el controlador NEG sincroniza de forma correcta el NEG, comprueba el campo de estado del recurso ServiceNetworkEndpointGroup para obtener una condición con type:Synced. La hora de la sincronización más reciente está en el campo status.lastSyncTime.

Los recursos ServiceNetworkEndpointGroup solo existen en GKE 1.18 y versiones posteriores.

Inspecciona NEG directamente

Para verificar que el NEG exista debes enumerar los NEG en tu proyecto de Google Cloud y verificar si hay un NEG que coincida con el Service que creaste. El nombre del NEG tiene el siguiente formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Usa el siguiente comando para enumerar los NEG:

gcloud compute network-endpoint-groups list

El resultado es similar a este:

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

Este resultado muestra que el NEG tiene un SIZE de 3, lo que significa que tiene tres extremos que corresponden a los tres pods en el Deployment.

Identifica los extremos individuales con el siguiente comando:

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

Reemplaza NEG_NAME con el nombre del NEG para el que deseas mostrar los extremos individuales.

En el resultado, se muestran tres extremos, cada uno de los cuales tiene una dirección IP y un puerto de Pod:

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

Adjunta un balanceador de cargas de aplicaciones externo a NEG independientes

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

1. Cree una regla de firewall. Los balanceadores de cargas deben acceder a los extremos del clúster para realizar verificaciones de estado. Este comando crea una regla de firewall 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
   

   Reemplaza lo siguiente:

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

   Si no creaste etiquetas de red personalizadas para tus nodos, GKE genera etiquetas de forma automática para ti. Puedes buscar estas etiquetas generadas si ejecutas el siguiente comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Reemplaza INSTANCE_NAME por el nombre de la instancia de VM de Compute Engine del host 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 para 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 en el proyecto.

2. Crea una dirección IP virtual global para el balanceador de cargas con el siguiente comando:

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

3. Crea una verificación de estado. El balanceador de cargas la usa para detectar los extremos individuales en funcionamiento dentro del NEG.

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

4. Crea un servicio de backend que especifique que este es un balanceador de cargas de aplicaciones externo global:

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

5. Crea un mapa de URL y un proxy de destino para el balanceador de cargas. Este ejemplo es muy simple porque la app serve_hostname que se usa para esta guía tiene un solo extremo y no presenta 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 cargas.

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

   Reemplaza HOSTNAME_SERVER_VIP por la dirección IP para usar en el balanceador de cargas. Si omites --address, GKE asigna de forma automática una dirección IP efímera. También puedes reservar una nueva dirección IP externa estática.

Punto de control

Estos son los recursos que creaste hasta el momento:

• Una dirección IP virtual externa
• Las reglas de reenvío
• Las reglas de firewall
• El proxy HTTP de destino
• El mapa de URL y la verificación de estado de Compute Engine
• El servicio de backend
• La verificación de estado de Compute Engine

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

Estos recursos juntos conforman un balanceador de cargas. En el siguiente paso, agregarás backends al balanceador de cargas.

Uno de los beneficios de los NEG independientes que se demuestran aquí es que los ciclos de vida del balanceador de cargas y el backend pueden ser completamente independientes. El balanceador de cargas puede seguir en ejecución después de que se borra la aplicación, sus objetos Service o el clúster de GKE. Puedes agregar y quitar NEG nuevos o varios NEG del balanceador de cargas sin cambiar ninguno de los objetos del balanceador de cargas de frontend.

Agrega backends al balanceador de cargas

Usa gcloud compute backend-services add-backend a fin de conectar el NEG al balanceador de cargas. Para ello, agrégalo como un backend del servicio de backend de 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

Reemplaza lo siguiente:

• NEG_NAME: Es el nombre de tu grupo de extremos de red. El nombre es el nombre que especificaste cuando creaste el NEG o un nombre generado automáticamente. Si no especificaste un nombre para el NEG, consulta las siguientes instrucciones a fin de encontrar el nombre generado de manera automática.
• NEG_ZONE: Es la zona en la que se encuentra tu grupo de extremos de red. Consulta las instrucciones siguientes 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 es similar al siguiente:

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

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

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

Valida que el balanceador de cargas funcione

Hay dos formas de validar el funcionamiento del balanceador de cargas que configuraste:

• Comprueba que la verificación de estado esté configurada correctamente y genere informes.
• Accede a la aplicación y verifica su respuesta.

Comprueba las verificaciones de estado

Comprueba que el servicio de backend esté asociado con la verificación de estado y los grupos de extremos de red, y que los extremos individuales estén en buen estado.

Usa este comando para verificar que el servicio de backend esté asociado con tu verificación de estado y tu grupo de extremos de red:

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

El resultado es similar a este:

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

Luego, verifica el estado de los extremos individuales:

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

La sección status: del resultado es similar a esta:

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

Accede a la aplicación

Accede a la aplicación a través de la dirección IP del balanceador de cargas para confirmar que todo funcione de forma correcta.

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

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

El resultado incluirá una dirección IP. Luego, 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 app serve_hostname debe ser neg-demo-app.

Vincula un balanceador de cargas de aplicaciones interno a NEG independientes

Puedes usar NEG a fin de configurar un balanceador de cargas de aplicaciones interno para los servicios que se ejecutan en Pods de GKE independientes.

Configura la subred de solo proxy

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

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"
}

Configura las reglas de firewall

En este ejemplo, se usan las siguientes reglas de firewall:

• fw-allow-ssh: Una regla de entrada aplicable a las instancias con balanceo de cargas y que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de IP de origen más restrictivo para esta regla. Por ejemplo, puedes especificar solo los rangos de IP del sistema desde el que inicias sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh para identificar las VM a las que se aplica la regla de firewall.

• fw-allow-health-check: Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP de los sistemas de verificación de estado de Google Cloud (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 debe aplicarse.

• fw-allow-proxies: Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP en el puerto 9376 desde los proxies administrados del balanceador de cargas de 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 firewall, la regla de entrada predeterminada denegada 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"
}

Configura el balanceador de cargas

Para la dirección IP de la regla de reenvío, usa una subred de backend. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.

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

Accede a la instancia de cliente para verificar que los servicios HTTP(S) en los backends sean accesibles mediante la dirección IP de la regla de reenvío del balanceador de cargas de aplicaciones interno y que las cargas del tráfico se balanceen en los extremos 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 entregue su nombre de host:

curl 10.1.2.199

Para la prueba de 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 sus cargas estén balanceadas.

Para 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
}

Implementa servicios heterogéneos (VM y contenedores)

Los balanceadores de cargas pueden ser frontends para una combinación de cargas de trabajo de Kubernetes y cargas de trabajo que no son de Kubernetes. Esto podría ser parte de una migración de VM a contenedores o una arquitectura permanente que se beneficia de un balanceador de cargas compartido. Esto se puede lograr mediante la creación de balanceadores de cargas que se dirigen a diferentes tipos de backends, incluidos los NEG independientes.

VM y contenedores en el mismo servicio de backend

En este ejemplo, se muestra cómo crear un NEG que apunte a una VM existente que ejecuta una carga de trabajo, y cómo agregar este NEG como otro backend de un backendService existente. De esta manera, un solo balanceador de cargas balancea entre las VM y los contenedores de GKE.

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

Debido a que todos los extremos se agrupan por el mismo backendService, los extremos del contenedor y la VM se consideran el mismo servicio. Esto significa que la coincidencia del host o la ruta tratará a todos los backends de manera idéntica según las reglas del mapa de URL.

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

1. Implementa una VM en Compute Engine con el siguiente 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
   

   Reemplaza lo siguiente:

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

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

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

3. Valida que la aplicación entregue en el puerto 9376 y que informe que se ejecuta 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 usar con el extremo de VM. Los contenedores y las VM pueden ser extremos de NEG, pero un solo NEG no puede tener extremos de contenedor y VM.

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

5. Vincula el extremo de VM al NEG:

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

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

6. Confirma que el NEG tenga el extremo de VM:

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

7. Vincula el NEG al servicio de backend mediante el mismo comando que usaste para agregar 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 firewall para permitir la verificación de 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 cargas reenvíe tráfico al backend de vm1 nuevo y al backend del contenedor existente mediante el envío de tráfico de prueba:

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

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

VM y contenedores para diferentes servicios de backend

En este ejemplo, se muestra cómo crear un NEG que apunta a una VM existente que ejecuta una carga de trabajo y cómo agregar este NEG como el backend de un backendService nuevo. Esto es útil para el caso en el que los contenedores y las VM son servicios diferentes, pero necesitan compartir el mismo balanceador de cargas L7, como si los servicios compartieran la misma dirección IP o 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 del contenedor. En este ejemplo, se vuelve a usar esa VM.

Debido a que los extremos del contenedor y la VM se agrupan en servicios de backend separados, se consideran servicios diferentes. Esto significa que el mapa de URL coincidirá con los backends y el tráfico directo a la VM o al contenedor según el nombre de host.

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

En el siguiente diagrama, se muestra la arquitectura que se describió en la sección anterior:

1. Crea un servicio de backend nuevo para la VM:

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

2. Vincula 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. Agrega una regla de host al mapa de URL 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. Agrega otra regla de host al mapa de URL para dirigir las solicitudes del host vm.example.com 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 cargas envíe tráfico al backend de la VM según la ruta solicitada:

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

   Reemplaza VIRTUAL_IP por la dirección IP virtual.

Limitaciones de los NEG independientes

• Los errores de validación de anotaciones se exponen al usuario a través de eventos de Kubernetes.
• Las limitaciones de los NEG también se aplican a los NEG independientes.

• Los NEG independientes no funcionan con redes heredadas.

• Los NEG independientes solo se pueden usar con servicios de red compatibles, incluidos Cloud Service Mesh y los tipos de balanceadores de cargas compatibles.

Precios

Consulta la sección de balanceo de cargas de la página de precios para obtener más detalles sobre los precios del balanceador de cargas. No se aplican cargos adicionales por los NEG.

Soluciona problemas

En esta sección, se proporcionan pasos para solucionar problemas comunes que puedes experimentar con los NEG independientes.

No se configuró un NEG independiente

Síntoma: Un NEG no se crea.

Resolución posible:

• Verifica los eventos asociados con el Service y busca mensajes de error.
• Verifica que la anotación del NEG independiente sea un JSON con el formato correcto y que los puertos expuestos coincidan con los puertos existentes en la especificación del Service.
• Verifica la anotación del estado del NEG y si los puertos de servicio esperados tienen los NEG correspondientes.
• Verifica que los NEG se creen en las zonas esperadas con el comando gcloud compute network-endpoint-groups list.
• Si usas la versión 1.18 o posterior de GKE, verifica si el recurso svcneg para el Service existe. De ser así, verifica la condición Initialized para detectar información de 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 extremos

Síntoma: Errores 502 o conexiones rechazadas.

Resolución posible:

• Después de configurar el servicio, por lo general, se puede acceder a los extremos nuevos después de vincularlos al NEG, siempre que respondan a las verificaciones de estado.
• Si después de este tiempo el tráfico aún no puede llegar a los extremos, y esto genera un código de error 502 de HTTP(S) o conexiones rechazadas para balanceadores de cargas TCP/SSL, verifica lo siguiente:
  • Verifica que las reglas de firewall permitan el tráfico de TCP entrante a los extremos de los siguientes rangos: 130.211.0.0/22 y 35.191.0.0/16.
  • Verifica que tus extremos estén en buen estado con Google Cloud CLI o llamando a la API getHealth en backendService o la API de listEndpoints en el NEG con el parámetro showHealth como SHOW.

Lanzamiento suspendido

Síntoma: El lanzamiento de un Deployment actualizado se suspende, y la cantidad de réplicas actualizadas no coincide con la cantidad seleccionada de réplicas.

Resolución posible:

Las verificaciones de estado de la implementación están fallando. La imagen del contenedor puede ser mala o la verificación de estado puede estar mal configurada. El reemplazo continuo de Pods espera hasta que el Pod recién iniciado pase su puerta de preparación de Pod. Esto solo ocurre si el Pod responde a las verificaciones de estado del balanceador de cargas. Si el pod no responde o la verificación de estado está mal configurada, no se pueden cumplir las condiciones de la puerta de preparación y el lanzamiento no puede continuar.

• Si usas kubectl 1.13 o una versión posterior, puedes verificar el estado de las puertas de preparación de un pod con el siguiente comando:

  kubectl get my-Pod -o wide
  

  Consulta la columna READINESS GATES.

  Esta columna no existe en kubectl 1.12 ni en versiones anteriores. Un pod que está marcado en estado READY puede tener una puerta de preparación con errores. Para verificar esto, usa el siguiente comando:

  kubectl get my-pod -o yaml
  

  Las puertas de preparación y sus estados se enumeran en la salida.

• Verifica que la imagen del contenedor en la especificación de tu pod de Deployment funcione de forma correcta y pueda responder a las verificaciones de estado.

• Comprueba que las verificaciones de estado estén configuradas de forma correcta.

El NEG no se recopila como elemento no utilizado

Síntoma: Aún existe un NEG que se debería haber borrado.

Resolución posible:

• El NEG no se recolecta con elementos no utilizados si un servicio de backend hace referencia al NEG. Consulta Cómo evitar NEG filtrados para obtener más detalles.
• Si usas 1.18 o versiones posteriores, puedes comprobar los eventos del recurso ServiceNetworkEndpointGroup mediante el procedimiento de service neg.
• Verifica si un NEG todavía necesita un servicio. Verifica el recurso svcneg para el servicio que corresponde al NEG y verifica si existe una anotación del Service.

El NEG no se sincroniza con el Service

Síntoma: Los extremos esperados (IP de Pod) no existen en el NEG, el NEG no está sincronizado o se muestra 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.

Resolución posible:

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

• Verifica el valor status.lastSyncTime para verificar si el NEG se sincronizó recientemente.
• Verifica la condición Synced para detectar errores que hayan ocurrido en la sincronización más reciente.

Si usas GKE 1.19.9 o una versión posterior, verifica 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 un NEG con el nombre que el controlador de NEG necesita usar se haya creado con la CLI de gcloud o la consola de Google Cloud en la zona del clúster (o una de las zonas del clúster). En este caso, debes borrar el NEG existente antes de que el controlador de NEG pueda sincronizar sus extremos. La creación y la membresía de NEG independientes están diseñadas para ser administradas por el controlador de NEG.

¿Qué sigue?

• Descripción general de grupos de extremos de red por zonas
• Explicación de los servicios de backend
• Crea verificaciones de estado
• Usa proxies de destino
• Conceptos de las reglas de reenvío