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

This article shows you how to use Deployment to achieve rolling upgrade in Kubernetes, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Create Deployment

You can see that a Deployment has multiple Replica Set, while a Replica Set has one or more Pod. A Deployment controls multiple rs mainly to support the rollback mechanism. Each time a Deployment operation occurs, the Kubernetes regenerates a Replica Set and retains it, and later rolls back to the previous state if necessary. Let's create a Deployment, which creates a Replica Set to launch the three nginx pod,yaml files as follows:

ApiVersion: apps/v1beta1kind: Deploymentmetadata: name: nginx-deploy labels: k8s-app: nginx-demospec: replicas: 3 template: metadata: labels: app: nginx spec: containers:-name: nginx image: nginx:1.7.9 ports:-containerPort: 80

Save the above as: nginx-deployment.yaml, execute the command:

$kubectl create-f nginx-deployment.yamldeployment "nginx-deploy" >

Then execute the command to view the Deployment you just created:

$kubectl get deploymentsNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEnginx-deploy 3 000 0 1s

Execute the above command again every once in a while:

$kubectl get deploymentsNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEnginx-deploy 3 3 3 4m

We can see that Deployment has created three Replica Set. Execute the following command to view rs and pod:

$kubectl get rsNAME DESIRED CURRENT READY AGEnginx-deploy-431080787 3 3 3 6 m $kubectl get pod-- show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx-deploy-431080787-53z8q 1 Running 0 7m app=nginx Pod-template-hash=431080787nginx-deploy-431080787-bhhq0 1/1 Running 0 7m app=nginx,pod-template-hash=431080787nginx-deploy-431080787-sr44p 1/1 Running 0 7m app=nginx,pod-template-hash=431080787

The replicas:3 in the yaml file of Deployment above will ensure that we always have 3 POD running.

Rolling upgrade Deployment

Now let's change the nginx image in the yaml file we just saved to nginx:1.13.3, and then add a rolling upgrade policy under spec:

MinReadySeconds: 5strategy: # indicate which strategy we want for rolling update type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1

MinReadySeconds:

Kubernetes will upgrade after waiting for the set time.

If this value is not set, Kubernetes assumes that the service is provided after the container is started

If this value is not set, it may cause the service to operate normally in some extreme cases.

MaxSurge:

The maximum number of POD that can be increased during the upgrade process is higher than the previous setting.

For example, maxSurage=1,replicas=5 means that Kubernetes will start a new Pod before deleting an old POD, and there will be a maximum of 5 POD in the whole upgrade process.

MaxUnavaible:

The maximum number of POD that cannot provide service during the upgrade process

When maxSurge is not 0, the value cannot be 0.

For example, maxUnavaible=1 means that at most 1 POD will be out of service during the entire upgrade process of Kubernetes.

Then execute the command:

$kubectl apply-f nginx-deployment.yamldeployment "nginx-deploy" configured

Then we can use the rollout command:

View status:

$kubectl rollout status deployment/nginx-deployWaiting for rollout to finish: 1 out of 3 new replicas have been updated..deployment "nginx-deploy" successfully rolled out

Pause upgrade

$kubectl rollout pause deployment

Continue to upgrade

$kubectl rollout resume deployment

After the upgrade is over, continue to view the status of rs:

$kubectl get rsNAME DESIRED CURRENT READY AGEnginx-deploy-2078889897 0 0 0 47mnginx-deploy-3297445372 3 3 3 42mnginx-deploy-431080787 0 0 01 h

According to AGE, we can see that the current status closest to us is: 3, which is consistent with our yaml file, which proves that the upgrade is successful. You can view all the information about the upgrade with the describe command:

Name: nginx-deployNamespace: defaultCreationTimestamp: Wed, 18 Oct 2017 16:58:52 + 0800Labels: k8s-app=nginx-demoAnnotations: deployment.kubernetes.io/revision=3 kubectl.kubernetes.io/last-applied-configuration= {"apiVersion": "apps/v1beta1", "kind": "Deployment", "metadata": {"annotations": {}, "labels": {"k8s-app": "nginx-demo"}, "name": "nginx-deploy" "namespace": "defa...Selector: app=nginxReplicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable 25% max surgePod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.13.3 Port: 80/TCP Environment: Mounts: Volumes: Conditions: Type Status Reason-Progressing True NewReplicaSetAvailable Available True MinimumReplicasAvailableOldReplicaSets: NewReplicaSet: nginx-deploy-3297445372 (3go 3 replicas created) Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message- -50m 50m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-2078889897 to 1 45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-2078889897 to 045m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 1 39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 2 39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 2 38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 1 38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 3 38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 0 rollback Deployment

We have been able to scroll and smoothly upgrade our Deployment, but what if something goes wrong with the upgraded POD? The best and fastest way we can think of is, of course, to go back to the last version that worked, and Deployment provides us with a rollback mechanism.

First, look at the upgrade history of Deployment:

$kubectl rollout history deployment nginx-deploydeployments "nginx-deploy" REVISION CHANGE-CAUSE1 2 3 kubectl apply-filename=Desktop/nginx-deployment.yaml-record=true

From the above results, we can see that it is best to take the record parameter when performing a Deployment upgrade, so that we can view the historical version information. Similarly, we can use the following command to view the information of a single REVISION:

Kubectl rollout history deployment nginx-deploy-revision=3deployments "nginx-deploy" with revision # 3Pod Template: Labels: app=nginx pod-template-hash=3297445372 Annotations: kubernetes.io/change-cause=kubectl apply-- filename=nginx-deployment.yaml-- record=true Containers: nginx: Image: nginx:1.13.3 Port: 80/TCP Environment: Mounts: Volumes:

If you want to go back directly to the previous version of the current version now:

$kubectl rollout undo deployment nginx-deploydeployment "nginx-deploy" rolled back

Of course, you can also use revision to roll back to the specified version:

$kubectl rollout undo deployment nginx-deploy-to-revision=2deployment "nginx-deploy" rolled back

Now you can use the command to see the current status of Deployment.

Pay attention to the clearing mechanism

After scrolling the upgrade of Deployment with the apply command, I inadvertently found a lot of RS with Pods 0 Pods 0 under Replica Sets in Dashboard. Because I had a slight obsessive-compulsive disorder, I couldn't tolerate this kind of thing in my eyes, and then I deleted it. As a result, when I updated it later, I thought it was a mistake in the yaml script. Only now do I know that this is used for Deployment rollback. You can't delete it casually (feel like a gavel).

By default, Kubernetes will generate a new RS for each change to the Deployments and save it. However, you can set the parameter .spec.revisonHistoryLimit to specify the maximum number of revision history that Deployment retains. Fallback is not allowed if this item is set to 0. Field deployment.

The above is how to use Deployment to achieve rolling upgrade in Kubernetes. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.