Uso de readiness gates para iniciar pods asociados con ALB Ingresses sin interrupciones durante actualizaciones continuas - Container Service for Kubernetes

Durante una actualización continua, Kubernetes marca un pod como Ready y comienza a finalizar los pods antiguos en cuanto sus contenedores superan las pruebas de disponibilidad. Sin embargo, es posible que el Application Load Balancer (ALB) aún no haya registrado ni verificado el estado del nuevo pod como objetivo de backend, lo que genera un intervalo donde se pierde tráfico. Los readiness gates evitan este problema al exigir que el controlador de ALB Ingress confirme que el pod está registrado y en buen estado en el grupo de servidores de backend antes de que Kubernetes lo considere completamente Ready y elimine los pods antiguos.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

Un clúster administrado ACK o un clúster ACK Serverless. Para obtener instrucciones de configuración, consulte Create an ACK Serverless cluster o Create an ACK managed cluster.
El controlador de ALB Ingress instalado en el clúster. Para obtener instrucciones de configuración, consulte Manage the ALB Ingress controller.

Para usar un ALB Ingress con un clúster dedicado ACK, primero autorice al clúster para acceder al controlador de ALB Ingress. Consulte Authorize an ACK dedicated cluster to access the ALB Ingress controller .
Un cliente kubectl conectado al clúster. Para obtener instrucciones de configuración, consulte Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.

Funcionamiento

ACK usa tres tipos de pruebas para supervisar el estado de los contenedores:

Prueba	Función
Prueba de actividad	El kubelet comprueba si los contenedores están activos. Los contenedores con problemas se finalizan y reinician según la directiva de reinicio. Se asume que los contenedores sin prueba de actividad están en buen estado.
Prueba de disponibilidad	Comprueba si un contenedor puede recibir solicitudes. Solo los pods en estado `Ready` reciben tráfico. Cuando `Ready` es `False`, Kubernetes elimina la IP del pod de los endpoints del servicio. Cuando `Ready` cambia a `True`, Kubernetes la agrega nuevamente.
Prueba de inicio	Indica al kubelet cuándo un contenedor se ha iniciado por completo. Las pruebas de actividad y disponibilidad se suspenden hasta que la prueba de inicio tenga éxito; esto evita que el kubelet finalice prematuramente contenedores de inicio lento.

Las pruebas de disponibilidad funcionan bien para el tráfico este-oeste (interno del clúster), donde el controlador EndpointSlice de Kubernetes mantiene sincronizadas las listas de endpoints. En cambio, para el tráfico norte-sur enrutado a través de un ALB, existe una diferencia de tiempo: Kubernetes puede marcar un pod como Ready y finalizar los pods antiguos más rápido de lo que el ALB tarda en registrar y verificar el nuevo pod como objetivo de backend. Durante este intervalo, los nuevos pods están listos desde la perspectiva de Kubernetes, pero el ALB sigue enviando tráfico a objetivos que tal vez ya no existan.

Los readiness gates eliminan esta discrepancia. Defina una o más condiciones personalizadas de disponibilidad que deben ser True antes de que Kubernetes considere que un pod está completamente Ready. Al configurar la condición target-health.alb.k8s.alibabacloud, el controlador de ALB Ingress establece esta condición como True solo después de agregar el pod a un grupo de servidores de backend. Los pods antiguos no se finalizan hasta que esto ocurra.

Cuando todos los contenedores de un pod están listos, pero una condición de readiness gate sigue siendo False , Kubernetes reporta la condición del pod como ContainersReady , no como Ready . El pod no recibe tráfico hasta que todas las condiciones de readiness gate sean True .

Configuración de readiness gates para actualizaciones continuas

Paso 1: Crear el Deployment y el Service

Cree un archivo llamado tea-service.yaml con el siguiente contenido. El campo readinessGates en la especificación del Deployment establece la condición personalizada target-health.alb.k8s.alibabacloud, que el controlador de ALB Ingress usa para indicar cuándo un pod está registrado y en buen estado en el grupo de servidores de backend.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
      # Require ALB backend registration before marking a pod Ready
      readinessGates:
        - conditionType: target-health.alb.k8s.alibabacloud
---
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: NodePort

Paso 2: Desplegar los recursos

kubectl apply -f tea-service.yaml

Paso 3: Comprobar que el readiness gate está activo

Ejecute el siguiente comando para confirmar que la condición personalizada está configurada en los pods:

kubectl get pods -o yaml | grep 'target-health'

Salida esperada:

- conditionType: target-health.alb.k8s.alibabacloud
  message: corresponding condition of pod readiness gate "target-health.alb.k8s.alibabacloud"

Para ver el estado completo de disponibilidad del pod, ejecute:

kubectl describe pod <pod-name>

Busque una sección Conditions similar a la siguiente. Un pod se considera completamente Ready solo cuando todas las condiciones enumeradas son True. Si los contenedores están listos pero el ALB aún no ha registrado el pod, ContainersReady será True mientras que Ready permanecerá como False; este es el estado intermedio esperado durante una actualización continua.

Conditions:
  Type                                     Status
  target-health.alb.k8s.alibabacloud      True
  ContainersReady                          True
  Ready                                    True

Pasos siguientes

Para configurar el enrutamiento de ALB Ingress en su clúster, consulte Get started with ALB Ingresses.
Para opciones avanzadas de configuración de ALB Ingress, consulte Advanced ALB Ingress configurations.
Para solucionar problemas relacionados con ALB Ingress, consulte ALB Ingress controller troubleshooting y ALB Ingress FAQ.