Usa el balanceo de cargas nativo del contenedor

En esta página, se explica cómo usar el balanceo de cargas nativo del contenedor en Google Kubernetes Engine.

Descripción general

El balanceo de cargas nativo del contenedor habilita a que los balanceadores de cargas de HTTP(S) se orienten a los pods de modo directo y distribuyan su tráfico de forma equitativa a los pods.

El balanceo de cargas nativo del contenedor aprovecha un modelo de datos llamado grupos de extremo de red (NEG), que son grupos de extremos de red representados por pares de puertos IP.

Beneficios

El balanceo de cargas nativo del contenedor ofrece los beneficios siguientes:

Los pods son elementos destacados para el balanceo de cargas.
El kube-proxy configura las reglas iptables de los nodos para distribuir el tráfico hacia los pods. Sin el balanceo de cargas nativo del contenedor, el tráfico del balanceador de cargas viaja a los grupos de instancias de nodos y se enruta por medio de reglas iptables hacia los pods que pueden estar o no en el mismo nodo. Con el balanceo de cargas nativo del contenedor, el tráfico del balanceador de cargas se distribuye de forma directa en los pods que deben recibir el tráfico y borra el salto de red adicional. El balanceo de cargas nativo del contenedor también ayuda a mejorar la comprobación de estado, ya que se dirige a los pods de forma directa.

Diagrama que compara el comportamiento predeterminado (izquierda) con el comportamiento del balanceador de cargas nativo del contenedor.
Rendimiento de red mejorado
Debido a que el balanceador de cargas nativo del contenedor se comunica directo con los pods y que las conexiones tienen menos saltos de red, tanto la latencia como la capacidad de procesamiento se ven mejoradas.
Mayor visibilidad
Con el balanceo de cargas nativo del contenedor, cuentas con visibilidad en el tiempo de ida y vuelta (RTT) desde el cliente hasta el balanceador de cargas de HTTP(S), incluida la asistencia de IU de Stackdriver. Esto facilita la solución de problemas de tus servicios en el nivel NEG.
Asistencia para las características de balanceo de cargas de HTTP(S)
El balanceo de cargas nativo del contenedor ofrece asistencia nativa en Google Kubernetes Engine para varias características del balanceo de cargas de HTTP(S), como la integración con servicios de GCP, como Google Cloud Armor, Cloud CDN y Cloud Identity-Aware Proxy. También cuenta con algoritmos de balanceo de cargas para lograr una distribución de tráfico precisa.
Compatibilidad con Traffic Director
Se requiere el modelo de datos NEG a fin de usar Traffic Director, el plano de control de tráfico completamente administrado de GCP para la malla de servicios.

Preparación del pod

Para los pod relevantes, el controlador Ingress correspondiente administra una puerta de preparación de tipo cloud.google.com/load-balancer-neg-ready. El controlador Ingress sondea la condición de la verificación de estado del balanceador de cargas, que incluye el estado de todos los extremos en el NEG. Cuando la condición de la verificación de estado del balanceador de cargas indica que el extremo correspondiente a un pod en particular está en buen estado, el controlador Ingress establece el valor de puerta de preparación del pod en True. El kubelet que se ejecuta en cada nodo calcula la preparación efectiva del pod, considerando tanto el valor de esta puerta de preparación como la prueba de disponibilidad del pod, si está definida.

Para el balanceo de cargas nativo del contenedor, las puertas de preparación del pod se habilitan automáticamente en los siguientes:

  • clústeres de GKE v1.13 que ejecutan v1.13.8 y superior
  • clústeres de GKE v1.14 que ejecutan v1.14.4 y superior

Las puertas de preparación controlan la velocidad de una actualización progresiva. Las versiones de GKE enumeradas anteriormente agregan automáticamente puertas de preparación a los pods. Cuando inicias una actualización progresiva, a medida que GKE crea nuevos pods, se agrega un extremo para cada pod nuevo a un NEG. Cuando el extremo está en buen estado desde la perspectiva del balanceador de cargas, el controlador Ingress establece la puerta de preparación en Verdadero. Por lo tanto, un pod recién creado debe pasar al menos su puerta de preparación antes de que GKE quite un pod anterior. Esto garantiza que el extremo correspondiente para el pod ya pasó la verificación de estado del balanceador de cargas y se mantiene la capacidad del backend.

