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

I. label

The main role of tags: to solve the problem of more and more resource objects of the same type, for better management, grouping according to tags

Commonly used label categories:

Release (version): stable (stable version), canary (Canary version, can be understood as beta version), beta (beta version) environment (environment variable): dev (development), qa (test), production (production) application (application): ui, as (application software), pc, sctier (architecture level): frontend (front end), backend (back end), cache (cache, hidden) partition (partition): customerA (customer A), CustomerB (customer B) track (quality control level): daily (daily), weekly (weekly)

Although there are no strict requirements in the K8s cluster, the tag still has to do: see the name and know the meaning! Convenient for yourself as well as for others!

Common commands are:

[root@master yaml] # kubectl get pod-- show-labels / / display pod tag [root@master yaml] # kubectl get pod-L env / / value corresponding to the display key [root@master yaml] # kubectl get pod-l env / / View resources containing only env tags [root@master yaml] # kubectl get pod-l env-- show-labels / / display the corresponding key value [root@] Master yaml] # kubectl label pod labels app=pc / / tag pod [root@master yaml] # kubectl label pod labels app- / / remove the tag [root@master yaml] # kubectl label pod labels env=dev-- overwrite / / modify the tag content

Relationship between tag and tag selector:

If there are multiple tags, the tag selector selects one of them, and the association can also be successful! If there are multiple selectors, the tag must meet the conditions of the tag selector for the association to be successful!

Tag selector: query filter criteria for tags

Based on equivalence (equality-based): "=", "=", "! =" the first two are equal, and the last one is not equal.

Based on set relation (set-based): in, notin, exists

Selector: matchLables: / / specifies the tag selector for the equivalence relationship app: nginx matchExpressions: / / collection-based tag selector. There is a "logical and" relationship between selector lists; using an In or NotIn operation, its values does not force an empty string list, but when using Exists or DostNotExists, its values must be empty;-{key: name,operator: In,values: [zhangsan,lisi]}-{key: age,operator: Exists,values:}

The logic of using the tag selector:

The logical relationship between multiple selectors specified at the same time is an "and" operation; a tag selector with a null value means that each resource object will be selected; an empty tag selector cannot select any resource; second, a common Pod controller

Basic concepts of Pod controller:

Pod is the smallest unit of kubernetes, and the pod deletion created autonomously is gone, but the pod created through the resource controller will be rebuilt if deleted. The pod controller is used to implement the middle tier to manage the pod instead of us, and to help us ensure that every pod resource is in the target state we defined or expected. if the pod resource fails, the container must be restarted first, and if there is a problem with the restart all the time, it will be rearranged based on a certain policy. Automatically adapt to the expected number of pod.

There are many controller (controllers) built into Kubernetes, which are equivalent to "state machines" to control the specific state and performance of the Pod.

There are many types of Pod controllers, but the commonly used controllers in kubernetes are:

Replication Controller (RC): a core concept in Kubernetes systems that defines the number of Pod replicas. In Master, the RC process completes the creation, monitoring, start and stop of Pod through the definition of RC. According to the definition of RC, Kubernetes ensures that the specified number of Pod "Replica" can be run at any time. With the iterative update of kubernetes, RC is about to be discarded and gradually replaced by ReplicaSet; ReplicaSet (RS): its core function is to create a specified number of Pod copies on behalf of users, and to make sure that Pod replicas are always in a state that meets the desired number of users, and supports the scaling-down mechanism. There are three main components: the number of Pod copies expected by the user; the tag selector, which creates a new Pod; according to the resource template when the current number of Pod selected for its own management and control does not meet the desired number of users; Deployment: works on ReplicaSet and is used to manage stateless applications. In addition to the ReplicaSet mechanism, it also adds rolling update and rollback functions to provide declarative configuration. DaemonSet: used to ensure that each node in the cluster runs only a specific copy of pod, which is typically used to implement system-level background tasks. Such as ELK services. Requirements: the service is stateless; it must be a daemon

The Pod controller usually consists of three components:

Replicas: expected number of copies of pod objects; selector: current controller matches Pod's tag selector for this copy; template for template:pod copies; 1) Replication Controller (RC)

Basic concept

