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

OpenKruise is a set of standard extensions for Kubernetes. It can be used with native Kubernetes to efficiently manage application pods, sidecar containers, and image distribution. This topic describes how to use OpenKruise to deploy cloud-native applications.

Prerequisites

A Container Service for Kubernetes (ACK) managed cluster that runs Kubernetes 1.13 or later is created. For more information, see Create an ACK managed cluster.

Background information

OpenKruise is an open source automation engine that Alibaba Cloud provides for cloud-native applications. It is used as a deployment base to migrate the business of Alibaba Group to the cloud. OpenKruise has joined the Cloud Native Computing Foundation (CNCF) Sandbox project.

OpenKruise contains various types of custom workloads. You can use the workloads to deploy and manage stateless applications, stateful applications, sidecar containers, and daemon applications. OpenKruise also supports advanced strategies such as in-place upgrades, canary releases, stream upgrades, and priority configuration.

Component architecture

OpenKruise

OpenKruise is a set of standard extensions for Kubernetes and can be deployed as Kubernetes-native components in ACK clusters. OpenKruise includes the following three components.

Component	Description
Kruise-manager	Kruise-manager is a control plane component that runs controllers and webhooks. It is deployed by a Deployment in the kruise-system namespace. It uses controllers and webhooks to implement key features such as in-place upgrades and sidecar management.
Kruise-daemon	Kruise-daemon is deployed as a DaemonSet on each node, and manages features such as image pre-download and container restart.
Kruise-Rollout	Kruise-Rollout is a Kubernetes-based standard extension and bypass component that supports complete Rollout model definitions and implementations. You can use Kruise-Rollout to perform canary releases, blue-green deployments, and A/B testing for multiple Kubernetes workloads.

Usage notes

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

Table 1. Commonly used controllers

Controller	Feature
CloneSet	CloneSets are equivalent to Kubernetes-native Deployments. CloneSets are used to manage stateless applications. For more information, see CloneSet. The fields in a CloneSet YAML file do not completely match those in a Deployment YAML file. However, CloneSets support all features of Deployments and provide more strategies.
Advanced StatefulSet	Advanced StatefulSets are equivalent to Kubernetes-native StatefulSets. Advanced StatefulSets are used to manage stateful applications. For more information, see Advanced StatefulSet. The fields in an Advanced StatefulSet YAML file completely match those in a StatefulSet YAML file. You need only to change the value of `apiVersion` to `apps.kruise.io/v1alpha1`. In addition, you can set the `optional` field to use more release strategies, such as in-place upgrades and parallel releases.
Advanced DaemonSet	Advanced DaemonSets are equivalent to Kubernetes-native DaemonSets. Advanced DaemonSets are used to manage daemon applications. For more information, see Advanced DaemonSet. The fields in an Advanced DaemonSet YAML file completely match those in a DaemonSet YAML file. You need only to change the value of `apiVersion` to `apps.kruise.io/v1alpha1`. In addition, you can set the `optional` field to use more release strategies, such as hot upgrades, canary releases, and canary releases by node label.
SidecarSet	The SidecarSet controller independently manages sidecar containers and injects sidecar containers to pods. For more information, see SidecarSet. After you define a sidecar container and a label selector in an independent custom resource (CR), OpenKruise injects the defined sidecar container to the pod that matches the conditions when the pod is created. You can also perform in-place upgrades for the injected sidecar container by using a SidecarSet.
UnitedDeployment	The UnitedDeployment controller manages multiple sub-workloads in different regions. For more information, see UnitedDeployment. The UnitedDeployment controller supports the following sub-workloads: CloneSets, StatefulSets, and Advanced StatefulSets. You can use one UnitedDeployment to manage sub-workloads in different regions and replicated pods of these sub-workloads.

The following section compares the CloneSet, Advanced StatefulSet, and Advanced DaemonSet controllers of OpenKruise with the equivalent controllers provided by the Kubernetes community.

Table 2. Feature comparison

Feature	CloneSet VS Deployment		Advanced StatefulSet VS StatefulSet		Advanced DaemonSet VS DaemonSet
Feature	CloneSet	Deployment	Advanced StatefulSet	StatefulSet	Advanced DaemonSet	DaemonSet
Stream scaling
Selective pod deletion
Upgrade pods upon recreation
In-place pod upgrade
Canary release
Maximum available pods
MaxSurge
Custom release sequence by using the priority or scatter strategy
Pod lifecycle management by using the lifecycle hook

Install OpenKruise

Important

