Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "how to use the new Patch features of OpenYurt". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Background

Before we begin the text, let's review the concept and design philosophy of cellular deployment. In the edge computing scenario, computing nodes have obvious geographical distribution attributes, and the same application may need to be deployed on computing nodes in different regions. Take Deployment as an example, as shown in the following figure, the traditional approach is to set the computing nodes in the same region to the same tag, and then create multiple Deployment, and different Deployment select different tags through NodeSelectors, so as to achieve the need to deploy the same application to different regions.

However, with more and more geographical distribution, operation and maintenance become more and more complex, which is shown in the following aspects:

When the image version is upgraded, a large number of related Deployment image version configurations need to be modified.

You need to customize the naming convention of Deployment to indicate the same application.

Lack of a higher perspective for unified management and operation and maintenance of these Deployment. The complexity of operation and maintenance increases linearly with the increase of application and regional distribution.

Based on the above requirements and problems, the cellular deployment (UnitedDeployment) provided by the yurt-app-manager component of openyurt manages these sub-Deployment through a higher-level abstraction: automatic creation / update / deletion, thus greatly simplifying the complexity of operation and maintenance.

Yurt-app-manager component: https://github.com/openyurtio/yurt-app-manager

As shown in the following figure:

Cellular deployment (UnitedDeployment) abstracts these Workload at a higher level, and UnitedDeployment contains two main configurations: WorkloadTemplate and Pools. The workloadTemplate format can be either Deployment or Statefulset. Pools is a list, each list has a configuration for Pool, and each Pool has its own name, replicas, and nodeSelector configurations. A set of machines can be selected through nodeSelector, so in the edge scene Pool we can simply think that it represents a group of machines in a certain region. Using the definition of WorkloadTemplate + Pools, we can easily distribute a Deployment or Statefulset application to different regions.

Here is a concrete example of UnitedDeployment:

ApiVersion: apps.openyurt.io/v1alpha1kind: UnitedDeploymentmetadata: name: test namespace: defaultspec: selector: matchLabels: app: test workloadTemplate: deploymentTemplate: metadata: labels: app: test spec: selector: matchLabels: app: test template: metadata: labels: app: test spec: Containers:-image: nginx:1.18.0 imagePullPolicy: Always name: nginx topology: pools:-name: beijing nodeSelectorTerm: matchExpressions:-key: apps.openyurt.io/nodepool operator: In values:-beijing replicas: 1-name: hangzhou nodeSelectorTerm: matchExpressions: -key: apps.openyurt.io/nodepool operator: In values:-hangzhou replicas: 2

The specific logic of the UnitedDeployment controller is as follows:

The user defines a UnitedDeployment CR, and the CR defines a DeploymentTemplate and two Pool.

Where the DeploymentTemplate format is defined as a Deployment format, and the Image used in this example is nginx:1.18.0.

The name of Pool1 is beijing and replicas=1,nodeSelector is apps.openyurt.io/nodepool=beijing. The Deployment,replicas representing that the UnitedDeployment controller is going to create a child is 1, the nodeSelector is apps.openyurt.io/nodepool=beijing, and the other configurations are inherited from the DeploymentTemplate configuration.

The name of Pool2 is hangzhou,replicas=2, and nodeSelector is apps.openyurt.io/nodepool=hangzhou, which means that the Deployment,replicas of the UnitedDeployment controller to create a child is 2, the NodeSelector is apps.openyurt.io/nodepool=hangzhou, and the other configurations are inherited from the DeploymentTemplate configuration.

After the UnitedDeployment controller detects that a UnitedDeployment CR instance whose name is test is created, it will first generate a template object of Deployment according to the configuration in DeploymentTemplate. According to the configuration of Pool1 and Pool2 and the template object of Deployment, two deployment resource objects with name prefixes of test-hangzhou- and test-beijing- are generated respectively. These two Deployment resource objects have their own nodeselector and replica configurations. In this way, by using the form of workloadTemplate+Pools, workload can be distributed to different regions without the need for users to maintain a large number of Deployment resources.

Problems solved by UnitedDeployment

UnitedDeployment can automatically maintain multiple Deployment or Statefulset resources through a monolithic deployment instance, and each Deployment or Statefulset resource follows a unified naming convention. At the same time, it can also realize the differential configuration of Name, NodeSelectors and Replicas. It can greatly simplify the operation and maintenance complexity of users in the edge scene.

New demand

UnitedDeployment can meet most of the needs of users, but in the process of promotion, customer landing and discussion with community students, we gradually find that the features provided by UnitedDeployment are not enough in some special scenarios, such as the following scenarios:

When you apply an image upgrade, users plan to do verification in a node pool first, and then update the release in all node pools if the verification is successful.

To speed up image pull, users may build their own private image repositories in different node pools, so the image name of the same application under each node pool will be different.

The number of servers, specifications, and business access pressure are different under different node pools, so the cpu, memory and other configurations of the pod of the same application under different node pools will be different.

The same application may use different configmap resources under different node pools.

These requirements prompt UnitedDeployment to provide some personalized configuration for each Pool, allowing users to do some personalized configuration according to the actual situation of different node pools, such as mirroring, pod request and limit, and so on. In order to maximize flexibility, after discussion, we decided to add Patch fields in Pool to allow users to customize Patch content, but need to follow Kubernetes's strategic merge patch specification, which is somewhat similar to our commonly used kubectl patch.

Add patch to pool. Examples are as follows:

Pools:-name: beijing nodeSelectorTerm: matchExpressions:-key: apps.openyurt.io/nodepool operator: In values:-beijing replicas: 1 patch: spec: template: spec: containers:-image: nginx:1.19.3 name: nginx

The content defined in patch needs to follow the strategic merge patch specification of Kubernetes. If you have used kubectl patch, you can easily know how to write patch content. For more information, please refer to updating Kubernetest api objects with kubectl patch. Next, let's demonstrate the use of UnitedDeployment patch.

Feature demonstration 1. Environmental preparation

Provide a K8s cluster or OpenYurt cluster with at least 2 nodes in the cluster. One node label is: apps.openyurt.io/nodepool=beiing, and the other node label is: apps.openyurt.io/nodepool=hangzhou.

Yurt-app-manager components need to be installed in the cluster.

Yurt-app-manager component: https://github.com/openyurtio/yurt-app-manager

two。 Create UnitedDeployment instance cat

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.