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

This article mainly introduces "what is the Pod controller". In the daily operation, I believe that many people have doubts about what is the Pod controller. The editor 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 is the Pod controller?" Next, please follow the editor to study!

ReplicaSet controller

Create ReplicaSet

Pod object under the control of ReplicaSet

Update ReplicaSet

Deployment controller

Create Deployment

Update policy

Upgrade Deployment

Canary release

Capacity expansion and reduction

DaemonSet controller

Job controller

Serial and parallel control

Delete Job

CornJob controller

Pod interrupts budget

After the autonomous Pod object is bound to the target work node by the scheduler, the kubelet on the corresponding node is responsible for monitoring the viability of the container. After the main process of the container crashes, kubelet can automatically restart the corresponding container. Based on survivability detection, it can also respond to other problems in the container. However, if the Pod is accidentally deleted, or the worker node fails, kubelet will be powerless. The Pod controller can handle this kind of situation. The Pod controller is provided by the kube-controller-manager component of master. Kube-controller-manager is an independent single daemon, which contains many controllers with different functions, not only Pod Controller, but also NodeLifecycle Controller, Namespace Controller, Service Controller and so on. These controllers continuously monitor the resources they are responsible for, and try to make the current state of the resources migrate and approach to the desired state when the system state changes due to failure, update or other reasons.

ReplicaSet controller

ReplicaSet replaces the earlier ReplicationController to ensure that the number of copies of Pod objects controlled by it can accurately meet the expected number at any one time.

The Pod created through the controller has the same functionality as the Pod created manually by the user, but compared to manual creation, ReplicaSet can achieve the following functions:

Ensure that the number of Pod resource objects accurately reflects expectations

Ensure that the Pod is running healthily, and automatically request the scheduler to create a missing copy of the Pod on other work nodes when it detects that the Pod object it controls is unavailable due to the failure of the worker node where it is located.

Auto scaling: when the resource demand fluctuates greatly, the number of related Pod resource objects can be adjusted dynamically through the ReplicaSet controller. It can also cooperate with HPA (HroizontalPodAutoscaler) to achieve automatic scaling of Pod resources.

Create ReplicaSet

Typically, the spec of a Pod controller's resource list contains the following basic attributes:

Selector: tag selector that matches and associates Pod resource objects and completes the count of Pod resources under its control

Replicas: the expected number of replicas, the number of objects of Pod resources expected to run precisely in the cluster

Template:Pod template, which is used to create a Pod template resource for Pod resource objects

For example:

ApiVersion: apps/v1kind: ReplicaSetmetadata: name: rs-examplespec: replicas: 2 selector: matchLabels: app: rs-demo template: metadata: labels: app: rs-demo spec: containers:-name: myapp image: ikubernetes/myapp:v2 imagePullPolicy: Never ports:-name: http containerPort: 80 protocol: TCP

After apply this configuration list, using kubectl get pods-l app=rs-demo to look at it, you will see that there are two containers, the state is changed from ContainerCreating to Running, and the two pod names are prefixed with the controller name rs-example, rs-example-j98fp, rs-example-wj8zg. Run kubectl get replicaset rs-example with options such as-o json\ wide to view the detailed status of the controller.

Pod object under the control of ReplicaSet

The reason why ReplicaSet can respond in time to the abnormal number of Pod objects is that it registers with API Server to listen for changes in related resources and their lists, so API Server will notify the listeners immediately when the changes occur.

Missing, extra copy of Pod

The loss of related Pod objects caused by any reason will be automatically made up by the ReplicaSet controller. Manually deleting a Pod,ReplicaSet will immediately create a new one; the previously created ReplicaSet relies on the tag app: rs-demo to manage the Pod, so forcing to modify this tag will also trigger the creation of a copy: kubectl label pods rs-example-wj8zg app=others-the Pod rs-example-wj8zg before overwrite still exists, and if it can be selected by other controllers through the tag selector, it will belong to this controller and become a self-service Pod. The redundant parts will be automatically deleted by the controller, and the smallest Age will be deleted first after testing.

The kubectl describe replicasets/rs-example command prints out the detailed status of the ReplicaSet and the Events.

Update ReplicaSet change template: upgrade application

Changing template has no effect on active objects that have been created, but rolling upgrades can be achieved by manually closing their older versions of Pod resources one by one. Compared with the manual operation mode of ReplicaSet, the Deployment controller can automatically achieve more perfect rolling update and rollback, and provide users with an interface to customize the update policy.

Change replicas: expand and reduce capacity

