How to use OpenKruise to deploy cloud-native applications - Container Service for Kubernetes

OpenKruise is a standard Kubernetes extension component. It extends native Kubernetes to provide efficient management of application containers, sidecars, and image distribution. This topic describes how to use OpenKruise to deploy cloud-native applications.

Prerequisites

You have created an ACK managed cluster.

Background information

OpenKruise is a cloud-native application automation engine that was open-sourced by Alibaba Cloud. It has officially joined the Cloud Native Computing Foundation (CNCF) Sandbox. OpenKruise includes various custom workloads for deploying and managing stateless applications, stateful applications, sidecar containers, and daemon applications. It also provides advanced deployment policies, such as in-place upgrades, phased releases, stream releases, and configuration priorities.

Component architecture

OpenKruise

OpenKruise is a standard Kubernetes extension and is deployed natively in Kubernetes clusters. It consists of the following three components.

Component	Description
Kruise-manager	Kruise-manager is a central component that runs controllers and webhooks. It is deployed as a deployment in the kruise-system namespace. It uses controllers and webhooks to implement core features such as in-place upgrades and sidecar management.
Kruise-daemon	It is deployed as a DaemonSet on each node to provide features such as image prefetch and container restarts.
Kruise-Rollout	Kruise-Rollout is a standard extension component based on Kubernetes. It includes a complete Rollout model definition and implementation. It supports canary releases, blue-green deployments, and A/B testing releases that coordinate with application traffic and deployed instances. It also provides seamless bypass integration and is compatible with various existing workloads.

Usage notes

The following section describes the features of common OpenKruise controllers, such as CloneSet, Advanced StatefulSet, and Advanced DaemonSet.

Table 1. Common controllers

Controller	Feature
CloneSet	Manages stateless applications and is equivalent to the native Kubernetes Deployment. For more information, see CloneSet. The fields in its YAML file are not fully compatible with a deployment, but it provides all the features of a deployment and offers more advanced policies.
Advanced StatefulSet	Manages stateful applications and is comparable to the native Kubernetes StatefulSet. For more information, see Advanced StatefulSet. The fields in its YAML file are fully compatible with a native StatefulSet. Simply change the `apiVersion` to `apps.kruise.io/v1alpha1`. It also provides an `optional` field to extend release policies, such as in-place upgrades and parallel releases.
Advanced DaemonSet	An Advanced DaemonSet manages daemon applications and is equivalent to a native Kubernetes DaemonSet. For more information, see Advanced DaemonSet. The fields in its YAML file are fully compatible with a native DaemonSet. Simply change the `apiVersion` to `apps.kruise.io/v1alpha1`. It also provides an `optional` field to extend release policies, such as hot upgrades, phased releases, and phased releases based on node labels.
SidecarSet	The SidecarSet controller independently manages sidecar containers and injects sidecar containers to pods. For more information, see SidecarSet. Define a sidecar container and a label selector in a separate custom resource (CR). OpenKruise then injects the defined sidecar container into all pods that match the selector when they are created. It also supports in-place upgrades for injected sidecar containers.
UnitedDeployment	Manages multiple Sub Workloads in different regions. For more information, see UnitedDeployment. It currently supports CloneSet, StatefulSet, and Advanced StatefulSet as sub-workloads. You can use a single UnitedDeployment to define the deployment replicas for sub-workloads in different regions.

The following table compares the features of the CloneSet, Advanced StatefulSet, and Advanced DaemonSet controllers with their counterparts in the Kubernetes community.

Table 2. Feature comparison with community controllers

Feature	CloneSet vs. Deployment		Advanced StatefulSet vs. StatefulSet		Advanced DaemonSet vs. DaemonSet
Feature	CloneSet	Deployment	Advanced StatefulSet	StatefulSet	Advanced DaemonSet	DaemonSet
Stream scale-out
Targeted scale-in
Recreate upgrade
In-place upgrade
Phased release
Available quantity
Max surge
Customize release order with priority and scatter policies
Manage pod lifecycle with hooks

Install OpenKruise

