Users expect applications to be available all the time, and developers need to deploy new versions of them multiple times a day. In Kubernetes, this is accomplished with Rolling Updates. Rolling updates allow Pod instances to be updated incrementally by using new instances. Deployment updates are performed with zero downtime.

Kubernetes Rolling Update Basic Concepts

Concepts

When a service in a cluster needs to be updated, the traditional approach is to take the service to be updated offline, update the version and configuration after the business is stopped, and then restart and provision the service. An obvious problem with this approach is that it causes the service to be unavailable for a longer period of time and creates a tremendous amount of work in large-scale service scenarios.

Rolling updates are a way to update multiple-instance services without interrupting them. In general, for multi-instance services, rolling updates are performed individually for each instance rather than for all instances at the same time.

For kubernetes clustered services, rolling update means updating one pod at a time and updating them one by one, instead of stopping all the pods under the service at the same time and then updating them to the new version and then bringing them all online. The rolling update method can avoid business interruption.

Features

Advantages.

  • No business interruption, less user experience impact, smoother
  • More resource efficient compared to blue-green deployment - it doesn’t need to run two clusters, twice the number of instances

Rolling update is not a silver bullet either, there are many issues that need to be taken into account, for example: Because it is a gradual update, then we will briefly have inconsistencies between the old and new versions when we go live with the code, and if there are scenarios with high requirements for going live, then we need to consider how to do a good job of compatibility.

K8S Deployment-based Rolling Update

kubernetes Deployment is a higher level abstraction than the earlier Replication Controller and now Replica Set. deployment creates a Replica Set that keeps the number of replicas of Pods in the deployment. To rolling-update the Pods in a deployment, simply modify the Deployment’s own yml file and apply it. This modification creates a new Replica Set that increases the number of pods in this new RS while decreasing the pods in the old RS until it is fully upgraded. All of this happens on the Server side and does not require kubectl involvement.

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deploy
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx-deploy
        version: v1
    spec:
      containers:
        - name: nginx-deploy
          image: nginx:1.10.1
          ports:
            - containerPort: 80
              protocol: TCP

Create the deployment.

1

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

Modify the YAML file of the deployment directly. Modify it to the target version configuration as follows.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deploy
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx-deploy
        version: v2
    spec:
      containers:
        - name: nginx-deploy
          image: nginx:1.11.9
          ports:
            - containerPort: 80
              protocol: TCP

Modified one of the labels, modified the tag of the image, and then executed it.

1

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

Yes, there is no need for the Replication Controller-era rolling-update form like kubectl rolling-update [SVC] -f [TARGET-RC]. Just do the usual apply -f. The only difference is that you need to add a --record, for the obvious purpose of rolling back.

At this point you can see the Deployment specific rolling update process.

1

kubectl describe deployment nginx-demo

Since the update history is recorded with --record, it can be viewed with the kubectl rollout history command.

1

kubectl rollout history deployment nginx-demo

Rollback

If you need to roll back to a previous version.

1

kubectl rollout undo deployment nginx-demo

Rollback to the specified version.

1

kubectl rollout undo deployment xxx-deployment --to-version=2