Horizontal scaling of the application scale can be achieved by modifying the replicas attribute and apply. Kubectl also provides a special subcommand scale to achieve the scaling of the application scale. For example, the kubectl scale replicasets rs-example-- replicas=2 use-- current-replicas option can also change the replicas when the number of replicas is specified. For example, the following command will not be executed successfully if the current number of replicas is not equal to 4: kubectl scale replicasets rs-example-- current-replicas=4-- replicas=2.

If ReplicaSet is allowed to manage stateful applications, such as Redis clusters with master-slave architecture, the above upgrade, downgrade and expansion operations need to be carefully choreographed and participated in. For such needs, StatefulSet,ReplicaSet provided by K8S can only be used to manage stateless applications, such as HTTP service programs.

Delete ReplicaSet resources

Delete command: kubectl delete-f... Or kubectl delete replicaset... When you delete a ReplicaSet object, each Pod object that it controls is deleted by default. However, sometimes, considering that these Pod resources may not be created by them, or when Pod resources may be used again later, you can add the-- cascade=false option to cancel cascading deletions.

Deployment controller

The Deployment controller is built on top of the ReplicaSet controller and provides declarative updates for Pod and ReplicaSet resources. Pod and ReplicaSet are lower-level resources that are rarely used directly. Deployment controller adds a variety of enhanced functions on the basis of ReplicaSet:

Event and status view: you can view the detailed progress and status of the Deployment object upgrade if necessary

Rollback: when a problem is found in the upgrade, you can use the rollback mechanism to return the application to the previous or specified historical version

Version record: save the record of each operation for subsequent rollback operations

Pause and start: for each upgrade, you can pause and start at any time

A variety of automatic update schemes:

Recreate, rebuild the update mechanism, stop and delete the old Pod completely and replace it with a new version

RollingUpdate, rolling upgrade mechanism, gradually replace the old Pod to the new version.

Create Deployment

Deployment takes the ReplicaSet object as its secondary resource. Except for kind and name, the other fields in the configuration list are the same as those of ReplicaSet. Example:

Kind: Deploymentmetadata: name: myapp-deploy

After the creation is completed, you can use kubectl get deployments myapp-deploy to view its status:

NAME READY UP-TO-DATE AVAILABLE AGEmyapp-deploy 2/2 2 2 15s

UP-TO-DATE represents the number of copies of Pod that have reached the desired state, and AVAILABLE represents the number of applications currently in the available state. View related ReplicaSet resources:

~ kubectl get replicasets-l app=myapp NAME DESIRED CURRENT READY AGEmyapp-deploy-7cfbdc886d 2 22 2m53s

The naming format of ReplicaSet resources is [DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE] to view related Pod resources:

~ kubectl get pods-l app=myapp NAME READY STATUS RESTARTS AGEmyapp-deploy-7cfbdc886d-8lw6f 1 Running 1 Running 0 4m55smyapp-deploy-7cfbdc886d-xn7xp 1 4m55s

The name of the Pod resource is prefixed with the name of the ReplicaSet resource, plus 5 random characters.

Update policy

The Deployment controller supports both RollingUpdate and Recreate update strategies, and the default is rolling update.

Recreate

It is similar to deleting all Pod objects at once when using ReplicaSet, and then the controller recreates the new version of the resource object based on the new template. This approach should usually be used only if the new and old versions of the application are not compatible (for example, the schema of the dependent back-end database is different and not compatible), because it will cause temporary unavailability during the application replacement, but the advantage is that it does not have an intermediate state.

RollingUpdate

Rolling upgrade is to create some new versions of Pod objects while deleting some of the old version of Pod resources. In this way, the service provided by the application in the container will not be interrupted, but it requires the application to be able to cope with the situation where the new version and the old version work at the same time, such as the new version and the old version are compatible with the same database scheme. During the rolling upgrade, there will be both new and old versions of ReplicaSet. While the number of Pod objects in the old version of ReplicaSet continues to decrease, the number of Pod objects in the new version of ReplicaSet continues to increase until the old version of ReplicaSet no longer owns Pod objects, and the number of copies of the new version of ReplicaSet becomes exactly as expected. During the upgrade, you should also ensure that the number of available Pod objects is not lower than a certain threshold to ensure that the service requests from the client can be processed continuously. The changing mode and the number range of Pod objects will be defined jointly by the attributes maxSurge and maxUnavailable under spec.strategy.rollingUpdate:

MaxSurge: the maximum number of total Pod objects that exist during the upgrade can exceed the expected value, which can be 0 or a positive integer, or a percentage of the expected value

MaxUnavailable: the maximum number of Pod copies (including new and old versions) available during the upgrade cannot be less than the expected value, which can be 0 or a positive integer, or a percentage of the expected value. The default value is 1.

MaxSurge and maxUnavailable are equivalent to defining the fluctuation range of the number of pod, so their values cannot be 0 at the same time. The mode of action of the two is as follows:

