• ReplicaSet controller
    • Create ReplicaSet
    • A Pod object controlled by the ReplicaSet
    • Update the ReplicaSet
  • Deployment controller
    • Create a Deployment
    • Update strategy
    • Upgrade Deployment
    • Published by Canary
    • Capacity expansion and reduction
  • DaemonSet controller
  • Job controller
    • Serial and parallel control
    • Delete the Job
  • CornJob controller
  • Pod interrupt budget

The autonomous Pod object is bound to the target working node by the scheduler, that is, the Kubelet on the corresponding node is responsible for monitoring the activity of its container. After the main process of the container crashes, Kubelet can automatically restart the corresponding container. Based on the activity detection, it can also respond to other problems in the container. But if the Pod is accidentally deleted, or the working node fails, Kubelet can’t help. The Pod controller deals with these situations. The Pod controller is provided by the Master’s Kube-Controller-Manager component. Kube-controller-manager is an independent daemon that contains a number of controllers with different functions, except Pod Controller, There are NodeLifecycle Controller, Namespace Controller, Service Controller, and so on. These controllers continuously monitor the resources they are responsible for and attempt to migrate and approximate the current state of the resources to the desired state when the system state changes due to failures, updates, or other reasons.

ReplicaSet controller

ReplicaSet replaces earlier ReplicationController and ensures that the number of Pod objects it manages is exactly what it wants at any given time

ReplicaSet provides the same functionality as a user’s manual Pod, but it does the following:

  • Ensure that the number of Pod resource objects accurately reflects the expected value
  • Ensure Pod healthy operation. When detecting that the Pod object under its control is unavailable due to the failure of its working node, it automatically requests the scheduler to create the missing Pod copy on other working nodes
  • Elastic scaling: The ReplicaSet controller dynamically adjusts the number of related Pod resource objects when the resource demand fluctuates greatly. It can also be used with HroizontalPodAutoscaler (HPA) to achieve automatic scaling of Pod resource scale.

Create ReplicaSet

The spec of a TYPICAL Pod controller resource list contains the following basic properties:

  • Selector: a tag selector that matches and associates Pod resource objects and counts the managed Pod resources accordingly
  • Replicas: The expected number of replicas, the number of objects that are expected to be exactly running in the cluster
  • Template: A Pod template used to create a Pod template resource for a Pod resource object

Such as:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: rs-example
spec:
 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

Copy the code

Kubectl get Pods -l app=rs-demo kubectl get Pods -l app=rs-demo Kubectl get Pods -l app=rs-demo Rs – example – – example – wj8zg j98fp, rs. Run kubectl get Replicaset rs-example with -o json\wide and other options to view the detailed status of the controller.

A Pod object controlled by the ReplicaSet

ReplicaSet responds to changes in the number of Pod objects because it registers with the API Server to listen for changes in the resource and its list, and the API Server notifies listeners immediately when changes occur.

Missing, extra Pod copy

The ReplicaSet controller automatically makes up for any lost Pod objects. If you manually delete a Pod, ReplicaSet will create a new one. ReplicaSet previously created relies on the tag app: Rs-demo to manage the Pod, forcing this tag to change will also trigger a new copy: Kubectl Label Pods Rs-example-wj8zg app=others — Overwrite the previous Pod rs-example-wj8zg is still available, if it can be selected by another controller through the label selector, it will belong to the controller. Will it become a self-service Pod? The redundant parts will be automatically deleted by the controller, and the ones with the smallest Age will be deleted first.

The kubectl describe Replicasets /rs-example command prints ReplicaSet status and Events.

Update the ReplicaSet

Change template: Upgrade the application

Changing the template does not work for live objects that have already been created, but you can manually close older versions of their Pod resources one by one to achieve a rolling upgrade. Compared to ReplicaSet’s manual approach, the Deployment controller automatically implements more sophisticated rolling updates and rollbacks and provides users with an interface to customize their update policies.

Change replicas: Expand and shrink replicas

By modifying replicas attributes and applying, the application scale can be scaled horizontally. Kubectl also provides a special subcommand scale to scale applications, such as: Kubectl scale replicasets rs-example –replicas=2 Kubectl scale replicasets rs-example –current-replicas=4 –replicas=2

