How OpenKruise v0.5.0 Enables Zero‑Downtime Deployments with MaxSurge and Sidecar Volume Merging

Background Problem

Native Kubernetes workloads such as Deployment, StatefulSet and DaemonSet provide limited rollout strategies: Deployment only supports maxUnavailable and maxSurge, StatefulSet only supports partition, and DaemonSet only maxUnavailable. These mechanisms work for small test clusters but cannot satisfy large‑scale production scenarios that require gray‑scale batch releases, staged rollouts, or high availability during upgrades.

OpenKruise v0.5.0 New Capabilities

OpenKruise, Alibaba Cloud’s open‑source large‑scale application management engine, adds two major features in version 0.5.0: (1) CloneSet now supports the maxSurge strategy together with in‑place upgrades, enabling “expand‑then‑shrink” rollouts; (2) SidecarSet gains volume‑merge handling, allowing sidecar containers to share existing Pod volumes without conflict.

CloneSet maxSurge in Action

Example CloneSet manifest demonstrates a 20 % maxSurge, zero maxUnavailable, and partition = 3. When the rollout starts, OpenKruise temporarily creates an extra Pod (total 6), then updates old Pods in place while respecting the partition, finally scaling back to the desired replica count.

apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
  replicas: 5
  updateStrategy:
    maxSurge: 20%
    maxUnavailable: 0
    partition: 3

kubectl output shows the intermediate total pod count (6) and the progressive update until all Pods reach the new version.

$ kubectl get clone demo
NAME   DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo   5         1         0               5       6       17m

SidecarSet Volume Merge

SidecarSet injects a logging sidecar into every Pod matching a label. The v0.5.0 enhancement merges sidecar‑defined volumes with those already declared in the target Pod, preventing duplicate volume names. When a Pod already defines a log-volume via a PersistentVolumeClaim, the injected sidecar reuses that volume, mounting it at /var/log inside the sidecar.

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: log-sidecar
spec:
  selector:
    matchLabels:
      app-type: long-term
  containers:
  - name: log-collector
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume
    emptyDir: {}

After injection, the resulting Pod spec contains both the original application container and the sidecar, sharing the same log-volume defined by the application.

apiVersion: v1
kind: Pod
metadata:
  labels:
    app-type: long-term
spec:
  containers:
  - name: app
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /app/logs
  - name: log-collector
    image: xxx:latest
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume
    persistentVolumeClaim:
      claimName: pvc-xxx

Conclusion

Version 0.5.0 of OpenKruise brings zero‑downtime, high‑availability rollouts through CloneSet’s maxSurge strategy and simplifies sidecar management with volume‑merge support in SidecarSet, making large‑scale Kubernetes deployments more flexible and maintainable.