All Products
Search
Document Center

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

Last Updated:Feb 29, 2024

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

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.

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

  2. On the Clusters page, click the name of the cluster that you want to manage and choose Operations > Add-ons in the left-side navigation pane.

  3. 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

  1. Create a CloneSet.

    1. 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: registry.cn-hangzhou.aliyuncs.com/kruise-test/guestbook:v1
              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.

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

      kubectl create -f ./cloneset.yaml

      Expected output:

      cloneset.apps.kruise.io/demo-clone created
  2. 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
  3. 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

  1. Create an Advanced StatefulSet.

    1. 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: registry.cn-hangzhou.aliyuncs.com/kruise-test/guestbook:v1
              env:
              - name: test
                value: foo
              volumeMounts:
              - name: log-volume
                mountPath: /var/log
            readinessGates:
            - conditionType: InPlaceUpdateReady
            volumes:
            - name: log-volume
              emptyDir: {}
        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.

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

       kubectl create -f ./statefulset.yaml

      Expected output:

      statefulset.apps.kruise.io/demo-asts created
  2. 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
  3. 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).