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:Jun 07, 2024

    During a rolling update, you need to ensure that the updated pods are ready before they are launched to receive traffic. You can configure readiness gates to ensure the readiness of pods before they are launched. The Application Load Balancer (ALB) Ingress controller allows you to enable readiness gates to continuously monitor the status of pods in a Container Service for Kubernetes (ACK) cluster. After the status of the pods changes to Ready, the pods are launched and added to a backend server group. Then, traffic is forwarded to the pods.

    Prerequisites

    How it works

    ACK uses liveness probes, readiness probes, and startup probes to check the health status, readiness, and startup conditions of pods in order to improve the availability of applications. When you configure liveness probes, readiness probes, and startup probes, you can specify the probing interval, timeout period, healthy threshold, and unhealthy threshold. You can define these probes with commands, TCP sockets, or HTTP requests to verify the health of containers. For more information, see Configure Liveness, Readiness and Startup Probes.

    Probe type

    Description

    Liveness probe

    The kubelet uses liveness probes to check whether containers are alive, kills unhealthy containers, and then restarts the containers based on the restart policy. If a container is not probed by liveness probes, the kubelet considers that the container returns Success for liveness probes and therefore the container is alive.

    Readiness probe

    Readiness probes are used to check whether a container is ready to receive requests. Only pods that are in the Ready state can receive requests. The relationship between Services and endpoints depends on the Ready state of the pod:

    • If the value of the Ready field is False, Kubernetes removes the IP address of the pod from the list of endpoints that are associated with the Services.

    • After the value of the Ready field changes to True, Kubernetes adds the IP address of the pod to the list of endpoints that are associated with the Services.

    Startup probe

    The kubelet uses startup probes to learn when a container has launched. You can use startup probes to ensure that liveness probes and readiness probes are sent to a container only after the container has launched. Startup probes can be used to perform liveness checks on slow starting containers so that the containers are not killed by the kubelet before they are started.

    If readiness probes are used, the value of the Ready field of a pod is determined by the kubelet based on the status of the containers in the pod. However, for complex applications, you may need to control the readiness Services in containers in a fine-grained manner. To do this, you need to control the value of the Ready field of pods.

    Readiness gates allow you to set one or more custom readiness conditions to check whether a pod is ready. These custom conditions are set on an external controller. Kubernetes considers that a pod is ready only when all conditions specified in readiness gates are True.

    You can configure readiness gates on the ALB Ingress controller to allow an ACK cluster to continuously monitor the status of pods. A pod is not considered started until it enters the Ready state. The started pod will be added to a backend server group, and traffic will be forwarded to the pod.

    Note

    You can configure the custom condition target-health.alb.k8s.alibabacloud for readiness gates in the Deployment. This allows the ACK cluster to continuously monitor the status of pods. The ACK cluster considers a pod is ready and starts to forward traffic to the pod only after the ALB Ingress controller adds the pod to a backend server group.

    Procedure

    1. Create a file named tea-service.yaml and configure custom conditions for readiness gates.

      Create a file named tea-service.yaml and add the following content to the file to deploy a Deployment named tea and a Service named tea-svc. Configure custom conditions for readiness gates in the Deployment: target-health.alb. Kubernetes. alibabacloud. This allows the ACK cluster to continuously monitor the status of pods. A pod is not considered started until it enters the Ready state. The started pods are added to a 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
# Configure readiness gates
      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

    2. Run the following command to deploy the Deployment andService: 

      kubectl apply -f tea-service.yaml

    3. Run the following command to check whether the configuration of readiness gates takes effect: 

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

      Expected output: 

      -conditionType:target-health.alb.k8s.alibabacloud 
     message:correspondingconditionofpodreadinessgate"target-health.alb.k8s.alibabacLoud"

    References