Si la puerta de preparación de un pod nunca indica que el pod está listo, debido a una mala imagen del contenedor o una verificación de estado del balanceador de cargas mal configurado, el balanceador de cargas no dirigirá el tráfico al nuevo pod. Si se produce un error de este tipo cuando se lanza una implementación actualizada, el lanzamiento se detiene después de intentar crear un pod nuevo porque la puerta de preparación del pod nunca se establece en Verdadero. Consulta la sección de solución de problemas para obtener información sobre cómo detectar y solucionar esta situación.

Sin el balanceo de cargas nativo del contenedor y las puertas de preparación, GKE no puede detectar si los extremos de un balanceador de cargas están en buen estado antes de marcar pods como listos. En versiones anteriores de Kubernetes, tú controlas la velocidad con la que se quitan y reemplazan los pods si especificas un período de retraso (minReadySeconds en la especificación de implementación).

Requisitos

Los balanceadores de cargas nativos del contenedor en Google Kubernetes Engine deben cumplir con los siguientes requisitos:

Google Kubernetes Engine v1.13.8 o v1.14.4

Los balanceadores de cargas nativos del contenedor generalmente están disponibles en los siguientes:

  • clústeres de GKE v1.13 que ejecutan v1.13.8 y superior
  • clústeres de GKE v1.14 que ejecutan v1.14.4 y superior
VPC nativa

Para usar el balanceo de cargas nativos del contenedor, los clústeres deben ser nativos de VPC. Si quieres obtener más información, consulta Cómo crear clústeres de VPC nativa con direcciones IP de alias.

Balanceo de cargas de HTTP

Para usar el balanceo de cargas nativo del contenedor, tu clúster debe tener habilitado el balanceo de cargas de HTTP. Los clústeres de GKE tienen habilitado el balanceo de cargas HTTP de forma predeterminada. No debes inhabilitarlo.

Restricciones

Los balanceadores de cargas nativos del contenedor no funcionan con redes heredadas.

Limitaciones

Los balanceadores de cargas nativos no admiten balanceadores de cargas internos ni balanceadores de cargas de red.

Precios

Se te cobra por el balanceador de cargas de HTTP(S) que aprovisiona el Ingress que creas en esta guía. Para obtener información sobre los precios del balanceador de cargas, consulta Balanceo de cargas y reglas de reenvío en la página de precios de Compute Engine.

Usa el balanceo de cargas nativo del contenedor

En las secciones a continuación, se te guía en la configuración del balanceo de cargas nativo del contenedor en Google Kubernetes Engine.

Crea un clúster nativo de VPC

Para usar el balanceo de cargas nativo del contenedor, tienes que crear un clúster con las IP de alias habilitadas.

Por ejemplo, con el comando siguiente, se crea un clúster neg-demo-cluster con una subred aprovisionada de forma automática en la zona us-central1-a:

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

Crea una implementación

A continuación, implementa una carga de trabajo en el clúster.

En la siguiente página de Implementación de muestra, neg-demo-app ejecuta una sola instancia de un servidor HTTP en contenedor. Recomendamos que uses cargas de trabajo que utilicen comentarios de preparación de pods. Consulta la sección de preparación de pod más arriba para obtener más información y los requisitos de la versión GKE.

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: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
  

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: k8s.gcr.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
      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 muestra el nombre del host del servidor de la aplicación (el nombre del pod en el que se ejecuta el servidor) como respuesta.

Guarda el manifiesto como neg-demo-app.yaml y, luego, crea la implementación mediante la ejecución del comando siguiente:

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.

En el servicio de muestra a continuación, neg-demo-svc se orienta 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
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Creates an NEG after an Ingress is created
spec: # Service's specification
  type: NodePort
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80 # Service's port
    protocol: TCP
    targetPort: 9376

La anotación del servicio cloud.google.com/neg: '{"ingress": true}' habilita el balanceo de cargas nativo del contenedor. Sin embargo, el balanceador de cargas no se crea hasta que crees un Ingress para el servicio.

Guarda el manifiesto como neg-demo-svc.yaml y, luego, crea el servicio con la ejecución del comando a continuación:

kubectl apply -f neg-demo-svc.yaml

Crea un Ingress para el servicio

En el Ingress de muestra a continuación, neg-demo-ing se orienta al servicio que creaste:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: neg-demo-ing
spec:
  backend:
    serviceName: neg-demo-svc # Name of the Service targeted by the Ingress
    servicePort: 80 # Should match the port used by the Service

