Rolling Updates in Kubernetes Deployment

Lets start understanding what is Deployment in Kubernetes?

The main role of deployment is to provide declarative updates to both the pod and the replicasets. With Deployments you can roll updates to your existing cluster without any downtime. Deployment is always in conjunction with replica sets. Which maintain the desired number of counts for the pods. If one of the pods fails, Replica Sets creates a new one. Below are some of the key features of deployment:

  • 📦 Easily deploy a Replica Sets
  • 🔄 Update Pods
  • ⏪ Rollback to previous deployment versions
  • 📈 Scale Deployment
  • ⏸️ Pause and resume deployment
Blog images

Deployment strategies

Deployment strategies are used to replace old pods by new ones.

Rolling update:

Pods are updated in a rolling fashion. This is defined by setting.spec.strategy.type to RollingUpdate. We can set maxUnavailable and maxSurge but, by default, it makes sure that only 25 percent of your pods are unavailable so we don't have to change it if it's not necessary.

So, in layman words, the Rolling Update is used to create a new pod with new updates and then delete the old pod one at a time, so there is no downtime in our application.

Now let's get our hands dirty with a practical to Rolling Updates in K8s cluster

Here we are using an example of nginx image in a pod. We would first deploy a pod with older image, and then we would update the pod with new image with rolling updates.

You can create a deployment using Imperative and Declarative way:

1 Declarative Way

By defining into a YAML file We would create a nginx-deployment.yaml file and add the contents below 

                    
                    apiVersion: apps/v1
                    kind: Deployment
                    metadata:
                    name: nginx-deployment
                    labels:
                        app: nginx
                    spec:
                    replicas: 10
                    selector:
                        matchLabels:
                        app: nginx
                    template:
                        metadata:
                        labels:
                            app: nginx
                        spec:
                        containers:
                        - name: nginx
                            image: nginx:1.14.2
                            ports:
                            - containerPort: 80

2 Imperative Way: Using Commands

Note: You cannot add replicas in the imperative way, you can create a deployment and scale it or you can output the command into .yaml file and edit it manually. We would discuss both the ways. 

            
                # Creating Deployment with 1 Replica
                kubectl create deployment --image=nginx:1.14.2 nginx-deployment
                
                # Scaling it to 10 Replicas
                kubectl scale deployment nginx-deployment --replicas=10
                
                # Verifying Deployment
                kubectl describe deployment nginx-deployment
                
                # Scaling Down to 1 Replica
                kubectl scale deployment nginx-deployment --replicas=1
                
                # Editing via YAML File
                apiVersion: apps/v1
                kind: Deployment
                metadata:
                    name: nginx-deployment
                    labels:
                    app: nginx
                spec:
                    replicas: 1
                    selector:
                    matchLabels:
                        app: nginx
                    template:
                    metadata:
                        labels:
                        app: nginx
                    spec:
                        containers:
                        - name: nginx
                        image: nginx:1.14.2
                        ports:
                        - containerPort: 80

Now let us start the rolling update

We would change the nginx version 1.14.2 to 1.19. Hence, we are rolling from older to newer version. By default the RollingUpdateStrategy is 25% max unavailable, 25% maxsurge.

Hence the pod with newer specifications is created first, than the older pod is evicted, this process is done one by one without downtime.

We would edit the deployment and change the image version to 1.19. 

                    
                        # Edit the Deployment to Update Image
                        kubectl edit deployment nginx-deployment

                        # Change the nginx image version to:
                        image: nginx:1.19

                        # Check the rolling update progress
                        kubectl rollout status deployment nginx-deployment

                        # View rollout history & revision details
                        kubectl rollout history deployment nginx-deployment

                        # Rollback to the previous deployment
                        kubectl rollout undo deployment nginx-deployment

                        # Verify rollback in the deployment file
                        kubectl edit deployment nginx-deployment

Deleting Deployment

Use the command below to delete a Kubernetes Deployment, removing all associated pods and replicasets. 

                    
                        # Delete Deployment
                        kubectl delete deployment nginx-deployment