In addition, you can set the spec.minReadySeconds property:

To control the speed of the application upgrade, and when rolling the upgrade, the new Pod object is available by default as long as the probe is ready and successful, so the next round of replacement operation begins. MinReadySeconds can define at least how long it will take after a new Pod object is created before it is considered ready, during which time the update operation will be blocked.

Upgrade Deployment

You can update the Deployment controller resources by modifying the configuration parameters related to the Pod template, which can be modified through the apply and patch commands; if you only modify the container image, you can use the set image command directly. To make the upgrade process easier to observe, first use the "kubectl patch" command to specify minReadySeconds=6s:

Kubectl patch deployments myapp-deploy-p'{"spec": {"minReadySeconds": 6}}'

Changing the values of the minReadySeconds, replicas, and strategy fields of the Deployment controller does not trigger an update of the Pod resource because they do not have any impact on the existing Pod object. Use the set image command to update the mirror version:

Kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v2

Then use the following command to observe the rolling upgrade process:

Kubectl rollout status deployments myapp-deploy-watch

After the upgrade is complete, the old version of the ReplicaSet controller will remain in the history, but its previous control Pod objects will be deleted.

Canary release

The Deployment controller supports the pause and continuation of update operations, and combined with maxSurge and maxUnavailable, canary release (Canary Release) can be realized, that is, the update process is suspended immediately after the first batch of new Pod resources are created. At this time, there are only a small number of new versions of applications, and the main body is still the old version. Then direct a small portion of the traffic to the new version of the Pod application, and continuously observe whether it can run steadily in the desired way, and then continue to complete the rolling update of the remaining Pod resources after making sure that there is no problem, otherwise, roll back the update operation immediately. In order to minimize the impact on the existing system, the canary release process is usually recommended to be "add first, then delete, and the total number of available Pod resource objects is not less than expected". The number of Pod objects added for the first time depends on the rules of the first batch of requests accessed and the carrying capacity of a single Pod. In the next experiment, maxSurge and maxUnavailable are set to 1 and 0 respectively, and updates are triggered by modifying the upgraded image version, but to pause after the first batch of updates are started. Because minReadySeconds is set, you can issue a pause command during this process, or for kubectl, you can directly connect the two commands in Shell with the symbol "& &":

Kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v2-record=true&& kubectl rollout pause deployments myapp-deploy

Check the status to know that the update operation has been paused:

Kubectl rollout status deployments myapp-deploy

At this point, by setting Service or Ingress resources and relevant routing policies, you can introduce some users' traffic to these Pod for publication verification, and then continue to update after confirming that there are no problems:

Kubectl rollout resume deployments myapp-deploy rollback

If the scrolling update cannot be carried out properly due to various reasons, such as failure to obtain the image file, "Canary" distress, etc., the application should be rolled back to the previous version or the version in the specified history, and directly to the previous version:

Kubectl rollout undo deployments myapp-deploy

Add the-- to-revision option to roll back to the specified version, and the following command allows you to view the saved historical version:

Kubectl rollout history deployments myapp-deploy

It is important to note that only the historical version that is saved is rolled back, and spec.revisionHistoryLimit defines the number of saved versions, which defaults to 10. In addition, the content of the CHANGE-CAUSE column displayed by rollout history is empty by default. Add the-- record=true option when executing the command to record the contents of the command that triggered the update. In addition, updates in a paused state cannot be rolled back.

Capacity expansion and reduction

Directly modify the spec.replicas and apply in the configuration list to change the number of copies of the Pod resource, or you can use the special command kubectl scale:

Kubectl scale [--resource-version=version] [--current-replicas=count]-- replicas=COUNT (- f FILENAME | TYPE NAME)

For example, when the current number of Pod replicas is 4, adjust to 2:

Kubectl scale-current-replicas=4-replicas=2 deployment/myapp-deployDaemonSet controller

DaemonSet is used to run a specified copy of Pod resources on all or specified nodes in the cluster at the same time. Subsequent new working nodes in the cluster will also automatically create a related Pod object. When nodes are removed from the cluster, such Pod objects will also be automatically reclaimed without having to be rebuilt. DaemonSet is a special controller, which has specific application scenarios. It usually runs those applications that perform system-level operation tasks, such as daemons for cluster storage, log collection daemons, agent daemons for monitoring the system, and so on.

ApiVersion: apps/v1kind: DaemonSetmetadata: name: daemonset-demospec: selector: matchLabels: app: daemonset-pod template: metadata: labels: app: nodeSelector: kubernetes.io/hostname: docker-desktop containers:-name: myapp image: ikubernetes/myapp:v1 imagePullPolicy: NeverJob Controller