If ReplicaSet manages stateful applications, such as a master-slave Redis cluster, all of these operations require careful orchestration and participation. For these needs, K8S can provide StatefulSet. ReplicaSet is typically used only to manage stateless applications, such as HTTP servers.

Delete the ReplicaSet resource

Kubectl delete -f… Or kubectl delete replicaset… When a ReplicaSet object is deleted, all its managed Pod objects are deleted by default. Sometimes, however, you can add the –cascade=false option to cancel the cascade deletion, considering that the Pod resource may not be created by the Pod resource, or that the Pod resource may be used again later.

Deployment controller

The Deployment controller is built on top of the ReplicaSet controller and provides declarative updates to Pod and ReplicaSet resources. Pod and ReplicaSet are low-level resources that are rarely used directly. Deployment controller builds on ReplicaSet with a number of enhancements:

  • Event and status viewing: Detailed progress and status of the Deployment object upgrade can be viewed if necessary
  • Rollback: When an upgrade finds a problem, the rollback mechanism can be used to return the application to a previous or specified historical version
  • Version record: Saves a record of each operation for possible subsequent rollback operations
  • Pause and Start: For each upgrade, you can pause and start at any time
  • Various automatic update schemes:
    • Recreate an update mechanism that completely stops, removes, and replaces existing pods with a new version
    • RollingUpdate, a rolling upgrade mechanism that gradually replaces old pods to new versions.

Create a Deployment

Deployment uses the ReplicaSet object as its secondary resource. The configuration list has the same fields as ReplicaSet except kind and name. Example:

kind: Deployment
metadata:
  name: myapp-deploy
Copy the code

Kubectl get deployments myapp-deploy kubectl get deployments myapp-deploy

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deploy   2/2     2            2           15s
Copy the code

Up-to-date indicates the number of Pod copies that have reached the desired state, and AVAILABLE indicates the number of applications that are currently AVAILABLE. View the relevant ReplicaSet resource:

~ kubectl get replicasets -l app=myapp   
NAME                      DESIRED   CURRENT   READY   AGE
myapp-deploy-7cfbdc886d   2         2         2       2m53s
Copy the code

ReplicaSet resources are named in the [deployment-name]-[pod-template-hash-value] format.

~ kubectl get pods -l app=myapp          
NAME                            READY   STATUS    RESTARTS   AGE
myapp-deploy-7cfbdc886d-8lw6f   1/1     Running   0          4m55s
myapp-deploy-7cfbdc886d-xn7xp   1/1     Running   0          4m55s
Copy the code

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

Update strategy

The Deployment controller supports both RollingUpdate and concrete update strategies, which default to RollingUpdate.

Recreate

Similar to using ReplicaSet, all Pod objects are deleted at once and the controller recreates the new version resource object based on the new template. This approach should generally only be used when the old and new versions of the application are incompatible (for example, the schema of the dependent back-end database is different and incompatible), because it can cause temporary unavailability during application replacement, but the advantage is that there is no intermediate state.

RollingUpdate

Rolling upgrade is to delete some of the Pod resources of the old version and create some of the Pod objects of the new version. In this way, the service provided by the application in the container will not be interrupted, but the application must be able to handle the situation that the old version and the new version work together, for example, the old version is compatible with the same database scheme. In a rolling upgrade, both the old and new versions of ReplicaSet exist. The number of Pod objects in the old ReplicaSet decreases while the number of Pod objects in the new ReplicaSet increases until the old ReplicaSet no longer has Pod objects. The new ReplicaSet has exactly the number of copies expected. During the upgrade, also ensure that the number of Pod objects available does not fall below a certain threshold to ensure that client service requests can be continuously processed, Changes in the way of object and Pod number range will be through the spec. The strategy. The rollingUpdate maxSurge and maxUnavailable under two attributes synergy definition:

  • MaxSurge: The maximum number of total Pod objects that can exist during an upgrade beyond the expected value, which can be 0 or a positive integer, or an expected percentage
  • MaxUnavailable: The number of Pod copies (both old and new versions) that are normally available during an upgrade cannot be less than the desired number. The value can be 0 or a positive integer, or it can be an expected percentage. The default value is 1.

MaxSurge and maxUnavailable define the fluctuation range of the number of pods, so their values cannot be 0 at the same time. For example, they work as follows:

