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

one。 Background

With the further use of Kubernetes, we more and more realize the efficiency and convenience it brings to our work. Rolling Update is a powerful function in Kubernetes system, which can bring great convenience to our operation and maintenance work.

two。 Step 2.1 deploy the initial version of Deployment.

The YAML of the initial Deployment is as follows:

ApiVersion: apps/v1beta1kind: Deploymentmetadata: name: deployment-rolloutspec: replicas: 4 template: metadata: labels: test: httpd spec: containers:-name: httpd-rollout-test image: httpd:2.2.31 ports:-containerPort: 80

Execute the command:

[root@k8s-m] # kubectl get deployment- o wideNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORdeployment-rollout 4 4 4 107s httpd-rollout-test httpd:2.2.31 test=httpd [root@k8s-m] # kubectl get replicaset-o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORdeployment-rollout-5fb9c69c5c 4 4 4 116s httpd-rollout-test httpd:2.2.31 pod-template-hash=5fb9c69c5c Test=httpd2.2 upgrades the initial version.

Upgrade to 2.4.31 Magi YAML as follows:

ApiVersion: apps/v1beta1kind: Deploymentmetadata: name: deployment-rolloutspec: revisionHistoryLimit: 10 replicas: 4 template: metadata: labels: test: httpd spec: containers:-name: httpd-rollout-test image: httpd:2.4.33 ports:-containerPort: 80

Execute the command:

[root@k8s-m] # kubectl apply-f Httpd-Deployment-rollout-v1.yamldeployment.apps/deployment-rollout configured [root@k8s-m] # kubectl get deployment- o wideNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORdeployment-rollout 4 5 2 3 3m57s httpd-rollout-test httpd:2.4.33 Test=httpd [root@k8s-m ~] # kubectl get replicaset-o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORdeployment-rollout-54766f574f 2 20 93s httpd-rollout-test httpd:2.4.33 pod-template-hash=54766f574f Test=httpddeployment-rollout-5fb9c69c5c 3 3 3 4m12s httpd-rollout-test httpd:2.2.31 pod-template-hash=5fb9c69c5c Test=httpd [root@k8s-m ~] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEdeployment-rollout-54766f574f-668pc 0 ContainerCreating 0 114s k8s-n1 deployment-rollout-54766f574f-ssz67 0 k8s-n2 deployment 1 ContainerCreating 0 115s k8s-n2 deployment -rollout-5fb9c69c5c-m5dvs 1 Running 0 Running 0 4m34s 10.244.2.47 k8s-n2 deployment-rollout-5fb9c69c5c-p9grr 1 Running 0 4m34s 10.244.1.113 k8s-n1 deployment-rollout-5fb9c69c5c-tzm7w 1 Running 0 4m34s 10.244.2.48 k8s-n2

We'll take a look at it after a while:

[root@k8s-m] # kubectl get replicaset-o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORdeployment-rollout-54766f574f 4 44 4m24s httpd-rollout-test httpd:2.4.33 pod-template-hash=54766f574f,test=httpddeployment-rollout-5fb9c69c5c 0 000 7m3s httpd-rollout-test httpd:2.2.31 pod-template-hash=5fb9c69c5c Test=httpd [root@k8s-m] # kubectl get deployment- o wideNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORdeployment-rollout 4 4 4 7m18s httpd-rollout-test httpd:2.4.33 test=httpd [root@k8s-m] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEdeployment-rollout-54766f574f-668pc 1/1 Running 0 4m48s 10.244.1.114 k8s-n1 deployment-rollout-54766f574f-h7gf9 1/1 Running 0 99s 10.244.2.50 k8s-n2 deployment-rollout-54766f574f-ssz67 1/1 Running 0 4m49s 10.244.2 . 49 k8s-n2 deployment-rollout-54766f574f-vklvr 1/1 Running 0 41s 10.244.1.115 k8s-n1