Log on to the ACK console. In the navigation pane on the left, click Clusters.
On the Clusters page, find the one you want to manage and click its name. In the navigation pane on the left, click Add-ons.
On the Add-ons page, click the Applications tab. In the ack-kruise section, click Install.
In the Install Ack-kruise dialog box, confirm the component information and click OK.

Use a CloneSet to deploy a stateless application

Create a CloneSet.

Create a cloneset.yaml file.

apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
  name: demo-clone
spec:
  replicas: 5
  selector:
    matchLabels:
      app: guestbook
  template: # The pod template structure is identical to that of 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 the in-place method for the upgrade if possible. Otherwise, use the recreate method.
    maxUnavailable: 20%        # During the release, a maximum of 20% of the pods can be unavailable.
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 3    # The graceful wait time for a pod in the NotReady state before an in-place upgrade.

type: Specifies the upgrade policy. The following upgrade methods are supported:
- ReCreate: The controller deletes the old pods and PersistentVolumeClaims (PVCs) and then creates new ones with the new version.
- InPlaceIfPossible: The controller first attempts to perform an in-place upgrade on the pods. If the in-place upgrade fails, the controller recreates the pods.
- InPlaceOnly: The controller performs only in-place upgrades.
maxUnavailable: The maximum number of pods that can be unavailable during a release. The value can be an absolute number or a percentage.
gracePeriodSeconds: The grace period in seconds for a pod in the NotReady state before an in-place upgrade is performed.

Apply the cloneset.yaml file to the ACK cluster.

kubectl create -f cloneset.yaml

Expected output:

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

Check the 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

Check the CloneSet.
```
kubectl get clone
```
Expected output:
```
NAME         DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
demo-clone   5         5         5               5       5       46s
```
- DESIRED: The desired number of pods (spec.replicas).
- UPDATED: The number of pods updated to the latest version (status.updatedReplicas).
- UPDATED_READY: The number of available pods updated to the latest version (status.updatedReadyReplicas).
- READY: The total number of available pods (status.readyReplicas).
- TOTAL: The total number of actual pods (status.replicas).

Use an Advanced StatefulSet to deploy a stateful application

Create an Advanced StatefulSet.

Create a statefulset.yaml file.

apiVersion: apps.kruise.io/v1alpha1
kind: StatefulSet
metadata:
  name: demo-asts
spec:
  replicas: 3
  selector:
    matchLabels:
      app: guestbook-sts
  podManagementPolicy: Parallel
  template: # The pod template structure is identical to that of 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 the in-place method for the upgrade if possible. Otherwise, use the recreate method.
      maxUnavailable: 20%                  # During the release, a maximum of 20% of the pods can be unavailable.
      inPlaceUpdateStrategy:
        gracePeriodSeconds: 3              # The graceful wait time for a pod in the NotReady state before an in-place upgrade.

type: Specifies the pod upgrade policy. The following upgrade methods are supported.
- ReCreate: The controller deletes the old pods and PVCs and then creates new ones with the new version.
- InPlaceIfPossible: The controller first attempts to perform an in-place upgrade on the pods. If the in-place upgrade fails, the controller recreates the pods.
- InPlaceOnly: The controller performs only in-place upgrades.
maxUnavailable: The maximum number of pods that can be unavailable during a release. The value can be an absolute number or a percentage.
gracePeriodSeconds: The grace period in seconds for a pod in the NotReady state before an in-place upgrade is performed.

Apply the statefulset.yaml file to the ACK cluster.

 kubectl create -f statefulset.yaml

Expected output:

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

Check the 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

Check the Advanced StatefulSet.
```
kubectl get asts
```
Expected output:
```
NAME        DESIRED   CURRENT   UPDATED   READY   AGE
demo-asts   3         3         3         3       3h30m
```
- DESIRED: The desired number of pods (spec.replicas).
- UPDATED: The number of pods at the latest version (status.updatedReplicas).
- READY: The total number of ready pods (status.readyReplicas).
- TOTAL: The total number of pods (status.replicas).