Alternatively, you can set the spec.minReadyseconds property:

  • To control the upgrade speed of the application. When rolling the upgrade, the default new Pod object is available as long as it is ready to detect successfully, so the next round of replacement operation begins. MinReadySeconds can define at least how long a new Pod object must wait after creation before it is considered ready, during which time updates are blocked.

Upgrade Deployment

The Deployment controller resources can be updated by modifying configuration parameters related to the Pod template, which can be modified by using 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, use the “kubectl patch” command to specify minReadySeconds=6s:

kubectl patch deployments myapp-deploy -p '{"spec":{"minReadySeconds":6}}'
Copy the code

Changing the values of fields such as minReadySeconds, Replicas, and Strategy in the Deployment controller does not trigger update operations on the Pod resource because they do not have any effect on the existing Pod objects. Update the image version using the set image command:

kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v2
Copy the code

Run the following command to view the rolling upgrade process:

kubectl rollout status deployments myapp-deploy --watch
Copy the code

After the upgrade, the old ReplicaSet controller will remain in the historical record, but its previous managed Pod objects will be deleted.

Published by Canary

The Deployment controller supports pause, continue, and, in combination with maxSurge and maxUnavailable, enables Canary Release, which pauses the update process immediately after the first batch of new Pod resources are created. There are only a small number of new versions of the application, the main part is the old version. Then, a small part of the traffic will be directed to the new VERSION of THE Pod application, and continue to observe whether it can stably operate in the expected way, and continue to complete the rolling update of the remaining Pod resources after confirming that there is no problem, otherwise, the update operation will be immediately rolled back. In order to minimize the impact on the existing system, canary publishing is usually recommended to be “first add, then remove, and the total number of available Pod resource objects is not less than the expected”. The number of Pod objects added for the first time depends on the rules of the first requests it receives and the carrying capacity of a single Pod. In the next experiment, set the maxSurge and maxUnavailable to 1 and 0, respectively, and trigger the update by changing the upgrade version of the mirror, but pause it after the first batch of updates are started. Due to minReadySeconds, you can issue the pause command during this process. For Kubectl, It is also possible to concatenate two commands directly in the Shell with the && symbol:

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

The update operation has been suspended:

kubectl rollout status deployments myapp-deploy 
Copy the code

At this point, through Service or Ingress resources and related routing policies and other Settings, you can divert some users’ traffic to these PODS for publication verification. After confirming that there is no problem, you can continue to update:

kubectl rollout resume deployments myapp-deploy
Copy the code
The rollback

If the rolling update fails due to various reasons, such as image file retrieval failure, canary in distress, etc., the application should be rolled back to the previous version or the specified historical version, and directly to the previous version:

kubectl rollout undo deployments myapp-deploy
Copy the code

With the — to-Revision option to roll back to the specified version, you can view the saved historical version with the following command:

kubectl rollout history deployments myapp-deploy
Copy the code

It is important to note that only the rollback to be saved version of history, the spec. RevisionHistoryLimit defines the version number of the preservation, the default is 10. In addition, the CHANGE-CAUSE column displayed in rollout History is empty by default, and the –record=true option is added when executing the command to record the contents of the command that triggered the update. In addition, paused updates cannot be rolled back.

Capacity expansion and reduction

You can change the number of replicas of the Pod resource by directly modifying the spec.replicas in the configuration manifest and applying them, or by using the kubectl scale command:

kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)
Copy the code

For example, if the current number of Pod copies is 4, change it to 2:

kubectl scale --current-replicas=4 --replicas=2 deployment/myapp-deploy  
Copy the code

DaemonSet controller

DaemonSet is used to run a copy of designated Pod resources on all or designated nodes in the cluster at the same time. Subsequent new working nodes that join the cluster will also automatically create a related Pod object. When nodes are removed from the cluster, such Pod objects will also be automatically recovered without reconstruction. DaemonSet is a special type of controller with specific application scenarios. It usually runs applications that perform system-level operational tasks, such as cluster storage daemons, log collection daemons, agent daemons that monitor systems, etc.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-demo
spec:
  selector:
    matchLabels:
      app: daemonset-pod
  template:
    metadata:
      labels:
        app: daemonset-pod
    spec:
      nodeSelector:
        kubernetes.io/hostname: docker-desktop
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        imagePullPolicy: Never
Copy the code

