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

This article mainly introduces "what is the use of the five controllers in K8S". In the daily operation, I believe that many people have doubts about the use of the five controllers in K8S. I have consulted all kinds of materials and sorted out the simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what are the five controllers in K8S?" Next, please follow the editor to study!

Controller type of K8s

There are many controller (controllers) built into Kubernetes, which are equivalent to a state machine to control the specific state and behavior of Pod.

Deployment: suitable for stateless service deployment

StatefullSet: suitable for stateful service deployment

DaemonSet: all node nodes are deployed at one time, such as some typical application scenarios:

Run clustered storage daemon, such as glusterd, ceph on each Node

Run log collection daemon on each Node, such as fluentd, logstash

Run a monitoring daemon, such as Prometheus Node Exporter, on each Node

Job: one-time execution of tasks

Cronjob: perform tasks periodically

In general, K8S has five controllers that correspond to stateless applications, stateful applications, guarded applications and batch applications.

The relationship between pod and Controller

Controllers: objects that manage and run containers on the cluster are associated through label-selector

Pod implements the operation and maintenance of applications through the controller, such as scaling, upgrading, etc.

Deployment (stateless application)

Application scenario: web service

Deployment Chinese means deployment, scheduling, through Deployment we can operate RS (ReplicaSet), you can simply understand that it is a declaration through the yml file, in the Deployment file you can define the number of Pod, update method, use of images, resource restrictions, and so on. Stateless applications are created using Deployment

With the Deployment object, you can easily do the following:

Create ReplicaSet and Pod

Rolling upgrade (upgrading without stopping the old service) and rolling back the application (rolling back the application to the previous version)

Smooth expansion and reduction

Pause and resume Deployment

Deployment creates [root@master shuai] # vim nginx-delpoy.yamlapiVersion: apps/v1kind: Deployment' definition is Deployment'metadata: name: nginx-deployment labels: app: nginxspec: replicas: 3' number of copies is 3 'selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.15.4 ports :-containerPort: 80' create Resource'[root@master shuai] # kubectl apply-f nginx-delpoy.yaml deployment.apps/nginx-deployment created//Replicaset is the controlled version Number of copies Rollback is the way to achieve'/ / View all resources'[root@master shuai] # kubectl get allNAME READY STATUS RESTARTS AGEpod/nginx-deployment-d55b94fd-cndf2 1 3m31spod/nginx-deployment-d55b94fd-ghlwk 1 Running 0 3m31spod/nginx-deployment-d55b94fd-ghlwk 1 3m31spod/ 1 Running 0 3m31spod/nginx-deployment-d55b94fd-tm4sw 1 3m31spod/ Pod-example 1 Running 0 10hNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEservice/kubernetes ClusterIP 10.0.0.1 443/TCP 3d6hNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEdeployment.apps/nginx-deployment 3 3 3 3 3m31sNAME DESIRED CURRENT READY AGEreplicaset.apps/nginx-deployment-d55b94fd 3 3 3 3m31s view controller information kubectl deit deployment/nginx-deployment. Omit the information. Strategy: rollingUpdate: 'version update to rolling update mechanism' maxSurge: 25% 'maximum update copy number is 25%, maximum capacity expansion is 125%' in order to maintain the number of copies, the percentage of increase in the number of copies to be destroyed at the same time 'maxUnavailable: 25%' the maximum deleted copy is 25%, and the maximum reduction is 75%. Type: RollingUpdate... Omit information.' If you execute kubectl describe deploy nginx-deployment, you can also view '.... Omit the information. RollingUpdateStrategy: 25% max unavailable, 25% max surge View History version [root@master shuai] # kubectl rollout history deploy/nginx-deploymentdeployment.extensions/nginx-deployment REVISION CHANGE-CAUSE1'/ / there is only one here, which proves that there is no rolling update 'status and stateless pair feature.

Characteristics of stateless service:

1) deployment thinks that all pod are the same.

2) do not consider the requirement of sequence