Before you install OpenKruise, make sure that the Kubernetes version is 1.13 or later. Before you install OpenKruise, make sure that the Kubernetes version is 1.13 or later. If you use Kubernetes 1.13 or 1.14, you must enable the CustomResourceWebhookConversion feature gate in kube-apiserver before you install OpenKruise. For more information, see Feature gates.
Image repositories in the China (Hangzhou) region are unavailable. If you fail to pull the registry.cn-hangzhou.cr.aliyuncs.com/openkruise/kruise-manager image, pull the registry.cn-shanghai.cr.aliyuncs.com/openkruise/kruise-manager image instead.

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side navigation pane, choose Operations > Add-ons.
On the Add-ons page, click the Manage Applications tab. In the ack-kruise section, click Install.
In the Note dialog box, confirm the component information and click OK.

Use a CloneSet to deploy a stateless application

Create a CloneSet.

Create a file named cloneset.yaml and copy the following code to the file:

apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
  name: demo-clone
spec:
  replicas: 5
  selector:
    matchLabels:
      app: guestbook
  template: #The schema of the pod template is the same as 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     #We recommend that you perform an in-place upgrade instead of upgrading pods upon recreation. 
    maxUnavailable: 20%        #A maximum of 20% pods can be unavailable during the release. 
    inPlaceUpdateStrategy:
      gracePeriodSeconds: 3    #The graceful period specifies how long a pod stays in the Not-ready state before the controller performs an in-place upgrade on the pod.

type: specifies the upgrade strategy. The following three strategies are supported:
- ReCreate: The controller deletes the current pods and PVCs, and then creates new pods and PVCs.
- InPlaceIfPossible: The controller attempts to perform an in-place upgrade. If the attempt fails, the controller upgrades the pods by recreating them.
- InPlaceOnly: The controller is allowed to perform only in-place upgrades.
maxUnavailable: The maximum number of pods that can be unavailable during the upgrade process. You can specify an absolute value or a percentage value.
gracePeriodSeconds: The grace period specifies how long a pod stays in the Not-ready state before the controller performs an in-place upgrade on the pod.

Make the cloneset.yaml file effective in the ACK cluster.

kubectl create -f ./cloneset.yaml

Expected output:

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

Query the status of the pods:

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

Query 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 expected number of pods (spec.replicas).
- UPDATED: the number of pods that are upgraded (status.updatedReplicas).
- UPDATED_READY: the number of pods that are available after the pods are upgraded (status.updatedReadyReplicas).
- READY: the total number of available pods (status.readyReplicas).
- TOTAL: the total number of pods (status.replicas).

Use an Advanced StatefulSet to deploy a stateful application

Create an Advanced StatefulSet.

Create a file named statefulset.yaml.

apiVersion: apps.kruise.io/v1alpha1
kind: StatefulSet
metadata:
  name: demo-asts
spec:
  replicas: 3
  selector:
    matchLabels:
      app: guestbook-sts
  podManagementPolicy: Parallel
  template: #The schema of the pod template is the same as that of a StatefulSet YAML. 
    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 #We recommend that you perform an in-place upgrade instead of upgrading pods upon recreation. 
      maxUnavailable: 20%                  #A maximum of 20% pods can be unavailable during the release. 
      inPlaceUpdateStrategy:
        gracePeriodSeconds: 3    #The graceful period specifies how long a pod stays in the Not-ready state before the controller performs an in-place upgrade on the pod.

type: specifies the upgrade strategy. The following three strategies are supported:
- ReCreate: The controller deletes the current pods and PVCs, and then creates new pods and PVCs.
- InPlaceIfPossible: The controller attempts to perform an in-place upgrade. If the attempt fails, the controller upgrades the pods by recreating them.
- InPlaceOnly: The controller is allowed to perform only in-place upgrades.
maxUnavailable: The maximum number of pods that can be unavailable during the upgrade process. You can specify an absolute value or a percentage value.
gracePeriodSeconds: The grace period specifies how long a pod stays in the Not-ready state before the controller performs an in-place upgrade on the pod.

Make the statefulset.yaml file effective in the ACK cluster.

 kubectl create -f ./statefulset.yaml

Expected output:

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

Query the status of the pods:

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

Query the Advanced StatefulSet.
```
kubectl get asts
```
Expected output:
```
NAME        DESIRED   CURRENT   UPDATED   READY   AGE
demo-asts   3         3         3         3       3h30m
```
- DESIRED: the expected number of pods (spec.replicas).
- UPDATED: the number of pods that are upgraded (status.updatedReplicas).
- READY: the total number of available pods (status.readyReplicas).
- TOTAL: the total number of pods (status.replicas).