In-depth kubernetes controller: K8s deployment controller

Recommended reading:

• I summarized 72 interview questions, totaling 3170 pages, and won 30+ Internet company offers (including BATJM)

• I won the first battle in 2020. This Java Interview Magic Plus version allowed me to successfully get offers from major manufacturers such as Ali, JD.com, and Bytedance.

• Worship the boss! The K8S (kubernetes) study guide that Ali is pushing internally, can’t be more detailed

Deployment can manage Pod very conveniently. You only need to describe the desired Pod state in Deployment, including defining the number of Pod replicas, rolling upgrades and rolling back applications, expanding and shrinking, suspending and continuing Deployment, etc., and then Deployment Controller can help us achieve the state we want to achieve.

Let's start with an example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

In this example:

• We have defined a Deployment named nginx-deployment;

• The number of Pod replicas is defined as 2 through the spec.replicas field;

• Only Pods that are marked with app: nginx can be managed through the spec.selector field;

• The tmplate field defines what the Pod managed by this Deployment should look like and what attributes it has;

In general, a Deploymet controller can consist of two parts:

ReplicaSet

ReplicaSet is a replica controller, ReplicaSet can use selector to control the number of Pods, and Deployments is a higher-level concept that manages ReplicaSets, and provides declarative updates to pods and many other functions.

By controlling the number and attributes of ReplicaSet, Deployment realizes the two orchestration actions of "horizontal expansion/contraction" and "rolling update".

Horizontal expansion and rolling update

We can create a Deployment with the following command:

kubectl create -f nginx-deployment.yaml --record

The function of the -record parameter here is to record the commands you execute in each operation for easy viewing later.

Check the deployment status:

kubectl get deployments

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           33m

• NAME: List the names of Deployments;
• READY: Shows how many copies of the application are available, the current number of copies/the number of expected copies;
• UP-TO-DATE: Shows the number of times the copy has been updated, here it is displayed as 2, indicating that it has been updated twice;
• AVAILABLE: Shows how many copies of the application are available;
• AGE: Shows the running time of the application.

Now we use kubectl scale to do a horizontal expansion:

kubectl scale deployment nginx-deployment --replicas=4

deployment.apps/nginx-deployment scaled

Then we can use rollout status to view the status of the rolling update:

kubectl rollout status deployment/nginx-deployment

Waiting for deployment "nginx-deployment" rollout to finish: 2 of 4 updated replicas are available...
Waiting for deployment "nginx-deployment" rollout to finish: 3 of 4 updated replicas are available...
deployment "nginx-deployment" successfully rolled out

The 3 of 4 updated replicas are available above means that 3 Pods have entered the UP-TO-DATE state.

Then we can also check the ReplicaSet status:

kubectl get rs

NAME                         DESIRED   CURRENT   READY   AGE
nginx-deployment-9754ccbdf   4         4         4       44m

After running a deployment modification, the Deployment Controller will create a replica as ReplicaSet and generate a string of random characters. ReplicaSet will add this random string to the labels of all Pods it controls to ensure that these Pods will not Confused with other Pods in the cluster.

We can check it through kubectl get pods –show-labels:

NAME                               READY   STATUS    RESTARTS   AGE    LABELS
nginx-deployment-9754ccbdf-5pl2j   1/1     Running   0          5m4s   app=nginx,pod-template-hash=9754ccbdf
nginx-deployment-9754ccbdf-67d4g   1/1     Running   0          48m    app=nginx,pod-template-hash=9754ccbdf
nginx-deployment-9754ccbdf-9drgb   1/1     Running   0          48m    app=nginx,pod-template-hash=9754ccbdf
nginx-deployment-9754ccbdf-fdmrx   1/1     Running   0          5m4s   app=nginx,pod-template-hash=9754ccbdf

Let's take a look at how the rolling update of Deployment is done:

We use set image to modify the image in the deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record

deployment.apps/nginx-deployment image updated

Then we can view the rolling update process through kubectl describe:

$ kubectl describe deployment nginx-deployment
...
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
...
 Normal  ScalingReplicaSet  29s                 deployment-controller  Scaled down replica set nginx-deployment-9754ccbdf to 3
  Normal  ScalingReplicaSet  29s                 deployment-controller  Scaled up replica set nginx-deployment-dc46b5ffc to 2
  Normal  ScalingReplicaSet  12s (x2 over 11m)   deployment-controller  Scaled down replica set nginx-deployment-9754ccbdf to 2
  Normal  ScalingReplicaSet  12s                 deployment-controller  Scaled up replica set nginx-deployment-dc46b5ffc to 3
  Normal  ScalingReplicaSet  11s                 deployment-controller  Scaled down replica set nginx-deployment-9754ccbdf to 1
  Normal  ScalingReplicaSet  11s                 deployment-controller  Scaled up replica set nginx-deployment-dc46b5ffc to 4
  Normal  ScalingReplicaSet  11s                 deployment-controller  Scaled down replica set nginx-deployment-9754ccbdf to 0

You can see that the Deployment Controller controls the ReplicaSet to reduce the number of old Pod replicas one by one, and creates a new ReplicaSet: nginx-deployment-dc46b5ffc, and increases the number of Pod replicas it controls.

After this "rolling update" process is completed, you can check the final status of the new and old ReplicaSet:

kubectl get rs

NAME                         DESIRED   CURRENT   READY   AGE
nginx-deployment-9754ccbdf   0         0         0       57m
nginx-deployment-dc46b5ffc   4         4         4       5m9s

By default, Deployment will ensure that at least 75% of Pods are still available, so in our example, we will ensure that at least 3 Pods are available.

This strategy is a field of the Deployment object, named RollingUpdateStrategy, as shown below:

 kubectl describe deployment

Name:                   nginx-deployment
...
Selector:               app=nginx
Replicas:               4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
...

25% max unavailable indicates that the maximum 25% is unavailable; 25% max surge indicates the maximum number of new Pods that can be created.

Version control and rollback

In the above operation, we set the version of nginx to 1.16.1, and now we can rollout the version through rollout undo:

kubectl rollout undo deployment/nginx-deployment

deployment.apps/nginx-deployment rolled back

Of course, in addition to this command, because we use –record, we can view the version information through kubectl rollout history:

kubectl rollout history deployment/nginx-deployment

deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
2         kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record=true
3         kubectl apply --filename=nginx-deployment.yaml --record=true

We can see the specific information of the corresponding version through kubectl rollout history:

kubectl rollout history deployment/nginx-deployment --revision=2

Use the kubectl rollout undo command to roll back to the corresponding version:

kubectl rollout undo deployment/nginx-deployment --to-revision=2

Pausing and Resuming a Deployment

In the above operation, we will perform a rolling update for each step of the operation. If we want to execute multiple commands at one time and then perform a rolling update at one time, we can pause Deployment and then resume it after the operation is completed.

as follows:

kubectl rollout pause deployment/nginx-deployment

deployment.apps/nginx-deployment paused

Then you can modify the content of this Deployment at will. Since the Deployment is in a "paused" state at this time, all our modifications to the Deployment will not trigger a new "rolling update" or create a new ReplicaSet.

Execute after operation:

kubectl rollout resume deployment/nginx-deployment

deployment.apps/nginx-deployment resumed

During the period after the kubectl rollout pause instruction, all the modifications we made to the Deployment will only trigger a "rolling update" in the end.