3) Don't worry about which node node to run on

4) you can expand and reduce capacity at will.

Features of stateful service:

1) there are differences between instances. Each instance has its own uniqueness and metadata, such as etcd,zookeeper.

2) unequal relationships between instances and applications that rely on external storage.

Update of Deployment if you want nginx pod to use the nginx:1.9.1 image instead of the original nginx image, run the following command [root@master ~] # kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1deployment.apps/nginx-deployment image updated or we can use the edit command to edit the Deployment Rewrite image from nginx to nginx:1.9.1kubectl edit deployment/nginx-deployment to view update progress [root@master ~] # kubectl rollout status deployment/nginx-deploymentWaiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...deployment "nginx-deployment" successfully rolled out

When Deployment is updated, a new ReplicaSet is created, then the Pod in the new ReplicaSet is slowly expanded to the specified number of replicas, and the old ReplicaSet is slowly reduced to 0. Therefore, when updating, it is always possible to ensure that the old service does not stop, which is called rolling update.

Rollback of Deployment

When we updated Deployment as above, we found that the image of nginx:1.9.1 is not very stable, so we want to modify the version of nginx:1.7.9, at this time we do not need to change the Deployment file manually, but take advantage of Deployment's rollback feature.

Use the rollout history command to view the version of Deployment (revision):

[root@master] # kubectl rollout history deployment/nginx-deploymentdeployment.apps/nginx-deployment REVISION CHANGE-CAUSE1 kubectl create-filename=deploy.yml-record=true2 kubectl create-filename=deploy.yml-record=true

Because we used the-recored parameter to record commands when we created the Deployment, we can easily see the changes in each revison.

View the details of a single revision: [root@master ~] # kubectl rollout history deployment/nginx-deployment-- revision=2deployment.apps/nginx-deployment with revision # 2Pod Template: Labels: app=nginx pod-template-hash=658d7f4b4b Annotations: kubernetes.io/change-cause: kubectl create-- filename=deploy.yml-- record=true Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes: you can use the rollout undo command to roll back to the previous revision [root@master ~] # kubectl rollout undo deployment/nginx-deploymentdeployment.apps/nginx-deployment rolled back [root@master ~] # kubectl describe deployment/nginx-deploymentName: nginx-deploymentNamespace: defaultCreationTimestamp: Fri 24 Dec 2021 22:24:10 + 0800Labels: Annotations: deployment.kubernetes.io/revision: 3 kubernetes.io/change-cause: kubectl create-- filename=deploy.yml-- record=trueSelector: app=nginxReplicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25 max unavailable 25% max surgePod Template: Labels: app=nginx Containers: nginx: Image: nginx Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes: you can also use the-to-revision parameter to specify a historical version: [root@master ~] # kubectl rollout undo deployment/nginx-deployment-- to-revision=2deployment.apps/nginx-deployment rolled back [root@master ~] # kubectl describe Deployment/nginx-deploymentName: nginx-deploymentNamespace: defaultCreationTimestamp: Fri 24 Dec 2021 22:24:10 + 0800Labels: Annotations: deployment.kubernetes.io/revision: 4 kubernetes.io/change-cause: kubectl create-- filename=deploy.yml-- record=trueSelector: app=nginxReplicas: 3 desired | 3 updated | 4 total | 3 available | 1 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25 max unavailable 25% max surgePod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes:

You can specify how much revison history deployment retains by setting the .spec.revisonHistoryLimit entry. All revision; will be retained by default. Fallback is not allowed if this item is set to 0Query deployment.

A revision will be created only if the rollout of Deployment is triggered! Be careful! A rollout is triggered when and only if the Pod template of the Deployment is changed, such as updating the label and container images in the template, creating a new revision for the Deployment.

More uses of the rollout command:

History (View Historical version)

Pause (pause Deployment)

Resume (resume paused Deployment)

Status (View Resource status)

Undo (rollback version)

