Container Compute Service:Configure Sidecar container startup and shutdown sequence

How it works

Native Kubernetes Sidecar declaration (Kubernetes 1.29+)

Sidecar containers are declared as init containers with restartPolicy: Always. Because init containers run before regular containers, the Sidecar starts before the application container. The restartPolicy: Always setting allows the Sidecar to restart independently without affecting other containers. When the application container in a Job-type Pod finishes, Kubernetes forcibly stops the Sidecar with exit code 0, allowing the Job to complete.

ACS custom declaration (Kubernetes 1.28 and earlier)

Set the __IS_SIDECAR__ environment variable to true on a regular container. ACS treats that container as a Sidecar: it starts before other regular containers and restarts according to restartPolicy: Always semantics. ACS clusters on 1.28 and earlier include compatibility adjustments to update container status correctly.

Prerequisites

Before you begin, ensure that you have:

• An ACS cluster

• kubectl configured to connect to the cluster

Declare Sidecar containers

The following example creates a Job named test with two containers: app (the application container) and sidecar (the Sidecar container). The Sidecar tails a log file written by the application container.

Choose the method that matches your cluster version.

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  # Declares this init container as a Sidecar: starts before app and restarts independently
      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

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__
          value: "true"  # Declares this regular container as a Sidecar: starts before app and stops when app exits
      restartPolicy: Never
  backoffLimit: 2

Verify the result

1. Apply the manifest:

   kubectl apply -f test-sidecar.yaml

2. Check that the Job completed successfully. The Conditions field should show Complete: True and the Succeeded pod count should be 1:

   kubectl describe job test

   

3. Check the Pod details to confirm startup order and exit behavior:

   kubectl describe pod <pod-name>

   • Startup order: The sidecar container's start time is earlier than app. This confirms that any services the application depends on—such as traffic forwarding or log collection—are ready before the application starts.

     

   • Exit code: The sidecar container exits with code 0 after app finishes. Exit code 0 means the forced termination is not treated as a failure, so the Job reaches Succeeded status.

     

Configuration reference