Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Use readiness gates to seamlessly launch pods that are associated with ALB Ingresses during rolling updates

    Central de documentação

    Container Service for Kubernetes:Use readiness gates to seamlessly launch pods that are associated with ALB Ingresses during rolling updates

    Última atualização: Jun 27, 2026

    Durante uma atualização contínua, o Kubernetes marca um pod como Ready e inicia a finalização dos pods antigos assim que os contêineres do pod passam nas sondagens de prontidão. No entanto, o Application Load Balancer (ALB) pode ainda não ter registrado e verificado a integridade do novo pod como alvo de backend, o que cria uma janela em que o tráfego é perdido. As readiness gates evitam esse problema ao exigir que o controlador de ALB Ingress confirme o registro e a integridade do pod no grupo de servidores de backend antes que o Kubernetes o considere totalmente Ready e remova os pods antigos.

    Pré-requisitos

    Antes de começar, verifique se você tem:

    Como funciona

    O ACK utiliza três tipos de sondagem para monitorar a integridade dos contêineres:

    Sondagem

    Função

    Sonda de atividade (Liveness probe)

    O kubelet verifica se os contêineres estão ativos. Contêineres não íntegros são eliminados e reiniciados conforme a política de reinicialização. Contêineres sem essa sonda são considerados íntegros por padrão.

    Sonda de prontidão (Readiness probe)

    Verifica se um contêiner está pronto para receber requisições. Apenas pods no estado Ready recebem tráfego. Quando o estado Ready é False, o Kubernetes remove o IP do pod dos endpoints do Service. Quando Ready se torna True, o Kubernetes o adiciona novamente.

    Sonda de inicialização (Startup probe)

    Informa ao kubelet quando um contêiner foi totalmente iniciado. As sondas de atividade e de prontidão ficam suspensas até que a sonda de inicialização tenha sucesso, evitando que o kubelet elimine prematuramente contêineres de inicialização lenta.

    As sondas de prontidão funcionam bem para tráfego leste-oeste (interno do cluster), em que o controlador EndpointSlice do Kubernetes mantém as listas de endpoints sincronizadas. Já para tráfego norte-sul roteado por um ALB, existe uma lacuna de tempo: o Kubernetes pode marcar um pod como Ready e finalizar pods antigos mais rápido do que o ALB consegue registrar e verificar a integridade do novo pod como alvo de backend. Durante essa janela, os novos pods estão prontos sob a perspectiva do Kubernetes, mas o ALB ainda roteia tráfego para alvos que podem não existir mais.

    As readiness gates eliminam essa lacuna. Defina uma ou mais condições personalizadas de prontidão que devem ser True antes que o Kubernetes considere um pod totalmente Ready. Ao configurar a condição target-health.alb.k8s.alibabacloud, o controlador de ALB Ingress define essa condição como True somente após adicionar o pod a um grupo de servidores de backend. Os pods antigos não são finalizados até que isso ocorra.

    Quando todos os contêineres de um pod estão prontos, mas uma condição de readiness gate ainda é False , o Kubernetes relata a condição do pod como ContainersReady — e não como Ready . O pod não recebe tráfego até que todas as condições de readiness gate sejam True .

    Configurar readiness gates para atualizações contínuas

    Etapa 1: Criar o Deployment e o Service

    Crie um arquivo chamado tea-service.yaml com o conteúdo a seguir. O campo readinessGates na especificação do Deployment define a condição personalizada target-health.alb.k8s.alibabacloud, usada pelo controlador de ALB Ingress para sinalizar quando um pod está registrado e íntegro no 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

    Etapa 2: Implantar os recursos

    kubectl apply -f tea-service.yaml

    Etapa 3: Verificar se a readiness gate está ativa

    Execute o comando a seguir para confirmar que a condição personalizada está definida nos pods:

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

    Saída esperada:

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

    Para visualizar o status completo de prontidão do pod, execute:

    kubectl describe pod <pod-name>

    Procure uma seção Conditions semelhante à seguinte. Um pod só é considerado totalmente Ready quando todas as condições listadas são True. Se os contêineres estiverem prontos, mas o ALB ainda não tiver registrado o pod, ContainersReady será True enquanto Ready permanece False — esse é o estado intermediário esperado durante uma atualização contínua.

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

    Próximos passos