Replication Controller is referred to as RC, which ensures that there are a specified number of pod replicas (replicas) running in the Kubernetes cluster at any time. If there are less than the specified number of pod replicas (replicas), Replication Controller will start a new Container, otherwise it will kill the excess to keep the number unchanged. Replication Controller uses a predefined pod template to create a pods. Once created, the pod template does not have any association with the created pods. You can modify the pod template without any impact on the created pods, or you can directly update the pods created through the Replication Controller. For the pods,Replication Controller created using the pod template to associate according to the label selector, the corresponding pods can be deleted by modifying the label of the pods.

Initially, Replication Controller was the only kubernetes component used to replicate and reschedule nodes in the event of an exception, but it was gradually replaced by replicaSet. Replication Controller is rarely seen these days, and it is about to be abandoned. However, it is still possible for some kubernates container environments to have RC, so it is still necessary to know its usage.

According to the definition of Replication Controller, Kubernetes ensures that a specified number of Pod "Replica" can be run at any time. If there are too many Pod copies running, the system will stop some Pod;. If the number of Pod copies running is too small, the system will start some more Pod. In short, by the definition of RC, Kubernetes always ensures that the number of replicas users expect is running in the cluster.

Characteristics of Replication Controller (RC):

Ensure the number of Pod; ensure that Pod is healthy; stretch; scroll update

Application example

[root@master yaml] # vim rc.yaml kind: ReplicationController apiVersion: v1metadata: name: http-rcspec: replicas: 2 selector: name: http-rc template: metadata: labels: name: http-rcspec: containers:-name: http-rc image: httpd [root@master yaml] # kubectl apply-f rc.yaml [root@master yaml] # kubectl get rc http-rc NAME DESIRED CURRENT READY AGEhttp-rc 2 2 2 103s [root@master yaml] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShttp-rc-l2sp6 1 Running 0 98s 10.244.1.5 node01 http-rc-xghkm 1 Running 0 98s 10.244.2.5 Node02 [root@master yaml] # kubectl delete-f rc.yaml 2) ReplicaSet (RS)

Basic concept

ReplicaSet is a replacement for Replication Controller, ensuring that the number of Pod replicas accurately meets expectations at any time. It is used to ensure that the number of copies of container applications is always kept at the user-defined number of copies, that is, if a container exits abnormally, a new Pod will be created automatically to replace it, and if more containers are abnormal, they will also be recycled automatically. Although ReplicaSet can be used independently, it is generally recommended to use Deployment to manage ReplicaSet automatically, so that you do not have to worry about incompatibility with other mechanisms (for example, ReplicaSet does not support rolling-update but Deployment). That is, Replicaset is not usually created directly, but automatically when the highest-level deployment resource is created.

Compared with RC, RS supports not only equivalent tags, but also set-based tag selectors.

Main functions of ReplicaSet (RS):

Ensure the number of Pod; ensure that Pod is healthy; stretch; scroll update

Application example

[root@master yaml] # cat rs.yaml kind: ReplicaSetapiVersion: apps/v1metadata: name: http-rsspec: replicas: 2 selector: matchLabels: name: http-rs template: metadata: labels: name: http-rsspec: containers:-name: http-rs image: httpd [root@master yaml] # kubectl apply-f rs.yaml [root@master yaml] # kubectl get rs http-rs NAME DESIRED CURRENT READY AGEhttp-rs 2 2 2 11s [root@master yaml] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShttp-rs-2sstf 1 Running 0 19s 10.244.1.6 node01 http-rs-jm8ph 1 Running 0 19s 10.244 .2.6 node02 [root@master yaml] # kubectl delete-f rs.yaml

As you can see from the yaml file above, the template parts of ReplicaSet and Replication Controller are the same, but not the same at selector. Replication Controller uses selector, ReplicaSet uses selector.matchLables selector, which is simpler and more expressive!

Spec.selector supported by RS supports both matchLabels and matchExpressions matching mechanisms!

The difference between ReplicaSet and Replication Controller

The ReplicaSet tag selector is more powerful; Replication Controller can only specify the tag signature: tag value; Replicaset can specify env=pro,env=devel or as long as it contains an env tag, which is understood as env=*

