Container Compute Service:Configure Sidecar container startup and shutdown sequence

Feature description

In ACS scenarios, due to virtual node limitations, Kubernetes DaemonSet functionality is not supported. In these cases, scenarios that require DaemonSets can achieve similar effects by adding Sidecar containers to pods. However, the lifecycle of Sidecar containers cannot be independent of the pod lifecycle. To achieve an effect similar to DaemonSets, you need to configure the startup and shutdown sequence of Sidecar containers. This ensures that Sidecar containers start before the main application containers when a pod is created, and that Sidecar containers are forcibly terminated when the application containers in job-type pods have already exited.

For these scenarios, ACS supports configuring the startup and shutdown sequence of Sidecar containers in two ways:

• Native Kubernetes Sidecar declaration

  In Kubernetes 1.29 and later versions, native Sidecar declaration is supported by default. This involves configuring Sidecar as an Init container and setting restartPolicy to Always.

  Note

  The native Sidecar method implements Sidecar containers as special Init containers. When a pod starts, application containers must wait for Sidecar containers to complete startup before they can run normally. At the same time, the restartPolicy: Always configuration allows Sidecar containers to start, stop, and restart without affecting the main application containers and other Init containers.

• ACS custom declaration

  For Kubernetes 1.28 and earlier versions, ACS supports setting a special environment variable __IS_SIDECAR__ for regular containers to mark whether the container is a Sidecar.

  Important

  The ACS custom declaration method supports declaring regular containers as Sidecars, which start before other regular containers and automatically retry according to the principle of restartPolicy set to Always. At the same time, ACS clusters have made compatibility adjustments for lower versions of Kubernetes (1.28 and earlier) to ensure that container status can be updated.

  However, in higher versions or other types of Kubernetes clusters, because of Kubernetes limitations on container status updates, the containerStatus and pod status of ACS custom-declared Sidecar containers will not be updated to Running after failure retries. Please refer to the actual pod status. It is recommended that you upgrade your cluster to version 1.29 or later and use the native Kubernetes Sidecar declaration method.

Configuration instructions

Configuration examples

1. The content example of test-sidecar.yaml is as follows, which indicates creating a Job containing two containers: app is the application container and sidecar is the Sidecar container.

   ACS custom declaration

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test
   spec:
     template:
       metadata:
         labels:
           app: test
       spec:
         containers:
         - name: app
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'for i in $(seq 1 10);do echo "logging" >> /var/logs.txt; sleep 1; done']
         - name: sidecar
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'touch /var/logs.txt && tail -F /var/logs.txt']
           env:
           - name: __IS_SIDECAR__   # Set environment variable for this container
             value: "true"          # Mark this container as sidecar
         restartPolicy: Never
     backoffLimit: 2

   Native Kubernetes Sidecar declaration

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test
   spec:
     template:
       metadata:
         labels:
           app: test
       spec:
         initContainers:
         - name: sidecar
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'touch /var/logs.txt && tail -F /var/logs.txt']
           restartPolicy: Always  # Declare this container as sidecar
         containers:
         - name: app
           image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28
           command: ['sh', '-c', 'for i in $(seq 1 10);do echo "logging" >> /var/logs.txt; sleep 1; done']
         restartPolicy: Never
     backoffLimit: 2

2. Execute the following command to create the Job.

   kubectl apply -f test-sidecar.yaml

3. View the Job details and corresponding Pod details to observe the effect of the environment variables.

   • Confirm that the Job has completed running and the status is Succeeded.

     kubectl describe job <job-name>

     Example as follows:

     

4. View Sidecar container details to observe the container startup sequence and actual exit code

   kubectl describe pod <pod-name>

   • The container startup sequence example is as follows. You can see that the sidecar container starts before the app container, ensuring that the sidecar functionality (such as traffic forwarding) that the application main container depends on is ready in advance. Additionally, you can see that after the app container finishes running (after 10s), the sidecar container will be forcibly killed, ensuring that the job pod can complete:

     

   • The exit code example is as follows. You can see that the sidecar container is forcibly exited with an exit code of 0, ensuring that it does not interfere with determining whether the job pod ran successfully or failed.