What’s New in OpenKruise v1.7? K8s 1.28 Upgrade, SidecarSet, Advanced StatefulSet, and More

OpenKruise is Alibaba Cloud’s open‑source cloud‑native application automation suite, now a CNCF incubating project. Built on years of container and cloud‑native experience, it extends Kubernetes for large‑scale production workloads.

Upgrade to Kubernetes 1.28

The v1.7 release upgrades the internal Kubernetes dependency to version 1.28, bringing several benefits:

SidecarSet, CloneSet, and Advanced StatefulSet can now configure native Kubernetes sidecar containers.

Lays groundwork for in‑place VPA support on CloneSet and Advanced StatefulSet in future releases.

Refactors the Advanced StatefulSet controller’s updateStatefulSet method for better readability.

Note: OpenKruise still runs on clusters with Kubernetes ≥ 1.18; the new features require OpenKruise 1.7.

SidecarSet Native Sidecar Support

Kubernetes 1.28 allows sidecar containers via initContainers[x].restartPolicy=Always, offering two advantages:

Sidecar containers become Ready before the main business container, ensuring logs are captured from the start.

For Job‑type Pods, the sidecar exits automatically after the main container finishes, avoiding blockage.

Example SidecarSet configuration:

apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: test-sidecarset
spec:
  selector:
    matchLabels:
      app: sample
  updateStrategy:
    type: NotUpdate
  initContainers:
  - name: sidecar
    image: nginx:alpine
    restartPolicy: Always
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "sleep 10"]

Note: Current version only supports automatic sidecar injection; in‑place upgrade is not yet available.

If using Kubernetes < 1.28, similar behavior can be achieved with OpenKruise’s Job Sidecar Terminator and Container Launch Priority by setting environment variables KRUISE_TERMINATE_SIDECAR_WHEN_JOB_EXIT and KRUISE_CONTAINER_PRIORITY:

apiVersion: v1
kind: Pod
spec:
  template:
    spec:
      containers:
      - name: sidecar
        env:
        - name: KRUISE_TERMINATE_SIDECAR_WHEN_JOB_EXIT
          value: "true"
        - name: KRUISE_CONTAINER_PRIORITY
          value: "1"
      - name: main
        image: centos:6.7

Advanced StatefulSet Start Ordinal

Pods normally start numbering from 0. By setting .spec.ordinals.start and enabling the feature gate StatefulSetStartOrdinal=true, you can define a custom start index.

apiVersion: apps.kruise.io/v1beta1
kind: StatefulSet
metadata:
  name: sample
spec:
  replicas: 5
  ordinals:
    start: 3
  serviceName: fake-service
  selector:
    matchLabels:
      app: sample
  template:
    metadata:
      labels:
        app: sample
    spec:
      containers:
      - name: main
        image: nginx:alpine

Image Pre‑heat with Credential Provider Plugins

Since Kubernetes v1.20, kubelet can use exec‑based credential provider plugins to obtain temporary image registry credentials. This is useful when:

Accessing cloud‑provider APIs for registry authentication.

Credentials have short lifetimes and need frequent refresh.

Storing credentials on disk or in imagePullSecret is undesirable.

OpenKruise supports the same mechanism. Steps:

Install a cloud‑provider credential plugin on the node (e.g., AWS ECR credential provider).

Create a ConfigMap with the plugin configuration.

Provide the plugin’s credentials (e.g., mount $HOME/.aws into the kruise daemon).

Deploy an ImagePullJob that uses the plugin to pre‑heat images.

helm install kruise https://... \
  --set daemon.credentialProvider.enable=true \
  --set daemon.credentialProvider.hostPath=/etc/eks/image-credential-provider \
  --set daemon.credentialProvider.configmap=credential-provider-config \
  --set daemon.credentialProvider.awsCredentialsDir=/root/.aws

External CA Injection (Cert‑Manager)

OpenKruise generates a self‑signed CA for webhook authentication by default, but you can inject an external CA using tools like Cert‑Manager:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: kruise-webhook-certs
  namespace: kruise-system
spec:
  secretName: kruise-webhook-certs
  dnsNames:
  - kruise-webhook-service.kruise-system.svc
  - localhost
  issuerRef:
    name: selfsigned-kruise
    kind: Issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-kruise
  namespace: kruise-system
spec:
  selfSigned: {}

Enable the feature gate EnableExternalCerts=true and annotate the webhook configuration accordingly:

helm install kruise https://... \
  --set featureGates="EnableExternalCerts=true" \
  --set-json externalCerts.annotations='{"cert-manager.io/inject-ca-from":"kruise-system/kruise-webhook-certs"}'

Structured Logging

Starting with OpenKruise 1.17, logs can be emitted in a structured key="value" format while remaining backward compatible as plain strings. To output JSON logs, set the Helm flag --set manager.loggingFormat=json. Example:

klog.V(3).InfoS("SidecarSet updated status success", "sidecarSet", klog.KObj(sidecarSet), "matchedPods", status.MatchedPods, "updatedPods", status.UpdatedPods, "readyPods", status.ReadyPods, "updateReadyPods", status.UpdatedReadyPods)

Resulting plain‑text log:

I0821 14:22:35.587919 1 sidecarset_processor.go:280] "SidecarSet updated status success" sidecarSet="test-sidecarset" matchedPods=1 updatedPods=1 readyPods=1 updateReadyPods=1

Resulting JSON log (when enabled):

{
  "ts": 1724239224606.642,
  "caller": "sidecarset/sidecarset_processor.go:280",
  "msg": "SidecarSet updated status success",
  "v": 3,
  "sidecarSet": {"name": "test-sidecarset"},
  "matchedPods": 1,
  "updatedPods": 1,
  "readyPods": 0,
  "updateReadyPods": 0
}

Future Roadmap

Release 1.8: CloneSet/Advanced StatefulSet will support PVCs and in‑place Resources updates; SidecarSet will gain in‑place upgrade of native sidecars.

Release 1.9: Kruise API moves to v1beta1, adds Liveness Probe feature, and introduces a minimal deployment option.

Community members are encouraged to contribute via GitHub, Slack, DingTalk, or WeChat.