Introduction and use of five controllers in K8S

Controller type of k8s
Relationship between pods and controllers
Deployment (stateless application)
Characteristics of state and statelessness
Deployment Updates
Rollback of a Deployment
CronJob Controller
Summarize

Controller type of k8s

Kubernetes has many built-in controllers, which are equivalent to a state machine and are used to control the specific state and behavior of the Pod.

Deployment: Suitable for stateless service deployment
StatefullSet: Suitable for stateful service deployment
DaemonSet: deploy once, all nodes will be deployed, for example, some typical application scenarios:
Run cluster storage daemons, such as glusterd and ceph on each Node.
Run a log collection daemon on each Node, such as fluentd, logstash
Run a monitoring daemon on each Node, such as Prometheus Node Exporter
Job: a one-time execution task
Cronjob: Periodic execution of tasks

In general, K8S has five controllers, corresponding to processing stateless applications, stateful applications, guarded applications, and batch applications.

Relationship between pods and controllers

Controllers: Objects that manage and run containers on a cluster are associated through label-selectors

Pod uses controllers to implement application operations and maintenance, such as scaling and upgrading.

Deployment (stateless application)

Application scenario: web service

Deployment means deployment and scheduling in Chinese. Through Deployment, we can operate RS (ReplicaSet). You can simply understand it as a declaration through a yml file. In the Deployment file, you can define the number of Pods, update method, image used, resource limit, etc. Stateless applications are created using Deployment

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

Create ReplicaSet and Pod
Rolling upgrade (upgrade without stopping the old service) and rollback (rolling back the application to the previous version)
Smooth expansion and reduction
Pausing and resuming a Deployment

Deployment creation [root@master shuai]# vim nginx-delpoy.yaml

apiVersion: apps/v1
kind: Deployment 'Definition is Deployment'
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 'The number of replicas is 3'
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80


'Create resources'
[root@master shuai]# kubectl apply -f nginx-delpoy.yaml 
deployment.apps/nginx-deployment created

//Replicaset controls the version and number of replicas. Rollback is achieved through this. '//View all resources'
[root@master shuai]# kubectl get all
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-d55b94fd-cndf2 1/1 Running 0 3m31s
pod/nginx-deployment-d55b94fd-ghlwk 1/1 Running 0 3m31s
pod/nginx-deployment-d55b94fd-tm4sw 1/1 Running 0 3m31s
pod/pod-example 1/1 Running 0 10h

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3d6h

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3 3 3 3 3m31s

NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deployment-d55b94fd 3 3 3 3m31s

View controller information kubectl deit deployment/nginx-deployment
.....Information omitted.....
strategy:
    rollingUpdate: 'Version update is a rolling update mechanism'
      maxSurge: 25% 'The maximum number of updated copies is 25%, and the maximum expansion is 125%' 'In order to maintain the number of copies, how many percentages of increase must be destroyed at the same time'
      maxUnavailable: 25% 'The maximum number of deleted copies is 25%, and the maximum reduction is 75%'
    type: RollingUpdate
...Information omitted....


'You can also view it by executing kubectl describe deploy nginx-deployment'

....Information omitted....
RollingUpdateStrategy: 25% max unavailable, 25% max surge

View historical versions [root@master shuai]# kubectl rollout history deploy/nginx-deployment
deployment.extensions/nginx-deployment 
REVISION CHANGE-CAUSE
1 <none> '//There is only one here, which proves that there is no rolling update yet'

Characteristics of state and statelessness

Characteristics of stateless services:

1) Deployment assumes that all pods are the same
2) No need to consider the order requirements
3) No need to consider which node to run on
4) Capacity can be expanded or reduced at will

Characteristics of stateful services:

1) There are differences between instances. Each instance has its own uniqueness and metadata, such as etcd and zookeeper.
2) Asymmetric relationships between instances and applications that rely on external storage.

Deployment Updates

If you want the 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.1
deployment.apps/nginx-deployment image updated

Or we can use the edit command to edit the Deployment and rewrite the image from nginx to nginx:1.9.1
kubectl edit deployment/nginx-deployment

View update progress[root@master ~]# kubectl rollout status deployment/nginx-deployment
Waiting 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 a Deployment is updated, a new ReplicaSet is created, and then the Pods in the new ReplicaSet are 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 will not be stopped, which is a rolling update.

Rollback of a Deployment

After we updated the Deployment as above, we found that the nginx:1.9.1 image was not very stable, so we wanted to change it back to nginx:1.7.9. At this time, we do not need to manually change the Deployment file, but use the rollback function of the Deployment.

Use the rollout history command to view the revision of the Deployment:

[root@master ~]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION CHANGE-CAUSE
1 kubectl create --filename=deploy.yml --record=true
2 kubectl create --filename=deploy.yml --record=true

Because we used the --recorded parameter to record commands when we created the Deployment, we can easily view the changes in each revision.

To view detailed information about a single revision:

