OpenKruise SidecarSet: Injection, In‑Place Upgrade & Rollout Strategies

Background

Sidecar containers are a core pattern in cloud‑native architectures, separating auxiliary functions like logging, security, and proxying from the main application container. As the number and variety of sidecars grow in large Kubernetes clusters, managing and upgrading them becomes increasingly complex.

OpenKruise, an open‑source cloud‑native application automation suite under CNCF, introduces the SidecarSet resource to address these challenges by providing a dedicated workload for sidecar injection and lifecycle management.

SidecarSet Core Features

Configuration Isolation : Each sidecar can be managed by its own SidecarSet, simplifying configuration and reducing risk.

Automatic Injection : Leveraging Kubernetes AdmissionWebhook, sidecars defined in a SidecarSet are automatically injected into Pods created by Deployments, CloneSets, StatefulSets, etc.

In‑Place Upgrade : Sidecar containers can be upgraded without recreating the Pod, avoiding disruption to the primary container and supporting sophisticated rollout policies.

Rolling Update Strategies : Supports partition and maxUnavailable fields to control the number or percentage of Pods updated at a time.

Canary Release : Allows selective rollout to Pods labeled for canary testing before a full rollout.

Scatter (Dispersed) Release : Enables custom pod selection based on labels (e.g., application name) to spread updates across different services, optionally combined with maxUnavailable.

Key Fields in SidecarSet Spec

selector : Chooses target Pods via label matching; can be scoped to a namespace.

containers : Defines sidecar containers, including image, command, probes, resource limits, volume mounts, and environment variable sharing ( transferEnv).

volumes : Declares shared volumes for log collection or other data exchange.

updateStrategy : Configures rollout behavior ( type: RollingUpdate, partition, maxUnavailable, selector for canary, scatterStrategy for dispersed rollout).

Practical Example: Logtail Sidecar

The following steps demonstrate creating a SidecarSet that injects a log collection sidecar (logtail) into an Nginx Pod, updating the sidecar image in place, and observing the rollout.

1. Define the SidecarSet

# sidecarset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: logtail-sidecarset
spec:
  selector:
    matchLabels:
      app: nginx
  updateStrategy:
    type: RollingUpdate
    maxUnavailable: 10%
  containers:
  - name: logtail
    image: log-service/logtail:0.16.16
    command:
    - sh
    - -c
    - /usr/local/ilogtail/run_logtail.sh 10
    livenessProbe:
      exec:
        command:
        - /etc/init.d/ilogtaild
        - status
    resources:
      limits:
        memory: 512Mi
      requests:
        cpu: 10m
        memory: 30Mi
    volumeMounts:
    - name: nginx-log
      mountPath: /var/log/nginx
    transferEnv:
    - sourceContainerName: nginx
      envName: TZ
  volumes:
  - name: nginx-log
    emptyDir: {}

2. Create the Target Pod

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nginx
  name: test-pod
spec:
  containers:
  - name: nginx
    image: log-service/docker-log-test:latest
    command: ["/bin/mock_log"]
    args: ["--log-type=nginx","--stdout=false","--stderr=true","--path=/var/log/nginx/access.log","--total-count=1000000000","--logs-per-sec=100"]
    volumeMounts:
    - name: nginx-log
      mountPath: /var/log/nginx
    envs:
    - name: TZ
      value: Asia/Shanghai
  volumes:
  - name: nginx-log
    emptyDir: {}

After applying both manifests, the logtail container is automatically injected into test-pod.

3. Verify Injection

$ kubectl get pod test-pod -o yaml | grep 'logtail:0.16.16'
image: log-service/logtail:0.16.16

The SidecarSet status shows the pod is matched and ready:

$ kubectl get sidecarset logtail-sidecarset -o yaml | grep -A4 status
status:
  matchedPods: 1
  observedGeneration: 1
  readyPods: 1
  updatedPods: 1

4. In‑Place Upgrade of the Sidecar

Update the sidecar image in the SidecarSet spec:

# edit sidecarset.yaml
spec:
  containers:
  - name: logtail
    image: log-service/logtail:0.16.18

Apply the change; the sidecar container is upgraded to 0.16.18 without restarting the Nginx container.

$ kubectl get pod test-pod -o yaml | grep 'logtail:0.16.18'
image: log-service/logtail:0.16.18

5. Advanced Rollout Strategies

Partition & MaxUnavailable : Control how many Pods are updated at once.

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: sidecarset
spec:
  updateStrategy:
    type: RollingUpdate
    partition: 980   # keep 20 Pods at old version first
    maxUnavailable: 10%

Canary Release : Deploy only to Pods labeled canary.release=true before a full rollout.

updateStrategy:
  type: RollingUpdate
  selector:
    matchLabels:
      canary.release: true
  maxUnavailable: 10%

Scatter Strategy : Distribute updates across different applications to avoid concentrating load.

updateStrategy:
  type: RollingUpdate
  scatterStrategy:
  - key: app_name
    value: nginx
  - key: app_name
    value: web-server
  - key: app_name
    value: api-gateway
  maxUnavailable: 10%

Note: Existing Pods cannot have containers added; injection only occurs at creation. For in‑place upgrades that modify fields other than image , the Pod must be recreated.

Conclusion

OpenKruise v0.8.0 enhances SidecarSet with robust logging sidecar support, automatic injection, in‑place upgrades, and flexible rollout mechanisms such as rolling updates, canary, and scatter strategies. These capabilities simplify large‑scale sidecar management in Kubernetes clusters, reduce operational overhead, and enable seamless, low‑impact updates.