OpenKruise — Advanced Kubernetes Workload Management

Introduction

OpenKruise is a CNCF Sandbox project created by Alibaba to address limitations in Kubernetes native workload controllers. Standard Deployments recreate pods on every update, which is slow and disruptive. Kruise introduces workload types like CloneSet, Advanced StatefulSet, and SidecarSet that support in-place container updates, configurable rolling strategies, and sidecar injection without mutating webhooks.

What OpenKruise Does

• Provides CloneSet for Deployment-like workloads with in-place update and partition canary
• Offers Advanced StatefulSet with maxUnavailable rolling updates and in-place upgrades
• Manages sidecar containers declaratively via SidecarSet without restarting main containers
• Pre-pulls images to nodes before rollout with ImagePullJob to speed up deployments
• Protects pods from cascading deletion with PodUnavailableBudget and deletion protection

Architecture Overview

Kruise installs as a set of controllers and webhooks in the kruise-system namespace. The kruise-manager Deployment runs all custom controllers (CloneSet, SidecarSet, ImagePullJob, etc.) that watch their respective CRDs. The kruise-daemon DaemonSet runs on each node to handle image pre-pulling and container restart operations for in-place updates. In-place updates modify the pod spec in place and restart only the changed container, avoiding pod recreation and IP changes.

Self-Hosting & Configuration

• Install with Helm chart: helm install kruise openkruise/kruise -n kruise-system
• Enable specific features via feature gates in the Helm values or kruise-manager args
• Use CloneSet as a drop-in replacement for Deployments with added in-place update capability
• Configure SidecarSet resources to inject and update sidecars across matching pods
• Set up ImagePullJob to pre-warm nodes with large images before scaling events

Key Features

• In-place updates restart only the changed container without pod recreation, preserving IP and volumes
• Partition-based canary releases let you upgrade a specific number of pods before rolling out fully
• SidecarSet hot-upgrades sidecar containers independently of the main application container
• ImagePullJob and NodeImage pre-pull container images to nodes for faster cold starts
• BroadcastJob runs one-off tasks across all or selected nodes (like a DaemonSet for batch jobs)

Comparison with Similar Tools

• Native Deployments — recreate pods on update; Kruise CloneSet does in-place updates
• Argo Rollouts — focused on progressive delivery (canary, blue-green); Kruise is broader with workload primitives
• Flagger — mesh-aware progressive delivery; Kruise operates at the pod/container level
• Istio traffic management — network-level canary; Kruise provides pod-level update strategies
• kustomize/Helm — packaging and templating tools; Kruise extends the runtime behavior of workloads

FAQ

Q: Can I use CloneSet as a drop-in for Deployment? A: Nearly. CloneSet has the same pod template spec but uses a different API group. Migrate by changing the apiVersion and kind.

Q: Does in-place update cause downtime? A: The updated container restarts briefly, but the pod keeps its IP and mounted volumes. Use readiness gates to manage traffic during the restart.

Q: Is OpenKruise production-ready? A: Yes. It runs in production at Alibaba and other large-scale Kubernetes environments with thousands of nodes.

Q: Does it work with managed Kubernetes (EKS, GKE, AKS)? A: Yes. OpenKruise installs as standard Kubernetes controllers and works on any conformant cluster.

Sources

• https://github.com/openkruise/kruise
• https://openkruise.io/docs/