Kubernetes Deployment Strategies: Recreate vs. RollingUpdate

INTRODUCTION

There are a variety of techniques to deploy new applications to production, so choosing the right strategy is an important decision. Two prominent strategies — Recreate and RollingUpdate — stand out, each with its unique approach to updating applications seamlessly. Let’s embark on a journey to unravel the nuances of these strategies.

What is Deployment strategies ?

Deployment strategies are techniques for updating applications running in Kubernetes clusters. These strategies define how the transition from the current version of an application to a new one is managed. Each strategy has its own set of rules, trade-offs, and implications, allowing developers to tailor their approach based on specific requirements.

Understanding Recreate Strategy

The Recreate strategy takes a straightforward approach to updates. The recreate strategy is a dummy deployment which consists of shutting down version A then deploying version B after version A is turned off.

This brief moment of downtime during the transition allows the updated version to take its place. While this approach is pragmatic for applications where a momentary pause is tolerable, it may not be suitable for those requiring continuous availability.

For Recreate Strategy, the code will be same as creating a normal deployment, just change the version with newer version of app.

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: Mydeploy1

spec:
  replicas: 3
  selector:
    matchLabels:
      region: india
  template:
    metadata:
      labels:
        team: dev
    spec:
      containers:
      - name: my-container
        image: <registry>/<myapp>:<version>

Command for creating the Deployment with Recreate strategy will be:

kubectl create deployment mydeploy1 --image=<image-name> --replicas=3
kubectl apply -f <filename.yml>

RollingUpdate Strategy

Users expect applications to be available all the time, and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. A rolling update allows a Deployment update to take place with zero downtime.

This strategy ensures a smooth and continuous transition, mitigating downtime by maintaining a specified number of healthy instances throughout the update process.

The YAML code for applying the deployment with recreate strategy :

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: mydeploy-1

spec:
  replicas: 3
  selector: 
    matchLabels:
      region: india
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        team: dev
    spec:
      containers:
      - name: my-container
        image: <registry>/<myapp>:<new-version>

For updating or rolling out the deployment we can also use the command set image with our new version of app.

kubectl set image deployment mydeploy-1 my-container=<registry>/<myapp>:<new-version>

To check the status of our current rollout :

kubectl rollout status deployment mydeploy-1

To check the total number of rollout we have done till that time.

kubectl rollout history deployment mydeploy-1

In case we feel that we have to go back to the previous version of our app, then we can also do “Rollback” to any previous deployment since kubernetes maintain the list of the history of our deployment updates in “Revision”.

Command:

kubectl rollout undo deployment mydeploy-1 --to-revision=<revision-number>