All Products
Search

This Product

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

    Document Center

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

    Last Updated:Mar 26, 2026

    During a rolling update, Kubernetes marks a pod Ready and begins terminating old pods as soon as the pod's containers pass their readiness probes. However, the Application Load Balancer (ALB) may not have registered and health-checked the new pod as a backend target yet—creating a window where traffic is dropped. Readiness gates prevent this by requiring the ALB Ingress controller to confirm that a pod is registered and healthy in the backend server group before Kubernetes considers it fully Ready and removes any old pods.

    Prerequisites

    Before you begin, ensure that you have:

    How it works

    ACK uses three probe types to monitor container health:

    Probe What it does
    Liveness probe The kubelet checks whether containers are alive. Unhealthy containers are killed and restarted according to the restart policy. Containers without a liveness probe are assumed healthy.
    Readiness probe Checks whether a container is ready to receive requests. Only pods in the Ready state receive traffic. When Ready is False, Kubernetes removes the pod's IP from Service endpoints. When Ready becomes True, Kubernetes adds it back.
    Startup probe Tells the kubelet when a container has fully launched. Liveness and readiness probes are held until the startup probe succeeds, preventing the kubelet from killing slow-starting containers prematurely.

    Readiness probes work well for east-west (cluster-internal) traffic, where the Kubernetes EndpointSlice controller keeps endpoint lists in sync. For north-south traffic routed through an ALB, a timing gap exists: Kubernetes can mark a pod Ready and terminate old pods faster than the ALB can register and health-check the new pod as a backend target. During this window, new pods are ready from Kubernetes' perspective, but the ALB still routes traffic to targets that may no longer exist.

    Readiness gates close this gap. You define one or more custom readiness conditions that must be True before Kubernetes considers a pod fully Ready. When you configure the target-health.alb.k8s.alibabacloud condition, the ALB Ingress controller sets this condition to True only after it has added the pod to a backend server group. Old pods are not terminated until this happens.

    When a pod's containers are all ready but a readiness gate condition is still False, Kubernetes reports the pod's condition as ContainersReady—not Ready. The pod does not receive traffic until all readiness gate conditions are True.

    Configure readiness gates for rolling updates

    Step 1: Create the Deployment and Service

    Create a file named tea-service.yaml with the following content. The readinessGates field in the Deployment spec sets the target-health.alb.k8s.alibabacloud custom condition, which the ALB Ingress controller uses to signal when a pod is registered and healthy in the backend server group.

    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

    Step 2: Deploy the resources

    kubectl apply -f tea-service.yaml

    Step 3: Verify the readiness gate is active

    Run the following command to confirm that the custom condition is set on the pods:

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

    Expected output:

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

    To see the full pod readiness status, run:

    kubectl describe pod <pod-name>

    Look for a Conditions section similar to the following. A pod is fully Ready only when all listed conditions are True. If containers are ready but the ALB has not yet registered the pod, ContainersReady is True while Ready remains False—this is the expected intermediate state during a rolling update.

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

    What's next