Guarda el manifiesto como neg-demo-ing.yaml y, luego, crea el Ingress con la ejecución del comando a continuación:

kubectl apply -f neg-demo-ing.yaml

Una vez creado el Ingress, se crea un balanceador de cargas de HTTP(S) en el proyecto y los NEG se crean 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.

Para recuperar el estado del Ingress, ejecuta el comando siguiente:

kubectl describe ingress neg-demo-ing

En el resultado del comando, busca 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 la funcionalidad del 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 HTTP(S) 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 comando siguiente:

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.

Primero, obtén una lista de los servicios de backend que se ejecutan en tu proyecto:

gcloud compute backend-services list

Copia el nombre del backend que incluye el nombre del servicio, como neg-demo-svc. Luego, obtén el estado del servicio de backend:

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

Verifica la funcionalidad del Ingress

Otra manera de probar que el balanceador de cargas funciona como lo esperado es mediante el 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.

El comando siguiente escala la implementación de neg-demo-app desde una instancia hasta dos instancias:

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

Espera unos minutos para que se complete el lanzamiento. Para verificar si se completó el lanzamiento, ejecuta el comando siguiente:

kubectl get deployment neg-demo-app

En el resultado del comando, verifica que hayan dos réplicas disponibles:

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

Luego, ejecuta el comando siguiente para contar la cantidad de respuestas distintas provenientes del balanceador de cargas:

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

donde [IP_ADDRESS] es la dirección IP del Ingress. Puedes obtener la dirección IP del Ingress desde kubectl describe ingress neg-demo-ing.

En el resultado del comando, observa que el número de respuestas distintas es el mismo que el número de réplicas, lo que indica que todos los pods de backend están entregando tráfico:

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

Limpieza

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

Borra el clúster

gcloud

gcloud container clusters delete neg-demo-cluster

Console

  1. Ve al menú de Google Kubernetes Engine en GCP Console.

    Ir al menú de Google Kubernetes Engine

  2. Selecciona neg-demo-cluster.

  3. Haz clic en Borrar.

Soluciona problemas

Usa las siguientes técnicas para verificar tu configuración de red. En las secciones a continuación, se explica cómo resolver problemas específicos relacionados con el balanceo de cargas nativo del contenedor.

  • Consulta la documentación del balanceo de cargas para obtener información sobre cómo enumerar los grupos de extremos de red.

  • Puedes encontrar el nombre y las zonas del NEG que corresponde a un servicio en la anotación neg-status del servicio. Obtén la especificación de servicio con el siguiente:

    kubectl get svc svc-name -o yaml

    La anotación metadata:annotations:cloud.google.com/neg-status enumera el nombre del NEG correspondiente del servicio y las zonas del NEG.

  • Puedes verificar el estado del servicio de backend que corresponde a un NEG con el siguiente comando:

    gcloud compute backend-service [--project PROJECT_NAME] \
      get-health BACKEND_SERVICE_NAME --global
    

    Ten en cuenta que el servicio de backend tiene el mismo nombre que su NEG.

  • Para imprimir los registros de eventos de un servicio, usa el siguiente:

    kubectl describe svc [SERVICE_NAME]
    

    La string de nombre del servicio incluye el nombre y el espacio de nombres del servicio GKE correspondiente.

No se puede crear un clúster con IP de alias

Síntomas
Cuando intentas crear un clúster con IP de alias, tal vez encuentres el error siguiente:
ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Causas posibles
Este error se produce si intentas crear un clúster con IP de alias que también usan redes heredadas.
Resolución
Asegúrate de no crear un clúster con IP de alias y una red heredada habilitadas a la misma vez. Para obtener más información sobre el uso de IP de alias, consulta Crea clústeres nativos de VPC con IP de alias.

El tráfico no alcanza los extremos

Síntomas
Errores 502 o conexiones rechazadas.
Causas posibles

A los extremos nuevos, por lo general, se los puede alcanzar después de adjuntarlos al balanceador de cargas, siempre que respondan a la verificación de estado. Tal vez encuentres errores 502 o conexiones rechazadas si el tráfico no puede alcanzar los extremos.

Un contenedor que no maneja SIGTERM también puede provocar errores 502 y conexiones rechazadas. Si un contenedor no maneja explícitamente SIGTERM, de inmediato termina y deja de manejar solicitudes. El balanceador de cargas continúa enviando tráfico entrante al contenedor finalizado, lo que genera errores.

Resolución

