Balanceo de cargas nativo del contenedor a través de Ingress

Autopilot estándar

En esta página, se explica cómo usar el balanceo de cargas nativo del contenedor en Google Kubernetes Engine (GKE). El balanceo de cargas nativo del contenedor permite que los balanceadores de cargas se orienten de forma directa a los pods de Kubernetes y distribuyan el tráfico de manera uniforme a los pods.

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

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

• Asegúrate de tener un clúster nativo de la VPC existente. Si necesitas uno, crea un clúster. Los clústeres de GKE son nativos de la VPC de forma predeterminada.

Usa el balanceo de cargas nativo del contenedor

En las siguientes secciones, se explica la configuración de balanceo de cargas nativo del contenedor en GKE.

Crear una implementación

En la siguiente Implementación de muestra, neg-demo-app, se ejecuta una única instancia de un servidor HTTP con contenedores. Recomendamos que uses cargas de trabajo que utilicen comentarios de preparación de pods.

Usa 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:
  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 # Container name
        ports:
        - containerPort: 9376
          protocol: TCP
  

Usa un retraso codificado

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
  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 # Container name
      # Note: The following line is necessary only on clusters running GKE v1.11 and lower.
      # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts
        ports:
        - containerPort: 9376
          protocol: TCP
      terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
  

En esta implementación, cada contenedor ejecuta un servidor HTTP. El servidor HTTP solo devuelve el nombre del host del servidor de la aplicación (el nombre del pod en el que se ejecuta el servidor) como respuesta.

Guarda este manifiesto como neg-demo-app.yaml y, luego, crea el Deployment:

kubectl apply -f neg-demo-app.yaml

Crea un servicio para un balanceador de cargas nativo del contenedor

Una vez creada una implementación, tienes que agrupar sus pods en un Servicio.

El siguiente servicio de muestra, neg-demo-svc, se dirige a la implementación de muestra que creaste en la sección anterior:

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc # Name of Service
spec: # Service's specification
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - name: http
    port: 80 # Service's port
    protocol: TCP
    targetPort: 9376

Nota: El servicio se expone en el puerto 80 y redirecciona el tráfico al puerto 9376, que es el targetPort. El targetPort corresponde a un containerPort en un Pod servidor. También es posible usar un servicio de tipo NodePort con el balanceo de cargas nativo del contenedor. Se recomienda un Service de tipo ClusterIP, a menos que necesites de forma explícita el nodePort proporcionado por un Service NodePort. Los objetos Service LoadBalancer no son compatibles como backends de Ingress.

El balanceador de cargas no se creará hasta que crees un Ingress para el servicio.

Guarda este manifiesto como neg-demo-svc.yaml y crea el Service:

kubectl apply -f neg-demo-svc.yaml

Crea un Ingress para el servicio

En el siguiente ejemplo de Ingress, neg-demo-ing, se dirige al servicio que creaste:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: neg-demo-ing
spec:
  defaultBackend:
    service:
      name: neg-demo-svc # Name of the Service targeted by the Ingress
      port:
        number: 80 # Should match the port used by the Service

Guarda este manifiesto como neg-demo-ing.yaml y crea el Ingress:

kubectl apply -f neg-demo-ing.yaml

Una vez creado el Ingress, se crea un balanceador de cargas de aplicaciones en el proyecto y se crean grupos de extremos de red (NEG) en cada zona en la que se ejecuta el clúster. Los extremos en el NEG y los del servicio se mantienen sincronizados.

Verifica el Ingress

Después de que implementaste una carga de trabajo, agrupaste sus pods en un servicio y creaste un Ingress para el servicio, tienes que verificar si el Ingress aprovisionó el balanceador de cargas nativo del contenedor de forma correcta.

Recupera el estado del Ingress:

kubectl describe ingress neg-demo-ing

El resultado incluye los eventos ADD y CREATE:

Events:
Type     Reason   Age                From                     Message
----     ------   ----               ----                     -------
Normal   ADD      16m                loadbalancer-controller  default/neg-demo-ing
Normal   Service  4s                 loadbalancer-controller  default backend set to neg-demo-svc:32524
Normal   CREATE   2s                 loadbalancer-controller  ip: 192.0.2.0

Prueba el balanceador de cargas

En las secciones a continuación, se explica cómo puedes probar la funcionalidad de un balanceador de cargas nativo del contenedor.

Visita la dirección IP del Ingress

Espera varios minutos hasta que el balanceador de cargas de aplicaciones se configure.

Puedes verificar que el balanceador de cargas nativo del contenedor funciona si visitas la dirección IP del Ingress.

Para obtener la dirección IP del Ingress, ejecuta el siguiente comando:

kubectl get ingress neg-demo-ing

En el resultado del comando, la dirección IP del Ingress se muestra en la columna ADDRESS. Visita la dirección IP en un navegador web.

Verifica el estado del servicio de backend

También puedes obtener el estado del servicio de backend de los balanceadores de cargas.

1. Obtén una lista de los servicios de backend que se ejecutan en tu proyecto:

   gcloud compute backend-services list
   

   Registra el nombre del servicio de backend que incluye el nombre del servicio, como neg-demo-svc.

2. Obtén el estado del servicio de backend:

   gcloud compute backend-services get-health BACKEND_SERVICE_NAME --global
   

   Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.

Prueba el Ingress:

Otra manera de probar que el balanceador de cargas funciona como lo esperado es a través del escalamiento de la implementación de muestra, el envío de solicitudes de prueba al Ingress y la verificación de la respuesta de la cantidad correcta de réplicas.

1. Escala el Deployment neg-demo-app de una instancia a dos instancias:

   kubectl scale deployment neg-demo-app --replicas 2
   

   Este comando puede tardar varios minutos en completarse.

2. Verifica si se completó el lanzamiento:

   kubectl get deployment neg-demo-app
   

   El resultado debe incluir dos réplicas disponibles:

   NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   neg-demo-app   2         2         2            2           26m
   

3. Obtén la dirección IP del Ingress:

   kubectl describe ingress neg-demo-ing
   

   Si este comando devuelve un error 404, espera unos minutos hasta que se inicie el balanceador de cargas y vuelve a intentarlo.

4. Cuenta la cantidad de respuestas distintas del balanceador de cargas:

   for i in `seq 1 100`; do \
     curl --connect-timeout 1 -s IP_ADDRESS && echo; \
   done  | sort | uniq -c
   

   Reemplaza IP_ADDRESS por la dirección IP del Ingress.

   El resultado es similar a este:

   44 neg-demo-app-7f7dfd7bc6-dcn95
   56 neg-demo-app-7f7dfd7bc6-jrmzf
   

   En este resultado, la cantidad de respuestas distintas es la misma que la cantidad de réplicas, lo que indica que todos los pods de backend entregan tráfico.

Limpia

Después de completar las tareas de esta página, sigue estos pasos para quitar los recursos a continuación y evitar que se hagan cargos no deseados a tu cuenta:

Borra el clúster

gcloud

gcloud container clusters delete neg-demo-cluster

Console

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

   Ir a Google Kubernetes Engine

2. Selecciona neg-demo-cluster y haz clic en Borrar.

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

¿Qué sigue?

• Obtén más información para usar el balanceo de cargas nativo del contenedor a través de NEG zonales independientes.
• Obtén más información sobre los clústeres nativos de VPC.
• Obtén más información sobre la configuración de Ingress.
• Obtén más información para usar certificados SSL administrados por Google.