Updating applications running on Kubernetes, even though can be done easily with kubernetes manifests or any other tools, it is difficult to do it without shutting down the pods or having some downtime.
This is where rolling upgrades come into play by helping us with seamless transitions to new application versions without downtime.
A rolling upgrade is a deployment strategy that gradually replaces the old pods (containers) of an application with new ones. Unlike blue-green deployments, which involve switching between entirely different versions of the application, rolling upgrades minimize disruption by incrementally updating pods. This approach ensures that the application remains available throughout the update process, providing a smooth user experience.
When a Deployment manifest is updated, the controller identifies the desired state of the application, including the number of pods and their desired container image. The controller then compares the current state to the desired state and starts replacing old pods with new ones.
Example:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-application
spec:
replicas: 3 # Desired number of pods
selector:
matchLabels:
app: my-application
strategy:
rollingUpdate:
maxUnavailable: 1 # Allow up to one pod to be unavailable during the upgrade
maxSurge: 1 # Allow up to one additional pod to run during the upgrade
template:
metadata:
labels:
app: my-application
spec:
containers:
- name: my-container
image: nginx:latest # Updated container image
ports:
- containerPort: 80
The maxUnavailable and maxSurge parameters ensure that the application remains available throughout the upgrade process by limiting the number of pods that can be unavailable or running simultaneously.
This way rolling upgrades can help us in reduced downtime, smooth rollout of latest features or bugfixes.