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.
RollOut
- 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
metadata:
name: firstdeploy
labels:
name: firstdeploy
spec:
replicas: 10
minReadySeconds: 30
stratergy:
rollingupdate:
maxSurge: 0
maxUnavailable: 1
selector:
matchlabels:
app: myapp
template:
metadata
name: dpod
labels:
app: myapp
spec:
containers:
- 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
Conclusion
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