Kubernetes rolling update strategy means suppose we are running pod (containers) in our live infra and we want to update new changes into our running pod like build update, confrontational changes etc. While deployment new pod with new changes suppose our containers got stuck or failed due to any reason.

1. LinuxDady.Com
Kubernetes rolling update strategy
for prod infra
For more information visit
https://linuxdady.com

2. Kubernetes Rolling Update
Strategy in our production infra
BY DEEPAK KUMAR · PUBLISHED SEPTEMBER 23, 2019 · UPDATED SEPTEMBER 23, 2019
Kubernetes rolling update strategy means suppose we are running pod
(containers) in our live infra and we want to update new changes into our
running pod like build update, confrontational changes etc. While deployment
new pod with new changes suppose our containers got stuck or failed due to
any reason.
So, we have to redeploy old pod with old changes again to avoid downtime of
our application. This complete process is called Kubernetes rolling update
strategy.
Kubernetes rolling update strategy
Before moving to next we should aware about new pod deployment strategy of
Kubernetes means how many new pods it will deploy at a time without taking
downtime. Because high availability of our website is our first priority. So, while
deploying new pod Kubernetes will deploy 25% or you can say one fourth of
the total pod. Suppose we are running four pods first it will terminate 25% of
total pod means one pod. Then it will launch 25% new pod and so on.
Advantage of rolling updates
▪ To maintain our application high availability during deployment.
▪ Save our time and manpower
▪ Easy to roll back if facing any issue
▪ Support versioning
▪ Recreate pod
[Click & Read:– Kubernetes deployments by yaml
file for beginner]
[Click & Read:– Pod deployment in kubernetes by command
line ]
Versioning in Kubernetes
I think you know very well about versioning means to store all changes for
backup purpose called versioning. Similarly, in Kubernetes we store our yaml
file old changes before new changes for backup point of view. Because in case
of any issue we will be able to deploy older version and our application will
become in upstate. So let’s enable versioning before deployment. But first make
nginx-deployment.yaml file first.

3. 1 vim nginx-deployment.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
1
2
3
kubectl create -f nginx-deployment.yaml --record=true
kubectl rollout history deployment nginx-deployment
kubectl get pod -o wide
nginx-deployment.yaml -::- This file is our confrontational file of
Kubernetes where all parameters are defines.
record=true -::- This option creates the latest version of nginx-deployment
before deployment new changes.
rollout history -::- To check the current version of our deployment.

4. Change new image instead of nginx
Note that still we are deploying containers from nginx image. Now we are going
to check we can roll back older version of our deployment if we got stuck
anywhere. So, for this purpose we have to make two version of nginx
deployment. Our first version will be with nginx image. For second version
change nginx image with new required image that we want to deploy. In my
case I am changing it with apache. So, open below file and change your older
image parameter with image: nginx:1.7.9 with new image:
docker.io/centos/httpd
1 vim nginx-deployment.yaml
1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:

5. 13
14
15
16
17
18
19
20
21
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: docker.io/centos/httpd
ports:
- containerPort: 80
Note in my case I have taken apache image in your case you can select
accordingly. After changing your desire image save the yaml file. After saving
this file let’s create version of this yaml.
1
2
kubectl apply -f nginx-deployment.yaml --record=true
kubectl rollout history deployment nginx-deployment
Now we have two version one for nginx and another for apache server.
If we will do deployment form version one, then it will reach into nginx image
state and if we will use version two it will reach into apache image state. So,
let’s take a scenario suppose now we are running nginx image and we want to
update it with apache and due to any reason, it got stuck. Then we will roll back
with older version nginx again from apache. So, check the pod life. In given
below fig. It is showing 15 minutes and still running our apache container now.
1 kubectl get pod

6. Kubernetes rolling update strategy and roll back to older version
Now we are going to roll back from version 2 to nginx version 1. So, Change
version accordingly in your case.
1
2
kubectl rollout undo deployment/nginx-deployment --to-revision=1
kubectl get pod -o wide
As we have checked our old version has been updated successfully and it’s show
“welcome to nginx” but before rollback it was showing “Apache HTTP Server
Test Page”. So, it’s all about Kubernetes rolling update. Now we will go through
some basic command that is useful in rolling update. Now check version
properly updated or not.
1 kubectl rollout status deployment nginx-deployment
1 kubectl rollout history deployment nginx-deployment
We can check all available version from above command. Output will be like
below.

7. 1
2
3
4
deployment.extensions/nginx-deployment
REVISION CHANGE-CAUSE
2 kubectl apply --filename=nginx-deployment.yaml --record=true
3 kubectl create --filename=nginx-deployment.yaml --record=true
Suppose we need full description of and version then below command will be
helpful.
1 kubectl rollout history deployment nginx-deployment --revision=3
Only change revision version = 3 accordingly in above command. Output will be
look like below.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
deployment.extensions/nginx-deployment with revision #3
Pod Template:
Labels: app=nginx
pod-template-hash=5754944d6c
Annotations: kubernetes.io/change-cause: kubectl create -
filename=nginx-deployment.yaml --record=true
Containers:
nginx:
Image: nginx:1.7.9
Port: 80/TCP
Host Port: 0/TCP
Environment: none
Mounts: none
Volumes: none
rs stand for replica status means we can check status and number of old replica
and new replica.
1 kubectl get rs

8. Watch the status of the rollout until it’s done.
1 kubectl get rs -w
All about Kubernetes Rolling Update Strategy
In this tutorial we have discussed about Kubernetes rolling update
strategy and its advantages for our infra. We have covered this topic because
this is daily routine task. So, if anyone still have any query write me in comment
box. I will try my best to resolve them.
My interview discussion in a company
I have faced recently an interview related to Kubernetes jobs. So, I thought I
should share all question and answer during that interview. If I am wrong in
any answer, please correct me in comment box.
How will you update the new changes in Kubernetes and what will be the
step?
MyAns. I told him first of all I will create new version of running deployment
for backup purpose. Then I will update new changes. So simple.
Then Interviewer again asked next question suppose you are updating changes
and your changes got stuck and due to that changes your application goes
down. Now what will be your step to recover that?
My Ans. I replied him sir my first priority will be to bring up our application
first anyhow. So first I will try to analyse logs and if find any issue into logs
related to any other teams like development, testing, security etc. Then I will
send logs to them. After sending logs I will roll back last version.
Again, Interviewer ask me a question suppose Deepak again your older version
got stuck. Now what will be your approach?
My Ans.. I replied him sir first of all I will again analyse logs. If into logs
everything is looking fine. Might be we do not have proper backup of our old
version.
Again, Interviewer ask me ok Deepak we don’t have proper backup. Now what
will be next approach because our application is not up still?
My Ans. I have replied Sir there is an alternate way we can use manually means
by command mode instead of yaml file.

9. Again, Interviewer ask me Deepak all team replied everything is ok from our
end. Then what will be possible reason of failure.
My Ans. From our end this can occur due to some of the following reason
▪ Insufficient quota
▪ Readiness probe failures
▪ Image pull errors
▪ Insufficient permissions
▪ Limit ranges
▪ Application runtime misconfiguratio