OpenKruise: advanced workloads and sidecar management for Kubernetes

What OpenKruise adds to the built-in Kubernetes controllers

Kubernetes ships Deployments, StatefulSets, DaemonSets and Jobs. They cover the common cases and they are maintained by the upstream project, which is why most teams never look further. The gap appears at scale. A Deployment that changes an image recreates pods, and on a large cluster that means a wave of restarts. A StatefulSet has limited control over which pods move first. Sidecar containers have no injection or upgrade mechanism at all in the core API. OpenKruise is a set of controllers that fill those gaps without replacing the core ones. The README describes it as controllers that "extend and complement the Kubernetes core controllers for workload and application management". The audience is platform and infrastructure engineers running many workloads across many nodes, who need in-place updates, ordered rollouts, or sidecar lifecycle control. A team running three Deployments does not need it.

CloneSet, SidecarSet and the other custom resources

The project is organised around custom resources, each handled by its own controller. Advance Workloads covers CloneSet for stateless applications, Advanced StatefulSet for stateful ones, Advanced DaemonSet for daemon workloads, BroadcastJob for running jobs across specific nodes, and AdvancedCronJob for scheduling Job or BroadcastJob objects periodically. The README states these support the basic features of the original workloads plus in-place update, configurable scale and upgrade strategies, and parallel operations. Sidecar container management is a second group: SidecarSet defines and upgrades sidecars, Container Launch Priority controls container startup order, and Sidecar Job Terminator stops sidecar containers for job-type pods once the main containers finish. A third group handles multi-domain placement. WorkloadSpread distributes pods across node pools, zones, architectures or node types without replacing the workload, while UnitedDeployment manages multiple sub-workloads as one unit. Enhanced operations add ContainerRecreateRequest for restarting a container inside a running pod, ImagePullJob for pre-downloading images onto nodes, ResourceDistribution for pushing Secrets and ConfigMaps across namespaces, PersistentPodState for retaining pod state such as IP, and PodProbeMarker for custom probes. Application protection adds deletion protection and PodUnavailableBudget.

Installing OpenKruise and running a first CloneSet

The README points installation at the project website rather than giving inline steps: the stable version is documented at openkruise.io/docs/installation, and a channel including alpha, beta and rc releases at openkruise.io/docs/next/installation. The repository also ships Helm charts, referenced from the Alibaba Cloud quick-deploy link as the openkruise/charts repository. The project is written in Go and the Dockerfile builds two binaries, a manager and a kruise-daemon, from main.go and ./cmd/daemon/main.go respectively, so a source build starts with the Makefile targets. The Makefile defines the image variables used for that build:

IMG ?= openkruise/kruise-manager:test
HOOK_IMG ?= openkruise/kruise-helm-hook:test
WIN_DAEMON_IMG ?= openkruise/kruise-daemon-win:test
PLATFORMS ?= linux/amd64,linux/arm64,linux/ppc64le

Those are the defaults the Makefile will use if you do not override them. The README does not document a single-command install from this repository, so the website installation page is the place to get the actual deployment steps. Once the controllers are running, the first useful object is a CloneSet, which behaves like a Deployment but supports in-place updates. The README does not print a CloneSet manifest, so read the CloneSet user manual at openkruise.io/docs/user-manuals/cloneset/ for the resource fields and the update policy before you write one.

Where OpenKruise is the wrong tool

OpenKruise adds controllers, custom resource definitions and a daemon component to a cluster. That is a real operational cost. The Dockerfile builds two binaries, a manager and a kruise-daemon, and the manager runs as the entrypoint of the image. The daemon runs per node, which means it must be upgraded in step with the control plane across every node in the cluster. On a managed Kubernetes service where you do not control the node lifecycle, or on a cluster where the built-in controllers already meet your rollout requirements, this is unnecessary surface area. There is also a version coupling to consider. The go.mod pins k8s.io/api, k8s.io/apimachinery and k8s.io/client-go at v0.32.10 and k8s.io/kubernetes at v1.32.10, so the project tracks a specific Kubernetes minor line. Clusters significantly older or newer than that line need their compatibility checked against the installation documentation before you plan an upgrade. Finally, the README does not document rollback or uninstall behaviour for the custom resources. If you create CloneSets and later remove the controllers, the CRDs and their objects remain, and what happens to the pods is not described in the README. Treat that as an open question to resolve from the website documentation before a production rollout.

How OpenKruise differs from KubeVela

KubeVela is a different layer of the stack. It is an application delivery and abstraction platform, built around an Open Application Model, that lets platform teams define reusable components and traits and expose them to developers. It sits above workloads and orchestrates them. OpenKruise does not model applications or provide a developer-facing abstraction; it provides concrete workload controllers and pod-level operations that Kubernetes itself lacks. The practical difference is what you write. With OpenKruise you write a CloneSet or a SidecarSet, which are Kubernetes custom resources with fields close to the built-in workload API. With KubeVela you write an application definition and the platform maps it onto underlying resources, which may themselves be OpenKruise workloads. The two can coexist, and choosing between them is really a question of whether your problem is workload semantics or application delivery.

Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-21, so the codebase is being changed. Recent releases listed are v1.8.5 on 2026-08-10, v1.9.1 on 2026-07-04 and v1.9.0 on 2026-06-21, which shows two release lines being maintained in parallel. The README badge links to the Apache 2.0 licence text, while the repository metadata reports the licence as NOASSERTION, so the machine-readable licence field and the badge disagree. Check LICENSE.md in the repository before you rely on either. Upgrade cost is driven by two things: the per-node daemon, which must be rolled out everywhere, and the CRD schemas, which change between minor versions. The Makefile exposes generate and manifests targets that regenerate deepcopy code and CRD manifests from the API types, which is what maintainers run rather than what cluster operators run. For operators, the relevant question is whether the CRD updates are applied automatically by your install method or need a separate step, and the README does not answer that.

Editorial conclusion

Platform teams running thousands of pods, doing frequent in-place image updates, or managing sidecars across many namespaces are the natural audience for OpenKruise. Teams whose applications already fit Deployments and StatefulSets should stay on the built-in controllers and avoid a second control plane. Before adopting, check the installation page for the current stable version, confirm your Kubernetes version against the k8s.io/api v0.32.10 dependency in go.mod, and read the PodUnavailableBudget and deletion protection manuals to see whether they cover the disruption scenarios you care about.

Frequently asked questions

Official sources

1. Issues
2. openkruise/kruise on GitHub
3. Project website
4. README
5. Releases