[root@master ~]# kubectl rollout history deployment/nginx-deployment --revision=2
deployment.apps/nginx-deployment with revision #2
Pod 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: <none>
    Mounts: <none>
  Volumes: <none>

You can use the rollout undo command to roll back to the previous revision
[root@master ~]# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back

[root@master ~]# kubectl describe deployment/nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Fri, 24 Dec 2021 22:24:10 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 3
                        kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
  Labels: app=nginx
  Containers:
   nginx:
    Image: nginx
    Port: 80/TCP
    Host Port: 0/TCP
    Environment: <none>
    Mounts: <none>
  Volumes: <none>

You can also use the –to-revision parameter to specify a historical version:

[root@master ~]# kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment.apps/nginx-deployment rolled back

[root@master ~]# kubectl describe deployment/nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Fri, 24 Dec 2021 22:24:10 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 4
                        kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector: app=nginx
Replicas: 3 desired | 3 updated | 4 total | 3 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
  Labels: app=nginx
  Containers:
   nginx:
    Image: nginx:1.9.1
    Port: 80/TCP
    Host Port: 0/TCP
    Environment: <none>
    Mounts: <none>
  Volumes: <none>

You can set the .spec.revisonHistoryLimit option to specify how many revision histories a deployment should retain. By default, all revisions are retained; if this option is set to 0, the Deployment is not allowed to roll back.

A revision is created only when a Deployment rollout is triggered! Notice! A rollout is triggered when and only when the Pod template of a Deployment is changed, such as updating the label and container image in the template, thus creating a new revision for the Deployment.

More usage of the rollout command:

history (view historical versions)
pause
resume (resume a suspended Deployment)
status (check resource status)
undo (rollback version)

The Job Controller is responsible for creating Pods according to the Job Spec and continuously monitoring the status of the Pods until they are successfully completed. If it fails, the restartPolicy (only OnFailure and Never are supported, but Always is not supported) is used to decide whether to create a new Pod and retry the task.

A Job is responsible for batch processing of short lived one-off tasks, that is, tasks that are executed only once. It ensures that one or more Pods of the batch task are successfully completed.

Kubernetes supports the following types of jobs:

Non-parallel Job: Usually creates a Pod until it completes successfully
Job with a fixed number of completions: Set .spec.completions and create multiple Pods until .spec.completions Pods are successfully completed
Parallel Job with Work Queue: Set .spec.Parallelism but not .spec.completions. The Job is considered successful when all Pods complete and at least one succeeds.
According to the settings of .spec.completions and .spec.Parallelism, jobs can be divided into the following patterns:

Job Type	Use Case	Behavior	completions	parallelism
One-time Job	Database Migration	Create a Pod until it completes successfully	1	1
Job with fixed end times	Pods that handle work queues	Create a Pod in sequence and run until completions are successfully completed	2+	1
Parallel jobs with a fixed number of completions	Multiple Pods processing work queues simultaneously	Create multiple Pods in sequence and run until completions are completed successfully	2+	2+
Parallel Jobs	Multiple Pods processing work queues simultaneously	Create one or more Pods until one completes successfully	1	2+

.job usage [root@master ~]# vi job.yml 
---
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  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 pods
NAME READY STATUS RESTARTS AGE
myjob-gq27p 0/1 Completed 0 37s

#View the tasks of this pod [root@master ~]# kubectl get job
NAME COMPLETIONS DURATION AGE
myjob 1/1 19s 5m11s

#View the log of this pod [root@master ~]# kubectl logs myjob-gq27p
hello k8s job

CronJob Controller

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

CronJob is very useful for performing periodic repetitive tasks, such as backing up data, sending emails, etc. CronJob can also be used to specify a time point in the future to execute a single task, such as scheduling a task to execute when the system load is relatively low.

A CronJob object is like a row in a crontab (cron table) file. It is written in Cron format and executes the job periodically at a given schedule time.

Notice:

All CronJob schedule: times are based on the time zone of kube-controller-manager.
If your control plane runs kube-controller-manager in a Pod or bare container, the time zone set for that container will determine the time zone used by the Cron Job's controller.
When creating a manifest for a CronJob resource, make sure the name provided is a valid DNS subdomain name. The name cannot exceed 52 characters. This is because the CronJob controller will automatically append 11 characters to the provided job name, and there is a limitation that the maximum length of a job name cannot exceed 63 characters.
CronJob is used to perform periodic actions, such as backup, report generation, etc. Each of these tasks should be configured to repeat periodically (eg: daily/weekly/monthly); you can define the time interval at which the task should start executing.

The following CronJob example listing will print out the current time and a greeting message every minute:

[root@master kubenetres]# vi cronjob.yml
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  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 CronJob
cronjob.batch/hello created

#Wait a minute to check [root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-27339330-kkfxv 0/1 Completed 0 2s

#View logs [root@master ~]# kubectl logs hello-27339330-kkfxv
Fri Dec 24 15:30:00 UTC 2021
Hello Nihao

Summarize

This is the end of this article about the five controllers and their uses in K8S. For more information on the use of K8S controllers, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!

You may also be interested in: