All Products
Search

This Product

    Container Service for Kubernetes:Use OpenKruise to deploy cloud-native applications

    Document Center

    Container Service for Kubernetes:Use OpenKruise to deploy cloud-native applications

    Last Updated:Mar 26, 2026

    OpenKruise extends native Kubernetes with advanced workload management capabilities that the native Kubernetes API does not support, including in-place pod upgrades, independent sidecar injection, and image prefetching. This document explains how to install OpenKruise on an ACK cluster and deploy applications using CloneSet and Advanced StatefulSet.

    Prerequisites

    Before you begin, ensure that you have:

    How OpenKruise works

    OpenKruise is an open-source, cloud-native application automation engine from Alibaba Cloud. It is a member of the Cloud Native Computing Foundation (CNCF) Sandbox and runs natively inside Kubernetes clusters as a standard extension.

    OpenKruise consists of three components:

    ComponentDescription
    Kruise-managerThe central control plane, deployed as a Deployment in the kruise-system namespace. Runs controllers and webhooks that implement features such as in-place upgrades and sidecar management.
    Kruise-daemonDeployed as a DaemonSet on every node. Handles node-level operations including image prefetching and container restarts.
    Kruise-RolloutA standalone extension that adds a complete Rollout model to Kubernetes. Supports canary releases, blue-green deployments, and A/B testing releases coordinated with live traffic and running instances.
    OpenKruise architecture

    Controllers

    OpenKruise provides five workload controllers. Each is a superset of its native Kubernetes equivalent:

    ControllerNative equivalentYAML compatibilityKey capabilities
    CloneSetDeploymentNot fully compatibleIn-place upgrades, targeted scale-in, stream scale-out, phased releases
    Advanced StatefulSetStatefulSetFully compatible — change only apiVersionIn-place upgrades, parallel pod management, phased releases
    Advanced DaemonSetDaemonSetFully compatible — change only apiVersionHot upgrades, phased releases, node-label-based release ordering
    SidecarSetN/AStandalone custom resourceIndependent sidecar lifecycle management, automatic injection, in-place sidecar upgrades
    UnitedDeploymentN/AStandalone custom resourceMulti-region sub-workload management across CloneSet, StatefulSet, and Advanced StatefulSet

    Upgrade strategies

    OpenKruise controllers support three upgrade strategies:

    StrategyBehaviorWhen to use
    ReCreateDeletes old pods and PersistentVolumeClaims (PVCs), then creates new onesDefault Kubernetes behavior; use when pod identity does not need to be preserved
    InPlaceIfPossibleAttempts an in-place upgrade first; falls back to recreate if the change cannot be applied in-placeRecommended for most production workloads
    InPlaceOnlyAlways performs in-place upgrades; rejects changes that would require pod recreationUse when pod IP, name, and node must remain unchanged

    Why choose in-place upgrades?

    Standard Kubernetes rolling updates recreate pods, which means pod name, IP address, and host node all change. An in-place upgrade modifies the running pod directly:

    • No rescheduling — the pod stays on the same node

    • Faster image pulls — most image layers are already cached on the node

    • Other containers in the pod are unaffected during the upgrade

    Install OpenKruise

    1. Log on to the ACK console. In the left navigation pane, click Clusters.

    2. On the Clusters page, click the name of the cluster you want to manage. In the left navigation pane, click Add-ons.

    3. On the Add-ons page, click the Applications tab. In the ack-kruise section, click Install.

    4. In the Install Ack-kruise dialog box, confirm the component information and click OK.

    Deploy a stateless application with CloneSet

    CloneSet manages stateless applications and provides all Deployment capabilities plus advanced policies such as in-place upgrades and targeted pod deletion.

    Note

    CloneSet's YAML schema is not fully compatible with a native Deployment. Do not convert an existing Deployment manifest directly — create a new CloneSet resource instead.

    Create a CloneSet

    1. Create a file named cloneset.yaml with the following content:

      apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
  name: demo-clone
