Kubernetes: Rolling Update example

Rolling update is the default deployment strategy in Kubernetes. In this strategy, instead of deleting all the Pods in one shot, we take down one pod at a time. Once a Pod is deleted, a newer Pod with the Specified image gets created. It is the default deployment strategy in Kubernetes.

 

You can configure a deployment strategy by specifying ‘strategy’ property.

 

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 2

      maxUnavailable: 1

 

maxUnavailble: It specifies the maximum number of Pods that can be upgraded at the same time.

 

maxSurge: It specifies the maximum number of Pods that can go beyond the desired number of Pods specified in the replica to achieve minimal availability

 

Step 1: Create a deployment definition file.

 

rollingUpdate.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: domain-service-deployment
  labels:
    app: domain-service-deployment
    author: krishna
    serviceType: webservice
spec:
  template:
    metadata:
      name: domain-service
      labels:
        app: domain-service
        author: krishna
        serviceType: webservice
    spec:
      containers:
      - name: domain-service-container
        image: jboss/wildfly

  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  selector:
    matchLabels:
      app: domain-service

Step 2: Create a deployment using the above definition file.

$kubectl create -f rollingUpdate.yml 
deployment.apps/domain-service-deployment created

Query all the deployments.

$kubectl get deployments
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
domain-service-deployment   5/5     5            5           51s

Step 3: Check the rollout history of the deployment.

$kubectl rollout history deployment domain-service-deployment
deployment.apps/domain-service-deployment 
REVISION  CHANGE-CAUSE
1         <none>

As you see the output, revision 1 is created.

 

Step 4: let's update the deployment by changing the replicas to 3.

 

Execute the below command to edit the deployment.

kubectl edit deployment domain-service-deployment

 

Update the replicas to 3 (For your information, vi editor commands will work here).

$kubectl edit deployment domain-service-deployment
deployment.apps/domain-service-deployment edited

$kubectl rollout history deployment domain-service-deployment
deployment.apps/domain-service-deployment 
REVISION  CHANGE-CAUSE
1         <none>

As you see no new revision is created. Replicas update do not create any new revision.

 

But, when you update the image, it will create new revision.

 

Let’s update the image of jboss/wildfly to below one.

jboss/wildfly:19.1.0.Final

$kubectl edit deployment domain-service-deployment
deployment.apps/domain-service-deployment edited

Now after applying the new image version, you can observe that new Revision entry gets created.

$kubectl rollout history deployment domain-service-deployment
deployment.apps/domain-service-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

You can get what is happened in a revision by executing below command.

 

kubectl rollout history deployment domain-service-deployment --revision=2

$kubectl rollout history deployment domain-service-deployment --revision=2
deployment.apps/domain-service-deployment with revision #2
Pod Template:
  Labels:	app=domain-service
	author=krishna
	pod-template-hash=59b87b89d
	serviceType=webservice
  Containers:
   domain-service-container:
    Image:	jboss/wildfly:19.1.0.Final
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

Whenever a new revision created, deployment creates new replicaset to take care of the deployment.

$kubectl get replicaset
NAME                                   DESIRED   CURRENT   READY   AGE
domain-service-deployment-59b87b89d    3         3         3       4m3s
domain-service-deployment-6d8455f97c   0         0         0       13m

You can use -o wide option to know, which image is handled by replicaset.

$kubectl get replicaset -o wide
NAME                                   DESIRED   CURRENT   READY   AGE     CONTAINERS                 IMAGES                       SELECTOR
domain-service-deployment-59b87b89d    3         3         3       4m54s   domain-service-container   jboss/wildfly:19.1.0.Final   app=domain-service,pod-template-hash=59b87b89d
domain-service-deployment-6d8455f97c   0         0         0       14m     domain-service-container   jboss/wildfly                app=domain-service,pod-template-hash=6d8455f97c

You can go to previous history by executing undo command.

$kubectl rollout undo deployment domain-service-deployment
deployment.apps/domain-service-deployment rolled back

You can confirm the undo by querying replicaset.

$kubectl get replicaset -o wide
NAME                                   DESIRED   CURRENT   READY   AGE     CONTAINERS                 IMAGES                       SELECTOR
domain-service-deployment-59b87b89d    0         0         0       6m31s   domain-service-container   jboss/wildfly:19.1.0.Final   app=domain-service,pod-template-hash=59b87b89d
domain-service-deployment-6d8455f97c   3         3         2       16m     domain-service-container   jboss/wildfly                app=domain-service,pod-template-hash=6d8455f97c

You can even go to specific revision by specifying --to-revision option.

$kubectl rollout undo deployment domain-service-deployment --to-revision=2
deployment.apps/domain-service-deployment rolled back

$kubectl get replicaset -o wide
NAME                                   DESIRED   CURRENT   READY   AGE     CONTAINERS                 IMAGES                       SELECTOR
domain-service-deployment-59b87b89d    3         3         3       7m57s   domain-service-container   jboss/wildfly:19.1.0.Final   app=domain-service,pod-template-hash=59b87b89d
domain-service-deployment-6d8455f97c   0         0         0       17m     domain-service-container   jboss/wildfly                app=domain-service,pod-template-hash=6d8455f97c

These undos and upgrades will create new revisions.

$kubectl rollout history deployment domain-service-deployment
deployment.apps/domain-service-deployment 
REVISION  CHANGE-CAUSE
3         <none>
4         <none>

Previous                                                    Next                                                    Home