Job Controller is responsible for creating the Pod based on the Job Spec and continuously monitoring the status of the Pod until it is successfully completed. If it fails, it is decided whether or not to create a new Pod and retry the task based on restartPolicy (only OnFailure and Never are supported, not Always).

Job is responsible for batch processing of short-lived one-time tasks (short lived one-off tasks), that is, tasks that are executed only once, which ensures the successful completion of one or more Pod of the batch task.

Kubernetes supports the following Job:

Non-parallel Job: usually create a Pod until it finishes successfully

Job with a fixed number of terminations: set .spec.completions, and create multiple Pod until .spec.completions Pod finishes successfully

Parallel Job with work queues: set .spec.Parallelism but not .spec.completions. When all Pod ends and at least one is successful, Job is considered successful

According to the settings of .spec.completions and .spec.Parallelism, Job can be divided into the following pattern

The JOB type uses instance behavior completionsparallelism one-time Job database migration to create a Pod until it successfully ends 11 fixed times of Job processing work queue Pod in turn to create a Pod run until completions successfully ends 2 / 1 parallel Job multiple Pod simultaneous processing work queues create multiple Pod runs until completions successfully ends 2 / 2 + parallel Job multiple Pod processes work queue creation Build one or more Pod until there is a successful completion of the use of 12+.job [root@master ~] # vi job.yml-apiVersion: batch/v1kind: Jobmetadata: name: myjobspec: template: spec: containers:-name: myjob image: busybox command: ["echo" "hello K8s job"] restartPolicy: Never [root@master ~] # kubectl apply-f job.yml job.batch/myjob created [root@master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEmyjob-gq27p 0 Completed 0 37s# View this pod's task [root@master ~] # kubectl get jobNAME COMPLETIONS DURATION AGEmyjob 1amp 1 19s 5m11s# View this pod's log [ Root@master ~] # kubectl logs myjob-gq27phello k8s jobCronJob controller

CronJob can be used to perform scheduled tasks based on time planning, similar to crontable (opens new window) in Linux/Unix systems.

CronJob is useful when performing periodic repetitive tasks, such as backing up data, sending mail, and so on. CronJob can also be used to specify the execution of a single task at a certain point in the future, such as scheduling a task to be executed when the system load is low.

A CronJob object is like a line in a crontab (cron table) file. It is written in Cron format and executes Job periodically at a given scheduled time.

Note:

All CronJob schedule: time is based on kube-controller-manager. The time zone.

If your control plane runs kube-controller-manager in a Pod or a bare container, the time zone set for that container will determine the time zone used by the Cron Job controller.

When creating a list for CronJob resources, make sure that the name provided is a legitimate DNS subdomain name. The name cannot exceed 52 characters. This is because the CronJob controller will automatically append 11 characters to the supplied Job name, and there is a restriction that the maximum length of the Job name cannot exceed 63 characters.

CronJob is used to perform periodic actions, such as backup, report generation, and so on. Each of these tasks should be configured to repeat periodically (for example, daily / weekly / monthly); you can define the interval at which the task begins.

The following sample CronJob listing prints the current time and greeting message every minute:

[root@master kubenetres] # vi cronjob.yml---apiVersion: batch/v1beta1kind: CronJobmetadata: name: hellospec: schedule: "* / 1 *" jobTemplate: spec: template: spec: containers:-name: hello image: busybox imagePullPolicy: IfNotPresent command:-/ bin/sh-- c-date Echo Hello nihao restartPolicy: OnFailure create pod View [root@master ~] # kubectl apply-f cronjob.yml Warning: batch/v1beta1 CronJob is deprecated in v1.21, unavailable in v1.25 + Use batch/v1 CronJobcronjob.batch/hello created# and so on one minute to check [root@master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEhello-27339330-kkfxv 0 2s# 1 Completed 0 2s# view log [root@master ~] # kubectl logs hello-27339330-kkfxvFri Dec 24 15:30:00 UTC 2021Hello nihao, about "what are the five controllers in K8S?" the study is over, hoping to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.