In the process, we will find that ReplicaSet deployment-rollout-5fb9c69c5c is gradually replaced by deployment-rollout-54766f574f, and after a new version of Pod is created, the original version of Pod is terminated. This is a smooth upgrade process. Kubernetes provides two parameters, maxSurge and maxUnavailable, to finely control the number of Pod replacements.

Rollback of version 2.3.

By default, Kubernetes retains only the most recent revision. During the upgrade process above, the number of revision is set through revisionHistoryLimit. Let's take a look at it by order:

[root@k8s-m ~] # kubectl rollout history deployment deployment-rolloutdeployment.extensions/deployment-rolloutREVISION CHANGE-CAUSE1 2

Continue to upgrade. The new version of YAML is as follows:

ApiVersion: apps/v1beta1kind: Deploymentmetadata: name: deployment-rolloutspec: revisionHistoryLimit: 10 replicas: 4 template: metadata: labels: test: httpd spec: containers:-name: httpd-rollout-test image: httpd:2.4.34 ports:-containerPort: 80

Perform the upgrade and log the upgrade.

[root@k8s-m] # kubectl apply-f Httpd-Deployment-rollout-v2.yaml-- recorddeployment.apps/deployment-rollout configured [root@k8s-m ~] # kubectl rollout history deployment deployment-rolloutdeployment.extensions/deployment-rolloutREVISION CHANGE-CAUSE1 2 3 kubectl apply-- filename=Httpd-Deployment-rollout-v2.yaml-- record=true [root@k8s-m ~] # kubectl get deployment deployment-rollout-o wideNAME DESIRED CURRENT UP-TO -DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORdeployment-rollout 4 4 4 31m httpd-rollout-test httpd:2.4.34 test=httpd [root@k8s-m ~] # kubectl get replicaset-o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORdeployment-rollout-54766f574f 0 0 0 29m httpd-rollout-test httpd:2.4.33 pod-template-hash=54766f574f Test=httpddeployment-rollout-54fc66bb6 4 4 4 6m12s httpd-rollout-test httpd:2.4.34 pod-template-hash=54fc66bb6,test=httpddeployment-rollout-5fb9c69c5c 0 0 0 32m httpd-rollout-test httpd:2.2.31 pod-template-hash=5fb9c69c5c Test=httpd [root@k8s-m ~] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEdeployment-rollout-54fc66bb6-2zvhk 1 k8s-n1 1 Running 0 6m26s 10.244.1.116 k8s-n1 deployment-rollout-54fc66bb6-7rsj6 1 Running 0 4m16s 10.244.1.117 k8s-n1 Deployment-rollout-54fc66bb6-nlx4h 1/1 Running 0 6m26s 10.244.2.51 k8s-n2 deployment-rollout-54fc66bb6-xxnrg 1/1 Running 0 6m24s 10.244.2.52 k8s-n2

Modify the version of the image in the YAML file to continue the upgrade, and observe the upgrade result:

[root@k8s-m] # kubectl rollout history deployment deployment-rolloutdeployment.extensions/deployment-rolloutREVISION CHANGE-CAUSE1 2 3 kubectl apply-- filename=Httpd-Deployment-rollout-v2.yaml-- record=true4 kubectl apply-- filename=Httpd-Deployment-rollout-v3.yaml-- record=true [root@k8s-m ~] # kubectl get replicaset-o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORdeployment-rollout-54766f574f 0 0 0 33m httpd-rollout-test httpd:2.4.33 pod-template-hash=54766f574f Test=httpddeployment-rollout-54fc66bb6 0 0 0 10m httpd-rollout-test httpd:2.4.34 pod-template-hash=54fc66bb6,test=httpddeployment-rollout-5b99bbfbbc 4 4 4 2m33s httpd-rollout-test httpd:2.4.35 pod-template-hash=5b99bbfbbc,test=httpddeployment-rollout-5fb9c69c5c 0 0 0 36m httpd-rollout-test httpd:2.2.31 pod-template-hash=5fb9c69c5c Test=httpd [root@k8s-m ~] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEdeployment-rollout-5b99bbfbbc-7mdg9 1 Running 0 65s 10.244.1.119 k8s-n1 deployment-rollout-5b99bbfbbc-9mfbk 1 Running 0 2m40s 10.244.1.118 k8s-n1 Deployment-rollout-5b99bbfbbc-jn5sb 1/1 Running 0 2m40s 10.244.2.53 k8s-n2 deployment-rollout-5b99bbfbbc-tr6t2 1/1 Running 0 2m38s 10.244.2.54 k8s-n2