In short, at present, RS can replace all the functions of RC, and RC is on the verge of being eliminated!

3) Deployment

Basic concept

Deployment is built on ReplicaSet and supports event and status viewing, rollback, version recording, pausing and starting upgrades. Deployment has a variety of automatic update solutions: Recreate, delete and then create; RollingUpdate, rolling upgrade, step by step replacement. Deployment provides declarative updates for Pod and Replica Set (next-generation Replication Controller), which makes it easier to manage Pod and Replica Set. Just describe what the desired target state is in Deployment, and Deployment controller will help you change the actual state of Pod and ReplicaSet to your target state. Alternatively, you can define a completely new Deployment to create a ReplicaSet or delete an existing Deployment and create a new one to replace it.

Typical applications of Deployment controllers are as follows:

Use Deployment to create a ReplicaSet (that is, RS). RS creates a pod in the background. Check the startup status to see if it succeeded or failed; then declare the new state of the Pod by updating the PodTemplateSpec field of the Deployment; this creates a new RS,Deployment that moves the pod from the old RS to the new RS at a controlled rate; if the current state is unstable, roll back to the previous Deployment revision. Each rollback will update Deployment's revision; expansion Deployment to meet the higher load; pause Deployment to apply multiple repairs of PodTemplateSpec, and then resume online; determine whether hang is online according to the status of Deployment; clear the old unnecessary ReplicaSet

Deployment, like RC and RS, is a core content of Kubernetes, and its main responsibility is to ensure the quantity and health of pod. 90% of its functions are exactly the same as Replication Controller and can be regarded as a new generation of Replication Controller.

However, it also has new features beyond Replication Controller:

Full functionality of RC; event and status viewing; rollback; version logging; pause and startup; multiple upgrade scenarios

In general, individuals recommend using Deployment!

Application example

[root@master yaml] # cat deployment.yaml kind: DeploymentapiVersion: extensions/v1beta1metadata: name: http-deploymentspec: replicas: 2 selector: matchLabels: name: http-deployment template: metadata: labels: name: http-deploymentspec: containers:-name: http-deployment image: httpd [root@master yaml] # kubectl apply-f deployment.yaml [root@master yaml] # kubectl get deployments Http-deployment NAME READY UP-TO-DATE AVAILABLE AGEhttp-deployment 2 kubectl get pod 2 2 29 s [root@master yaml] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShttp-deployment-548ddf7b65-77vfk 1 Running 0 18s 10.244.1.7 Node01 http-deployment-548ddf7b65-hdczk 1 Running 0 18s 10.244.2.7 node02 [root@master yaml] # kubectl delete-f deployment.yaml 4) DaemonSet (DS)

Basic concept

DaemonSet ensures that a copy of Pod runs on all (or some) Node nodes, using the node selector and node tags to specify that Pod runs only on some Node nodes. When Node joins the cluster, a new Pod; is added for them. When Node is removed from the cluster, the Pod is also recycled. Deleting a DaemonSet will delete all Pod that it creates. DaemonSet is often used to store, log, and monitor class daemons.

The simple use of DeamonSet is that there is a DaemonSet on all Node that will be used as each type of daemon. A slightly more complex use might be to use multiple DaemonSet for each type of daemon individually, but with different flags, and / or different memory and CPU requirements for different hardware types.

Application example

[root@master yaml] # cat ds.yaml kind: DaemonSetapiVersion: extensions/v1beta1metadata: name: http-dsspec: selector: matchLabels: name: http-ds template: metadata: labels: name: http-dsspec: containers:-name: http-ds image: httpd [root@master yaml] # kubectl apply-f ds.yaml daemonset.extensions/http-ds created [root@master yaml] # kubectl get ds http-ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGEhttp-ds 2 2 2 217s [root@master yaml] # kubectl get podNAME READY STATUS RESTARTS AGEhttp-ds-gkscx 1 39shttp-ds-nbq69 1 Running 0 39shttp-ds-nbq69 1 Running 0 39s [root@master yaml] # kubectl delete-f ds.yaml

Note: the number of replicas (copies) not writable in DaemonSet. It is automatically generated based on the node in the current K8s cluster!

-this is the end of this article. Thank you for reading-

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.