Rolling Deployment

Kubernetes promises zero downtime and one of the reasons behind it is Rolling Deployments. With Rolling Deployments, Kubernetes makes sure that the traffic to the pods are not interrupted when updated pods are being deployed.


It only triggers if we change anything in pod definitions

We can specify min readiness time to specify the time needed to up and run the service

we can also specify how many max unavailable pod whiling rolling if we specify maxunavailable=5 then it will make a batch of 5 while rolling, it will down 5 pods from old rs and create new 5 pods in new rs

Note: If we don't specify max unavailable then it takes 25% by default

max surge is an optional field that specifies the maximum number of Pods that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a percentage of desired Pods (for example, 10%). The value cannot be 0 if MaxUnavailable is 0. The absolute number is calculated from the percentage by rounding up. The default value is 25%

to create a roll out use the below YAML file

vim rollout.yaml

apiVersion: apps/v1
kind: Deployment
  name: firstdeploy
    name: firstdeploy
     replicas: 10
	 minReadySeconds: 30
	    maxSurge: 0
		maxUnavailable: 1
	      app: myapp
	      name: dpod
		    app: myapp
			 - name: container
			   image: coolgourav147/nginx-custom:v2

now roll out will trigger as we changed the image from v1 to v2 from our last deployment


Kubernetes makes it easy to control the Deployment of our applications with these strategies. This was just a rundown of how Rolling and Rollback Update Deployments work from a ground level. In real-life, we rarely do all these steps manually, since we hand it down to our CI/CD pipeline