Job controller

The Job controller is used to deploy a Pod object to execute a one-time task. After the process in the container is Completed, the Pod object is placed in the state of Completed. The Job controller configuration list is relatively simple:

apiVersion: batch/v1
kind: Job
metadata:
  name: job-example
spec:
  completions: 5
  parallelism: 5
  template:
    metadata:
      labels:
        app: job1
    spec:
      restartPolicy: Never
      containers:
      - name: job1
        image: alpine
        command: ["/bin/sh", "-c", "sleep 5"] 
Copy the code

The default spec.restartPolicy in the Pod template is Always, but only Never or OnFailure is supported for the Job controller. Therefore, you must explicitly set the value of the restartPolicy property. After applying the resource list, the job starts to be executed. If the job is successfully executed, it is in the Succeed state. The job resource is automatically labeled job-name=’name’, for example, job-name=job-example

Serial and parallel control

Parallelism is set to 1, so the job is executed once. If parallelism is set to 1 and Completions is set to 5, the job will run five times in serial mode. If Parallelism is also set to 5, five job instances will run in parallel. If completions are larger than Parallelism, the Job controller will run multiple tasks in serial mode. You can use the –watch option to monitor the running status of the job

kubectl get jobs -l job-name=job-example --watch
Copy the code

Delete the Job

The Job controller does not occupy system resources after the Pod resources are running. Users can reserve them on demand or delete them using the resource deletion command. However, if the container application of a Job controller always fails to end and its restartPolicy is set to restart, it may be in a cycle of repeated restarts and errors. The following two property is used to inhibit the occurrence of this kind of circumstance: spec. ActiveDeadlineSeconds, is used to specify the maximum execution time, the job is beyond will be terminated. Spec. backoffLimit, the maximum number of retries that will be marked as a failure. The default value is 6. ActiveDeadlineSeconds has a higher priority than backoffLimit. If the time is up but the backoffLimit has not arrived, the Job is forcibly stopped.

CornJob controller

The CronJob controller manages the running time of Job controller resources. The jobs defined by the Job controller are executed immediately after the controller resources are created. However, the CronJob can control the running time and the repeated running mode in a manner similar to the periodic task scheduling (Crontab) in Linux.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-example
  labels:
    app: cronjob1
spec:
  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"]
Copy the code

This cronjob runs every minute. The syntax of schedule can be seen here. The schedule time is based on the kube-Controller-manager time zone.

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

kubectl logs cronjob-example-1620082920-vg7p8
Copy the code

Pod interrupt budget

Pod interrupts can be broadly divided into two types:

  • Involuntary interruption refers to the interruption and exit operation of Pod caused by uncontrollable external factors, such as hardware or system kernel failure, network failure, and the expulsion of Pod objects due to insufficient node resources.
  • Voluntary outages refer to those Pod outages that are caused by administrative actions specifically performed by the user, such as empting nodes, manually deleting Pod objects, or rebuilding Pod objects triggered by update operations.

Although a controller such as Deployment or ReplicaSet can ensure that the number of copies of the corresponding Pod objects approaches the desired number, it cannot guarantee that there will be a specified number or proportion of Pod objects at any given time, but this requirement may be necessary in some scenarios that emphasize service availability. A Pod Interrupt Budget (PDB) can be used to Budget for voluntary interrupts, limiting the maximum number of Pod copies that can be voluntarily interrupted or ensuring the minimum number of Pod copies available to ensure high availability of the service.

When defining a PDB resource, the spec field mainly uses the following three fields nested:

  • Selector, the label selector used by the current PDB object, typically the same selector as the associated Pod controller.
  • At least the number or proportion of Pod objects available should be guaranteed in scenarios where Pod voluntary interrupts occur. To prevent any Pod objects from voluntary interrupts, set it to 100%
  • MaxUnavailable: The maximum number or percentage of Pod objects that can be converted to an unavailable state in a scenario where Pod interrupts voluntarily. A value of 0 means Pod objects are not allowed to voluntarily interrupt. This field is mutually exclusive with minAvailable.
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: pdb1
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp
Copy the code
Learning materials

Kubernetes combat advanced ma Yongliang