The Job controller is used to provision the Pod object to run an one-time task. After the process in the container is running normally, the Pod object will be placed in the Completed state. The configuration checklist for the Job controller is relatively simple:

ApiVersion: batch/v1kind: Jobmetadata: name: job-examplespec: completions: 5 parallelism: 5 template: metadata: labels: app: job1 spec: restartPolicy: Never containers:-name: job1 image: alpine command: ["/ bin/sh", "- c", "sleep 5"]

The spec.restartPolice in the Pod template defaults to "Always", but only "Never" or "OnFailure" is supported for the Job controller, so you must explicitly set the value of the restartPolicy property. After the apply resource list, the job starts execution. If the execution is completed smoothly, the job resource will be in the Succeed state, and the job resource will be automatically tagged with job-name='name', such as job-name=job-example, based on which you can use the tag selector to view the job status.

Serial and parallel control

Spec.completions represents the total number of tasks, and spec.parallelism represents parallelism. The default is 1, so job is completed after one execution. If parallelism is set to 1 and completions is set to 5, job will run 5 times in serial mode. If parallelism is also set to 5, 5 job instances will be run in parallel. If the completions is greater than parallelism,Job, the controller runs multitasking in a serial manner. You can use the-- watch option to monitor the running status of job

Kubectl get jobs-l job-name=job-example-- watch delete Job

The Job controller will no longer occupy the system resources after its Pod resources have been run. Users can retain them as needed or delete them using the resource delete command. But if the container application of a Job controller doesn't work properly and its restartPolicy is set to restart, it may be in a cycle of constant restarts and errors. The following two attributes are used to suppress the occurrence of this situation: spec.activeDeadlineSeconds, which specifies the maximum execution time of the job, which will be terminated; and spec.backoffLimit, the maximum number of retries, which is marked as a failure, and the default value is 6. ActiveDeadlineSeconds has a higher priority than backoffLimit, and if the time is up, but the backoffLimit has not yet arrived, the Job will be forced to stop.

CornJob controller

The CronJob controller is used to manage the run time of the Job controller resources. Job tasks defined by Job controllers are executed immediately after their controller resources are created, but CronJob can control when it runs and how it is repeated in a manner similar to the periodic task job schedule (crontab) of the Linux operating system.

ApiVersion: batch/v1beta1kind: CronJobmetadata: name: cronjob-example labels: app: cronjob1spec: schedule: "* *" jobTemplate: metadata: labels: app: cronjob1-job spec: template: spec: restartPolicy: Never containers:-name: job1 image: alpine command: ["/ bin/sh", "- c", "date Echo Hello from the kubernetes cluster; sleep 1 "]

This cronjob does not run every minute. The syntax of schedule can be found here. The time of schedule is based on the time zone of kube-controller-manager.

After the task has been started for some time, you can use the log command to view the pod output:

Kubectl logs cronjob-example-1620082920-vg7p8Pod interrupts budget

Pod interrupts can be broadly divided into two types:

Involuntary interrupts refer to those Pod interrupt exit operations caused by uncontrollable external factors, such as hardware or system kernel failures, network failures, and Pod objects being expelled due to insufficient node resources, etc.

Voluntary interrupts refer to those Pod interruptions caused by management operations specifically performed by users, such as emptying nodes, artificially deleting Pod objects, and rebuilding Pod objects triggered by update operations. Although controllers such as Deployment or ReplicaSet can ensure that the number of copies of the corresponding Pod objects is constantly approaching the desired number, it cannot guarantee that a specified number or proportion of Pod objects will exist at some point in time. However, this requirement is necessary in some scenarios that emphasize service availability. The Pod interruption budget (PodDisruptionBudget,PDB) can be used to budget for voluntary interruptions (Budget), to limit the maximum number of Pod replicas that can be voluntarily interrupted or to ensure the minimum number of Pod replicas available to ensure high availability of services.

When defining PDB resources, the spec fields are mainly nested using the following three fields:

Selector, the tag selector currently used by PDB objects, generally uses the same selector as the associated Pod controller.

In scenarios where minAvailable,Pod is voluntarily interrupted, at least the number or proportion of Pod objects available should be guaranteed. To prevent any Pod object from voluntarily interrupting, set it to 100%.

In a scenario where maxUnavailable,Pod is voluntarily interrupted, the maximum number or proportion of Pod objects that can be converted to unavailable state. A value of 0 means that voluntary interruptions of Pod objects are not allowed. This field is mutually exclusive with minAvailable.

ApiVersion: policy/v1beta1kind: PodDisruptionBudgetmetadata: name: pdb1spec: minAvailable: 2 selector: matchLabels: app: myapp at this point, the study of "what is a Pod controller" is over. I hope to be able to solve your 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.