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

This article shows you how to use Deloyment to achieve scrolling updates 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.

Introduction to rolling updates

When a service in the kubernetes cluster needs to be upgraded, the traditional practice is to offline the updated service first, then update the version and configuration after the business stops, and then restart and provide the service. If the business cluster is large, this work becomes a challenge, and stopping it all first, and then gradually upgrading the service will cause the service to be unavailable for a long time. Kubernetes provides a way of rolling updates (rolling-update) to solve the above problems.

To put it simply, rolling update is an uninterrupted update and upgrade method for multi-instance services. In general, for multi-instance services, rolling updates are done individually for each instance instead of updating all instances at the same time.

For K8s cluster, rolling update refers to updating only one or a group of pod at a time, rather than managing all pod shutdown managed by one Deployment at the same time to avoid business interruption.

The new version of Kubernetes recommends Deployment instead of ReplicationController, and under the concept of Deployment, it is the hidden Replica Set that actually plays a role in maintaining the number of Pod copies.

Update RC with kubectl rolling-update

The way to use the kubectl rolling-update command is mainly for pods created with RC.

Let's take a look at the following example to create a RC nginx-demo-v1-rc.yml with 4 copies of nginx:

ApiVersion: v1kind: ReplicationControllermetadata: name: nginx-demo-v1spec: replicas: 4 selector: app: nginx-demo ver: V1 template: metadata: labels: app: nginx-demo ver: v1spec: containers:-name: nginx-demo image: nginx:1.14 ports:-containerPort: 80 protocol: TCP env: -name: NGX_DEMO_VER value: v1

Create a service,nginx-demo-svc.yml as follows:

ApiVersion: v1kind: Servicemetadata: name: nginx-demo-svcspec: ports:-port: 80 protocol: TCP selector: app: nginx-demo

Create rc and service:

Kubectl create-f nginx-demo-v1-rc.ymlkubectl create-f nginx-demo-svc.yml

After the creation is completed, you can view the value of NGX_DEMO_VER by accessing the environment variable of any Pod, which is v1

Now let's create a nginx-demo-v2-rc.yml file to upgrade the existing pod:

ApiVersion: v1kind: ReplicationControllermetadata: name: nginx-demo-v2spec: replicas: 4 selector: app: nginx-demo ver: v2 template: metadata: labels: app: nginx-demo ver: v2spec: containers:-name: nginx-demo image: nginx:1.15 ports:-containerPort: 80 protocol: TCP env: -name: NGX_DEMO_VER value: v2

Perform an update operation:

Kubectl rolling-update nginx-demo-svc-f nginx-demo-v2-rc.yml

It is important to note that when performing a rolling upgrade, the two versions of the yml file differ:

The name of RC cannot be the same as the old RC name

At least one label in the selector should be different from the label of the old RC to identify it as the new RC.

We can view the complete process of the update by doing the following:

Kubectl rolling-update nginx-demo-v1-- udpate-period=10s-f nginx-demo-v2-rc.yml

When all the old pod is replaced by the new Pod, the update is complete.

Shortcomings of using kubectl rolling-update to implement scrolling updates:

The logic of rolling-update is completed by kubectl issuing N commands to APIServer, which is likely to cause update interruption due to network reasons.

A new rc needs to be created. The name cannot be the same as the rc to be updated.

Rollback also requires rolling-update, just replacing the new version with the old version

The rolling-update executed by service is not recorded in the cluster, and the rolling-update history cannot be tracked later.

Today, the RC approach has been replaced by Deployment.

Rolling-update of Deployment

Kubernetes's Deployment is a higher level of abstraction. Deployment creates a Replica Set to guarantee the number of copies of the Pod in the Deployment. To Pod in rolling-update deployment, you just need to modify Deployment's own yml file and apply it. This modification creates a new Replica Set that increases the number of pod of the new RS and reduces the pod of the old RS until it is fully upgraded. All this happens on the server side and does not require the participation of kubectl.

Create a Deployment yml file, nginx-demo-dm.yml:

ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: nginx-demospec: replicas: 4 selector: matchLabels: app: nginx-demo minReadySeconds: 10 template: metadata: labels: app: nginx-demo version: v1 spec: containers:-name: deployment-demo image: nginx:1.14 ports:-containerPort: 80 protocol: TCP

Create the deployment:

Kubect create-f nginx-demo-dm.yml-- record

Then we can modify the deployment file directly, as follows:

ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: nginx-demospec: replicas: 4 selector: matchLabels: app: nginx-demo minReadySeconds: 10 template: metadata: labels: app: nginx-demo version: v2 spec: containers:-name: deployment-demo image: nginx:1.15 ports:-containerPort: 80 protocol: TCP

A total of two changes have been made. Change the version to v2 and the nginx image from 1.14 to 1.15. Perform the following operations to apply the changes:

Kubectl apply-f nginx-demo-dm.yml-- record

At this point, we can check the changes in rs by executing kubectl get rs to confirm whether the upgrade is being performed. You can also view the detailed rolling-update process through kubectl describe deployment nginx-demo. You can also view the update status through kubectl rollout status deployment/nginx-demo.

In addition to using apply to apply changes, there is another way to upgrade directly. Is to edit the deployment file through kubectl edit nginx-demo-dm.yml, after saving, do not need to execute apply, will automatically complete the upgrade.

We can notice that when performing the deployment operation, we used a-- record parameter, which is used to tell apiserver to record the history of the update. You can view the update history with the following command:

Kubectl rollout history deployment nginx-demo

View the details of the specified revision:

Kubectl rollout history deployment hello-deployment-revision=2

It is important to note that after the upgrade is completed, the old RS will not be deleted, and this information will be stored on the server side to facilitate rollback.

The rollback operation of pod under deployment is quite simple. You can directly execute rollout undo to roll back deployment to the last revision recorded in record:

Kubectl rollout undo deployment nginx-demo

Roll back to the specified version by doing the following:

Kubectl rollout undo deployment hello-deployment-to-revision=2 the above is how to use Deloyment to implement scrolling updates 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.