Configura los contenedores para manejar SIGTERM y continúa respondiendo a las solicitudes durante todo el período de gracia de terminación (30 segundos de forma predeterminada). Configura pods para comenzar a fallar las verificaciones de estado cuando reciben SIGTERM. Esto le indica al balanceador de cargas que deje de enviar tráfico al pod mientras la desprogramación de extremo está en progreso.

Consulta la documentación sobre la terminación de pod y esta publicación sobre las prácticas recomendadas de terminación del pod para obtener más información.

Para solucionar el tráfico que no llega a los extremos, verifica que las reglas de firewall permitan el tráfico entrante de TCP a tus extremos en los rangos 130.211.0.0/22 y 35.191.0.0/16. Para obtener más información, consulta la página sobre cómo agregar verificaciones de estado en la documentación de Cloud Load Balancing.

Revisa los servicios de backend de tu proyecto. La string de nombre del servicio de backend relevante incluye el nombre y el espacio de nombres del servicio de Google Kubernetes Engine correspondiente:

gcloud compute backend-services list

Recupera el estado del backend desde el servicio de backend:

gcloud compute backend-services get-health [BACKEND_SERVICE_NAME]

Si todos los backends están en mal estado, puede que tu firewall, Ingress o servicio estén mal configurados.

Si algunos backends están en mal estado durante un período breve, la causa podría ser la latencia de programación de la red.

Si algunos backends no aparecen en la lista de servicios de backend, la causa podría ser la latencia de programación de la red. Puedes verificar esto con la ejecución del comando siguiente, en que [NEG] es el nombre del servicio de backend. (Los NEG y los servicios de backend comparten el mismo nombre):

gcloud compute network-endpoint-groups list-network-endpoints [NEG]

Verifica que todos los extremos esperados estén en el NEG.

Lanzamiento suspendido

Síntomas
El lanzamiento de puestos de implementación actualizados y la cantidad de réplicas actualizadas no coincide con la cantidad deseada de réplicas.
Causas posibles

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 si 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 estás utilizando kubectl 1.13 o superior, 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 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.

Resolución

Verifica que la imagen del contenedor en la especificación de su pod de implementación funcione correctamente y pueda responder a las verificaciones de estado. Comprueba que las verificaciones de estado estén configuradas correctamente.

Problemas conocidos

El balanceo de cargas nativo del contenedor en Google Kubernetes Engine tiene los siguientes problemas conocidos:

Recolección incompleta de elementos no utilizados

Google Kubernetes Engine recolecta elementos no utilizados de los balanceadores de cargas nativos de contenedores cada dos minutos. Si se borra un clúster antes de que los balanceadores de cargas se quiten por completo, tienes que borrar los NEG del balanceador de cargas de forma manual.

Para revisar los NEG en tu proyecto, ejecuta el comando siguiente:

gcloud compute network-endpoint-groups list

En el resultado del comando, busca los NEG relevantes.

Para borrar un NEG, ejecuta el siguiente comando, en que [NEG] es el nombre del NEG:

gcloud compute network-endpoint-groups delete [NEG]

Alinea los lanzamientos de carga de trabajo con la propagación de extremos

Cuando implementas una carga de trabajo en tu clúster o actualizas una carga de trabajo existente, el balanceador de cargas nativo del contenedor puede demorar más en propagar extremos nuevos que lo que demora en terminar el lanzamiento de la carga de trabajo. La implementación de muestra que implementas en esta guía usa dos campos para alinear su lanzamiento con la propagación de extremos: terminationGracePeriodSeconds y minReadySeconds.

terminationGracePeriodSeconds permite al pod cerrarse con facilidad mediante la espera de que las conexiones terminen después de que se programe un pod para su eliminación.

minReadySeconds agrega un período de latencia después de que se crea un pod. Especifica una cantidad mínima de segundos que debe tardar un pod nuevo en adquirir el estado Ready, sin que ninguno de sus contenedores fallen, con el fin de que el pod se considere disponible.

Debes configurar tus valores minReadySeconds y terminationGracePeriodSeconds de la carga de trabajo en 60 segundos o más para asegurarte de que el servicio no se interrumpa por lanzamientos de carga de trabajo.

terminationGracePeriodSeconds está disponible en todas las especificaciones de pod y minReadySeconds está disponible para implementaciones y DaemonSets.

Para obtener más información sobre el ajuste preciso de los lanzamientos, consulta RollingUpdateStrategy.

¿Qué sigue?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Kubernetes Engine