A brief analysis of kubernetes controllers and labels

01 Common controllers in k8s

Previously, we learned that Pod is the smallest scheduling unit in the k8s cluster. Pod is composed of Pause container + application container.

In k8s, it is often the case that one resource object manages another resource object. We call this type of resource object a "controller".

Let's take a quick look at the types of controllers and their functions. In fact, each controller has its own characteristics. We will analyze them one by one later. Now you just need to have a general idea.

RC Controller

It defines an expected scenario, which states that the number of replicas of a certain Pod meets a certain expected value at any time. For example, in the one-master-two-slave structure of MySQL, we expect that there are always two slave databases at any time. If that is not enough, we need to expand a slave database.

Its definition requires the following three key parameters:

1. Expected number of Pods

2. Pod label, which is a type identifier

3. Create a Pod template for a new Pod

Its general structure is as follows:

apiVersion: vl
kind: ReplicationController
metadata:
    name: rc-mysql-slave
spec:
    replicas: 2 # expected value selector: # tag app: mysql
    template: # Template xxx: xxx

By comparing the above text, you can see the basic YAML file template of RC.

Once the RC is defined and submitted to the k8s master, the controller manager will inspect the currently surviving target Pods and ensure that the currently surviving Pods are equal to the expected Pods. If there are more, they will be deleted; if there are fewer, they will be created.

Deployment Controller

It is a new concept introduced in k8s version 1.2. This controller is 90% similar to the RC controller. The difference between it and RC is that it can obtain the "deployment progress" of the current Pod at any time. Its yaml file definition is as follows:

apiVersion: extensions/vlbetal
kind : Deployment
metadata:
    name: dep-mysql-slave
spec:
    replicas: 2
    selector:
       xxxx:xxxx
    template：
       xxxx:xxxx

With Deployment, almost all scenarios where RC is used can be replaced by Deployment.

Statefulset Controller

This controller also generates the expected value of certain Pods, but it is different from RC and Deployment in that the Pods it generates are stateful.

In the Pods generated by RC and Deployment, we only need to generate the expected number of Pods, similar to the two slave libraries of MySQL in the 1 master 2 slave architecture. They have no concept of order or weight. The Pods controlled by the Statefulset controller have a certain logical relationship in generation order or weight. For example, in the MySQL master-slave architecture, it is necessary to generate the master node first and then the slave node. In this case, it is more appropriate to use statefulset.

There are some other commonly used controller types, which we will share in detail next time. Here we just need to know the concept of "controller".

02 The concept of Label

In the previous article, we talked about several key fields in the yaml file of the Pod in k8s. Today we will look at another attribute of the Pod, which is Label.

Label means label, and its format is also key-value format. It can be attached to an object in the k8s cluster, including but not limited to Pod, Node, RC, etc. The binding relationship between resource objects and Labels can be one-to-one or many-to-one. Different labels can be used to manage resources in groups.

After we label a resource, we can use the label selector to select the resource for scheduling, as follows:

apiVersion : vl
kind: Pod
metadata:
    name: myweb
    labels:
       app : mysql

The above example defines a Pod for us, and its label is app=mysql.

Then we define a "controller" and use the label selector in the controller to select the Pod with app=mysql and keep two copies of this Pod in the cluster as follows:

apiVersion : vl
kind : ReplicationController
metadata:
    name: myweb
spec:
    replicas : 2
    selector:
        app : mysql
    template:
        xxxx

The new version of Selector can also specify more detailed filtering conditions, which mainly rely on the following parameters:

apiVersion : vl
kind : ReplicationController
metadata:
    name: myweb
spec:
    replicas : 1
    selector:
       matchLabels :
         app: myweb
       matchExpressions:
        - {key: aaa , parameter: In , values: [mysql-slave]}
        - {key: bbb , operator: Notin , values: [mysql-master)}
    template:
        xxxx

One parameter is matchLabels, which can be followed by multiple label conditions in key-value format;

Another parameter is matchExpression, which can specify an array and combine it with conditional operations. In the above example, it means that the pods with the aaa parameter are in mysql-slave, but the bbb parameter is not in mysql-master.

If these two parameters appear at the same time, they will be automatically ANDed, and their intersection will be used as the final filter condition to filter the Pod

It can be seen that the use of tags makes the "controller" more flexible and convenient in selecting the controlled object.

The above is a brief analysis of the details of Kubernetes controllers and labels. For more information about Kubernetes controllers and labels, please pay attention to other related articles on 123WORDPRESS.COM!