Container Service for Kubernetes:Use preStop hooks to enable seamless pod termination during rolling updates of backend pods of ALB Ingresses

Prerequisites

Before you begin, make sure you have:

• An ACK managed cluster or ACK dedicated cluster running Kubernetes 1.18 or later. See Create an ACK managed cluster or Create an ACK dedicated cluster (discontinued). To upgrade an existing cluster, see Manually upgrade ACK clusters.

• The ALB Ingress controller installed in the cluster. See Manage the ALB Ingress controller.

To use an ALB Ingress with an ACK dedicated cluster, grant the cluster the permissions required by the ALB Ingress controller first. See Authorize an ACK dedicated cluster to access the ALB Ingress controller.

How it works

Pod lifecycle

A pod contains two types of containers:

• Init container: Runs before the main container to complete initialization operations.

• Main container: Runs the application process. After the container starts, the postStart hook runs. During the container's lifetime, the system performs liveness and readiness checks. Before the container terminates, the preStop hook runs.

The following figure shows the pod lifecycle.

Step 1: Deploy the application with a preStop hook

1. Create tea-service.yaml with the following content. The lifecycle.preStop field configures the hook.

   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
           lifecycle:
             preStop:          # Delay SIGTERM by 10 seconds to allow the ALB Ingress controller
               exec:           # to finish deregistering the pod from the backend server group.
                 command:
                 - /bin/sh
                 - -c
                 - "sleep 10"
         terminationGracePeriodSeconds: 45   # Must exceed preStop duration + program shutdown time.
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: tea-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: tea
     type: NodePort

2. Deploy the Deployment and Service.

   kubectl apply -f tea-service.yaml

3. Create tea-ingress.yaml with the following content.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
     - host: demo.ingress.top
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: tea-svc
               port:
                 number: 80

4. Create the Ingress.

   kubectl apply -f tea-ingress.yaml

5. Get the ALB address assigned to the Ingress.

   kubectl get ingress

   Expected output:

   NAME          CLASS   HOSTS              ADDRESS                                              PORTS   AGE
   tea-ingress   alb     demo.ingress.top   alb-110zvs5nhsvfv*****.cn-chengdu.alb.aliyuncs.com   80      7m5s

   Note the ADDRESS value—you will need it in the next step.

Step 2: Verify that the preStop hook prevents service interruptions

1. Create test.sh with the following content. The script sends one request per second to the NGINX service and records each HTTP status code.

   #!/bin/bash
   HOST="demo.ingress.top"
   DNS="alb-110zvs5nhsvfv*****.cn-chengdu.alb.aliyuncs.com"  # Replace with your ADDRESS value.
   printf "Response Code|| TIME \n" >> log.txt
   
   while true; do
     RESPONSE=$(curl -H Host:$HOST -s -o /dev/null -w "%{http_code}" -m 1 http://$DNS/)
     TIMESTAMP=$(date +%Y-%m-%d_%H:%M:%S)
     echo "$TIMESTAMP - $RESPONSE" >> log.txt
     sleep 1
   done

2. Run the script.

   bash test.sh

3. Trigger a rolling restart.

   kubectl rollout restart deploy tea

4. Watch the rollout progress. The following screenshots show the expected pod states during the update. Before the rolling update starts, three replicas are running. When new pods are not yet ready, two old pods continue serving traffic. After the new pods are added to the backend server group, the old pods begin terminating. After all old pods finish the preStop hook (or the grace period expires), the kubelet sends the termination signal and the rolling update completes.

   

   

   

   

5. Check the test log. Every request should return 200, confirming no service interruption occurred during the rolling update.

   cat log.txt

   Expected output:

   

What's next

• For advanced routing scenarios—such as HTTP-to-HTTPS redirects and canary releases—see Advanced ALB Ingress configurations.

• To make sure pods pass readiness checks before they receive traffic during rolling updates, see Use readiness gates to seamlessly launch pods that are associated with ALB Ingresses during rolling updates.

• If you run into issues, see ALB Ingress FAQ and ALB Ingress controller troubleshooting.