OpenKruise

Introduction

OpenKruise is an extended component suite for Kubernetes. It leverages CRDs to offer advanced workload and application management features, including automatic deployment, release, O&M, and availability protection for cloud native applications. This simplifies and streamlines application management, making it more efficient.

OpenKruise has the following core capabilities:

• Advanced workloads: It contains a set of advanced workloads, such as CloneSets and Advanced StatefulSets.
• Application sidecar management: It provides many SidecarSets to make sidecar inject easier and offers other capabilities like in-place sidecar upgrades.
• Application security protection: It protects your Kubernetes resources from being interfered by the cascading deletion mechanism.
• Efficient application O&M: It provides many advanced O&M capabilities to help you better manage applications. For example, you can use ImagePullJob to pull some images from any nodes beforehand or restart containers in a running pod.

Open-source community: https://github.com/openkruise/kruise

Typical OpenKruise Workload Controllers

OpenKruise includes workload controllers like CloneSets, Advanced StatefulSets, and Advanced DaemonSets. The typical types of workloads are listed in the table below.

Notes and Constraints

If you have deployed the community OpenKruise in your cluster, uninstall it and then install the CCE OpenKruise add-on. Otherwise, the add-on may fail to be installed.

Precautions

OpenKruise has added webhooks to its open-source components. The default pod failure policy has been set to Fail by the community. This means that if kruise-controller-manager becomes unavailable, operations like pod creation and deletion will be blocked. Before using this add-on, it is important to carefully assess the risks and configure HA for kruise-controller-manager to ensure that the webhook server can handle requests properly.

Since OpenKruise 1.7.3, Kruise, installed through Helm charts, uses a pre-delete hook to automatically check for the presence of Kruise CRs during uninstallation. If any Kruise CRs are detected, the uninstallation process is blocked. This prevents accidental deletion of CRs but also causes the uninstallation to fail. So, before uninstalling the add-on, you must verify that all Kruise-related CRs have been cleared to ensure the add-on can be removed successfully.

OpenKruise is an open-source add-on that CCE has selected, adapted, and integrated into its services. CCE offers comprehensive technical support, but is not responsible for any service disruptions caused by defects in the open-source software, nor does it provide compensation or additional services for such disruptions. It is highly recommended that you regularly upgrade your software to address any potential issues.

Installing the Add-on

1. Log in to the CCE console and click the cluster name to access the cluster console.
2. In the navigation pane, choose Add-ons. Locate OpenKruise on the right and click Install.
3. On the Install Add-on page, configure the specifications as needed.
   • If you select Preset, choose Small or Large based on your cluster scale. CCE automatically configures the number of add-on pods and resource quotas according to the selected specification. You can view these configurations on the console.

     The small specification specifies that the add-on runs in one pod, which is ideal for clusters with fewer than 50 nodes. The large specification specifies that the add-on runs in two pods, which are suitable for clusters with more than 50 nodes.

   • If you selected Custom, you can adjust the number of pods and resource quotas as needed. High availability is not possible with a single pod. If an error occurs on the node where the add-on pod runs, the add-on will fail.

4. Check whether to enable KruiseDaemon.

   KruiseDaemon, a new DaemonSet component, has been added to OpenKruise. It provides image warm-up and container restarts. For details, see Components.