The image of httpd has been upgraded to 2.4.35, so let's try rolling back to v2:

[root@k8s-m] # kubectl rollout undo deployment deployment-rollout-- to-revision=3deployment.extensions/deployment-rollout [root@k8s-m] # kubectl get deployment- o wideNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORdeployment-rollout 4 4 4 42m httpd-rollout-test httpd:2.4.34 test=httpd [root @ k8s-m ~] # kubectl get replicaset-o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORdeployment-rollout-54766f574f 00039m httpd-rollout-test httpd:2.4.33 pod-template-hash=54766f574f Test=httpddeployment-rollout-54fc66bb6 4 4 4 16m httpd-rollout-test httpd:2.4.34 pod-template-hash=54fc66bb6,test=httpddeployment-rollout-5b99bbfbbc 0 0 0 8m35s httpd-rollout-test httpd:2.4.35 pod-template-hash=5b99bbfbbc,test=httpddeployment-rollout-5fb9c69c5c 0 0 0 42m httpd-rollout-test httpd:2.2.31 pod-template-hash=5fb9c69c5c Test=httpd [root@k8s-m ~] # kubectl get pod-o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEdeployment-rollout-54fc66bb6-bjskn 1 Running 0 68s 10.244.1.121 k8s-n1 deployment-rollout-54fc66bb6-c65th 1 Running 0 70s 10.244.2.55 k8s-n2 deployment -rollout-54fc66bb6-cwpbk 1 Running 0 70s 10.244.1.120 k8s-n1 deployment-rollout-54fc66bb6-lz9xt 1 Running 0 68s 10.244.2.56 k8s-n2 [root@k8s-m ~] # kubectl rollout history deployment deployment-rolloutdeployment.extensions/deployment-rolloutREVISION CHANGE-CAUSE1 24 kubectl apply-- filename=Httpd-Deployment-rollout-v3.yaml- -record=true5 kubectl apply-filename=Httpd-Deployment-rollout-v2.yaml-record=true

The number of REVISION increases by 1 after each upgrade or rollback operation. Through kubectl history, we can see the record of each upgrade-- record records the detailed process of each operation. The rollback operation is performed through kubectl undo, and the option-- to-revision specifies the revision number of the rollback.

three。 Summary

3.1. Once again impressed by the charm of Kubernetes, the usual work of grayscale upgrade / release / update (stop the old version instance by batch, enable the new version instance, the new version coexist, gradually expand the scope of the new version, and eventually migrate all users to the new version), blue-green upgrade / release / update (do not stop the old version, deploy a new version, the new version passes the test release and deletes the old version) Rolling upgrade / release / update (one or more services stop, perform updates, gradually put the new version into use, cycle through, and eventually complete version updates for all instances in the entire cluster) these concepts are more thoroughly understood.

3.2. At present, some materials are no longer applicable to the new version, do not be misled by online materials, must be based on official documents and system help. For example:

The only Deploy-related commands for Kubernetes are:

Deploy Commands: rollout Manage the rollout of a resource scale sets a new number of copies for Deployment, ReplicaSet, ReplicationController or Job autoscale automatically adjusts the number of copies of a Deployment, ReplicaSet, or ReplicationController

Types of resources available for Rollout:

Valid resource types include: * deployments * daemonsets * statefulsets

3. 3 Rollout updat can also be implemented through YAML, which will be covered in a later article.

four。 Related materials

4.1 yaml files related to this article

4.2 official information

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.