What’s New in OpenKruise v0.9.0? Container Restart, Deletion Protection, and CloneSet Enhancements

Background

OpenKruise is an open‑source cloud‑native application automation suite hosted by the CNCF, extending Kubernetes with production‑grade features developed at Alibaba. Version v0.9.0, released on May 20, 2021, adds several major capabilities.

Pod Container Restart

Kubernetes natively only supports creating and deleting Pods, lacking a container‑level restart operation. OpenKruise v0.9.0 provides a ContainerRecreateRequest (CRR) custom resource that lets users restart specific containers within a Pod.

apiVersion: apps.kruise.io/v1alpha1
kind: ContainerRecreateRequest
metadata:
  namespace: pod-namespace
  name: xxx
spec:
  podName: pod-name
  containers:
  - name: app
  - name: sidecar

Required fields are namespace, name, podName, and the list of containers to restart. Optional strategy fields allow fine‑grained control:

spec:
  # ...
  strategy:
    failurePolicy: Fail
    orderedRecreate: false
    terminationGracePeriodSeconds: 30
    unreadyGracePeriodSeconds: 3
    minStartedSeconds: 10
  activeDeadlineSeconds: 300
  ttlSecondsAfterFinished: 1800

failurePolicy: Fail (default) aborts the CRR if any container fails.

orderedRecreate: false (default) restarts containers concurrently; true enforces sequential recreation.

terminationGracePeriodSeconds: graceful shutdown timeout (uses Pod’s value if omitted).

unreadyGracePeriodSeconds: time to set the Pod not ready before recreation.

minStartedSeconds: minimum running time for a new container to be considered successful.

activeDeadlineSeconds: maximum total execution time for the CRR.

ttlSecondsAfterFinished: automatic deletion delay after completion.

The restart process is handled by the kruise‑manager and kruise‑daemon on the node, executing any preStop hook, stopping the container via CRI, letting kubelet create a new container (incrementing restartCount), and finally reporting success.

Cascade Deletion Protection

Kubernetes’ cascade‑delete semantics can cause accidental large‑scale resource removal. OpenKruise v0.9.0 adds a feature‑gate ResourcesDeletionProtection that, when enabled, lets users label resources with policy.kruise.io/delete-protection set to Always (prevent deletion unless label is removed) or Cascading (prevent deletion if dependent resources exist). Supported resource types include Namespace, CRD, Deployment, StatefulSet, ReplicaSet, CloneSet, and UnitedDeployment, each with specific cascade‑check logic (e.g., a Namespace can be deleted only if no Pods remain).

CloneSet New Features

1. Deletion Cost Ordering

From Kubernetes 1.21, the annotation controller.kubernetes.io/pod-deletion-cost influences Pod deletion order. OpenKruise v0.9.0 makes CloneSet respect this annotation, where a lower integer cost gives higher deletion priority.

2. Image Pre‑download for In‑Place Updates

When the feature‑gate PreDownloadImageForInPlaceUpdate is enabled, updating a CloneSet’s image triggers automatic creation of ImagePullJob objects that pre‑pull the new image on each node. The default parallelism is 1; it can be customized via the annotation apps.kruise.io/image-predownload-parallelism:

apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
  annotations:
    apps.kruise.io/image-predownload-parallelism: "5"

3. Pod Replacement Strategies (Expand‑Then‑Shrink)

CloneSet now applies maxUnavailable and maxSurge not only during rollout but also when users explicitly delete Pods via podsToDelete or the apps.kruise.io/specified-delete: true label. Depending on the current unavailable count, CloneSet may create a new Pod first (respecting maxSurge) and delete the old one later, or delete first and then create.

4. Partition‑Based Rollback

Enabling the feature‑gate CloneSetPartitionRollback allows “final‑state rollback”: increasing the partition value after a rollout will automatically roll back the corresponding number of Pods to the previous revision (identified by currentRevision vs. updateRevision).

5. Short Hash Labels

Normally CloneSet adds a full controller-revision-hash label (e.g., demo-cloneset-956df7994), limiting Pod name length. The feature‑gate CloneSetShortHash shortens this label to just the hash (e.g., 956df7994), removing the length restriction.

apiVersion: v1
kind: Pod
metadata:
  labels:
    controller-revision-hash: demo-cloneset-956df7994

SidecarSet Hot Upgrade

SidecarSet manages sidecar containers across a set of Pods. The new hot‑upgrade strategy allows seamless replacement of sidecars (e.g., Envoy) without disrupting the main application. Users define an upgradeStrategy with upgradeType: HotUpgrade and provide an empty placeholder image for the transition.

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
spec:
  containers:
  - name: nginx-sidecar
    image: nginx:1.18
    lifecycle:
      postStart:
        exec:
          command:
          - /bin/bash
          - -c
          - /usr/local/bin/nginx-agent migrate
    upgradeStrategy:
      upgradeType: HotUpgrade
      hotUpgradeEmptyImage: empty:1.0.0

The hot‑upgrade process swaps the running sidecar with the empty container, then starts the new sidecar, allowing custom state migration scripts to run.

Further Information

For detailed usage, refer to the official OpenKruise documentation and the GitHub repositories linked in the original article.