5. Configure deployment policies for the add-on pods.
   

   • Scheduling policies do not take effect on the DaemonSet pods of the add-on.
   • When configuring multi-AZ deployment or node affinity, ensure that there are nodes meeting the scheduling policy and that resources are sufficient in the cluster. Otherwise, the add-on pods cannot run.

   Table 1 Configurations for add-on scheduling

   Parameter	Description
   Multi-AZ Deployment	Preferred: Deployment pods of the add-on will be preferentially scheduled to nodes in different AZs. If all the nodes in the cluster are deployed in the same AZ, the pods will be scheduled to different nodes in that AZ. Equivalent mode: Deployment pods of the add-on are evenly scheduled to the nodes in the cluster in each AZ. If a new AZ is added, you are advised to increase add-on pods for cross-AZ HA deployment. With the Equivalent multi-AZ deployment, the difference between the number of add-on pods in different AZs will be less than or equal to 1. If resources in one of the AZs are insufficient, pods cannot be scheduled to that AZ. Forcible: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. There can be at most one pod in each AZ. If nodes in a cluster are not in different AZs, some add-on pods cannot run properly. If a node is faulty, the add-on pods on it may fail to be migrated.
   Node Affinity	Not configured: Node affinity is disabled for the add-on pods. Specify node: Specify the nodes where the add-on pods are deployed. If you do not specify the nodes, the add-on pods will be randomly scheduled based on the default cluster scheduling policy. Specify node pool: Specify the node pool where the add-on pods are deployed. If you do not specify the node pools, the add-on pods will be randomly scheduled based on the default cluster scheduling policy. Customize affinity: Enter the labels of the nodes where the add-on pods are to be deployed for more flexible scheduling policies. If you do not specify node labels, the add-on pods will be randomly scheduled based on the default cluster scheduling policy. If multiple custom affinity policies are configured, ensure that there are nodes that meet all the affinity policies in the cluster. Otherwise, the add-on pods cannot run.
   Toleration	Using both taints and tolerations enables (but does not require) the add-on's Deployment pods to be scheduled on nodes with matching taints, and allows control over pod eviction policies when host nodes are tainted. The add-on applies default toleration policies for the node.kubernetes.io/not-ready and node.kubernetes.io/unreachable taints on pods. The tolerance time window is 60s. For details, see Configuring Tolerance Policies.

6. Click Install.

Components

The Kubernetes community removed dockershim support in version 1.24. In CCE clusters v1.25 and later, dockershim is replaced by cri-dockerd. The OpenKruise community added cri-dockerd support in versions later than 1.7.x. For details, see the related issue. This issue has been resolved in the CCE add-on 1.1.x.

When OpenKruise v1.0.40 or earlier is installed in a cluster v1.25 or later, KruiseDaemon cannot run on Docker nodes. Use containerd instead. For OpenKruise v1.1.10 or later, KruiseDaemon can run on Docker nodes or containerd nodes.

How to Use the Add-on

After the add-on is installed, you can use a workload controller provided by OpenKruise in the cluster. The following describes how to use a CloneSet to deploy a stateless application. For more examples, see the OpenKruise official website.

1. Write a cloneset.yaml file.
   File content:

   apiVersion: apps.kruise.io/v1alpha1
   kind: CloneSet
   metadata:
     labels:
       app: sample
     name: sample
   spec:
     replicas: 5
     selector:
       matchLabels:
         app: sample
     template:  # The structure of the CloneSet template is the same as that of the Deployment.
       metadata:
         labels:
           app: sample
       spec:
         containers:
         - name: nginx
           image: nginx:alpine
         imagePullSecrets: 
         - name: default-secret

2. Create the CloneSet.

   kubectl create -f cloneset.yaml

   Information similar to the following is displayed:

   cloneset.apps.kruise.io/sample created

3. View the CloneSet.

   kubectl get clone

   Information similar to the following is displayed:

   NAME       DESIRED   UPDATED   UPDATED_READY   READY   TOTAL   AGE
   sample     5         5         5               5       5       23s

   • DESIRED: the number of expected pods
   • UPDATED: the number of pods of the latest version
   • UPDATED_READY: the number of available pods of the latest version
   • READY: the total number of available pods
   • TOTAL: the total number of pods.

Troubleshooting

When a workload is being created, the following error occurs:

Error creating: Internal error occurred: failed calling webhook "mpod.kb.io": failed to call webhook: Post "https://kruise-webhook-service.kube-system.svc:443/mutate-pod?timeout=10s": dial tcp 10.247.10.181:443: connect: connection refused

The issue is caused by the unavailability of the kruise-controller-manager component. This results in the interception of pod creation, update, and deletion operations in certain namespaces (excluding the kube-system namespace or namespaces without the control-plane: openkruise label).

Solution

Restore kruise-controller-manager. The causes and solutions are as follows:

• The resources required by kruise-controller-manager are not enough for kruise-controller-manager to be properly scheduled. You are advised to configure more resources for the add-on.
• A scheduling or affinity policy configured for kruise-controller-manager may prevent the pod from being scheduled. You are advised to check the scheduling policy and configure a proper one to allow kruise-controller-manager to be scheduled smoothly.

Release History