spec:
  replicas: 5
  selector:
    matchLabels:
      app: guestbook
  template: # Pod template structure is identical to a Deployment
    metadata:
      labels:
        app: guestbook
    spec:
      containers:
      - name: guestbook
        image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
        env:
        - name: test
          value: foo
  updateStrategy:
    type: InPlaceIfPossible     # Use in-place upgrade if possible; fall back to recreate
    maxUnavailable: 20%         # Allow up to 20% of pods to be unavailable during an upgrade
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 3     # Seconds to wait after marking the pod NotReady before upgrading in-place

      Key parameters:

      ParameterDescription
      typeUpgrade strategy: ReCreate, InPlaceIfPossible, or InPlaceOnly. See Upgrade strategies.
      maxUnavailableMaximum number or percentage of pods that can be unavailable during an upgrade.
      gracePeriodSecondsSeconds the controller waits after marking a pod NotReady before performing the in-place upgrade.

    2. Apply the manifest to your cluster:

      kubectl create -f cloneset.yaml

      Expected output:

      cloneset.apps.kruise.io/demo-clone created

    Verify the CloneSet

    1. Check pod status:

      kubectl get pod

      Expected output:

      NAME               READY   STATUS    RESTARTS   AGE
demo-clone-5b9kl   1/1     Running   0          3s
demo-clone-6xjdg   1/1     Running   0          3s
demo-clone-bvmdj   1/1     Running   0          3s
demo-clone-dm22s   1/1     Running   0          3s
demo-clone-rbpg9   1/1     Running   0          3s

    2. Check the CloneSet status:

      kubectl get clone

      Expected output:

      NAME         DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo-clone   5         5         5               5       5       46s

      Output fields:

      FieldKubernetes status fieldDescription
      DESIREDspec.replicasDesired number of pods
      UPDATEDstatus.updatedReplicasPods updated to the latest version
      UPDATED_READYstatus.updatedReadyReplicasReady pods among those at the latest version
      READYstatus.readyReplicasTotal ready pods across all versions
      TOTALstatus.replicasTotal pods managed by this CloneSet

    Deploy a stateful application with Advanced StatefulSet

    Advanced StatefulSet is a drop-in replacement for the native StatefulSet. Its YAML schema is fully compatible — the only required change is the apiVersion.

    Migrate from a native StatefulSet

    To use Advanced StatefulSet with an existing StatefulSet manifest, change one line:

    - apiVersion: apps/v1
+ apiVersion: apps.kruise.io/v1alpha1
  kind: StatefulSet

    The rest of the manifest remains unchanged.

    Create an Advanced StatefulSet

    1. Create a file named statefulset.yaml with the following content:

      apiVersion: apps.kruise.io/v1alpha1
kind: StatefulSet
metadata:
  name: demo-asts
spec:
  replicas: 3
  selector:
    matchLabels:
      app: guestbook-sts
  podManagementPolicy: Parallel
  template: # Pod template structure is identical to a native StatefulSet
    metadata:
      labels:
        app: guestbook-sts
    spec:
      containers:
      - name: guestbook
        image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
        env:
        - name: test
          value: foo
      readinessGates:
      - conditionType: InPlaceUpdateReady
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      podUpdatePolicy: InPlaceIfPossible   # Use in-place upgrade if possible; fall back to recreate
      maxUnavailable: 20%                  # Allow up to 20% of pods to be unavailable during an upgrade
      inPlaceUpdateStrategy:
        gracePeriodSeconds: 3              # Seconds to wait after marking the pod NotReady before upgrading in-place

      Key parameters:

      ParameterDescription
      podUpdatePolicyUpgrade strategy: ReCreate, InPlaceIfPossible, or InPlaceOnly. See Upgrade strategies.
      maxUnavailableMaximum number or percentage of pods that can be unavailable during an upgrade.
      gracePeriodSecondsSeconds the controller waits after marking a pod NotReady before performing the in-place upgrade.

    2. Apply the manifest to your cluster:

      kubectl create -f statefulset.yaml

      Expected output:

      statefulset.apps.kruise.io/demo-asts created

    Verify the Advanced StatefulSet

    1. Check pod status:

      kubectl get pod

      Expected output:

      NAME          READY   STATUS    RESTARTS   AGE
demo-asts-0   1/1     Running   0          3h29m
demo-asts-1   1/1     Running   0          3h29m
demo-asts-2   1/1     Running   0          3h29m

    2. Check the Advanced StatefulSet status:

      kubectl get asts

      Expected output:

      NAME        DESIRED   CURRENT   UPDATED   READY   AGE
demo-asts   3         3         3         3       3h30m

      Output fields:

      FieldKubernetes status fieldDescription
      DESIREDspec.replicasDesired number of pods
      UPDATEDstatus.updatedReplicasPods at the latest version
      READYstatus.readyReplicasTotal ready pods
      TOTALstatus.replicasTotal pods managed by this Advanced StatefulSet