Effective Deployment Strategies in Kubernetes

Introduction

Deployment strategies are part of Deployments, which helps scale the application efficiently without downtime. We can also revert to the previous application version with the help of deployments. And ReplicaSet helps in maintaining the desired replicas of applications.

Pioneers in Cloud Consulting & Migration Services

Reduced infrastructural costs
Accelerated application deployment

Get Started

What is ReplicaSet?

A ReplicaSet is a Kubernetes object that manages a group of pods. It ensures that the number of pods in the group always matches the desired number.

This helps to prevent applications from becoming unavailable if a pod fails. Whenever any pod gets failed, the replica set immediately launches another pod and replaces it with the failed pod.

replica

Image Source: https://blog.devgenius.io/k8s-controller-replicaset-e6e0f29312f1

Features of Replica Set

A pod template is used to create a new pod whenever an existing pod fails, and the replica count is maintained by defining the desired number of replicas a controller needs to be running.
A replica set also ensures that an additional pod needs to be created or deleted whenever an instance with the same label is created.
The replica set allows multiple pod replicas, which means the traffic is sent to different instances, preventing overloading a single instance.
The replica set ensures it has multiple replicas of the application so that it won’t fail because of one pod fails.

ReplicaSet Manifest

Below is the YAML file, which will create multi replicas of the pod.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: httpd-replica
  namespace: facebook
spec:
  replicas: 4
  minReadySeconds: 10
  selector:
    matchLabels:
      role: web
    matchExpressions:
      - {key: version, operator: In, values: [v1, v2, v3]}
  template:
    metadata:
      name: web
      labels:
        role: web
        version: v1
        tier: frond
    spec:
      containers:
      - name: web
        image: httpd
        ports:
        - containerPort: 80
          protocol: TCP

apiVersion: apps/v1

kind: ReplicaSet

metadata:

namespace: facebook

spec:

replicas: 4

minReadySeconds: 10

selector:

matchLabels:

role: web

matchExpressions:

- {key: version, operator: In, values: [v1, v2, v3]}

template:

metadata:

labels:

role: web

version: v1

tier: frond

spec:

containers:

- name: web

image: httpd

ports:

- containerPort: 80

protocol: TCP

Fields that are used to define replicas are as follows:

Selector:It is used to identify for which pod the replica set is responsible.
Replicas:It specifies the number of pods the replica set must maintain.
Template:It defines the pod template replica set that will use to create new pods.
ApiVersion:It defines Kubernetes API that supports ReplicaSet.

What is Deployment and its strategies?

Deployment is used to maintain the versions of your application running in the pod. It helps to scale the number of replica pods efficiently and enables the rollout and rollback to an earlier deployment version. Deployment runs on multiple replicas of the pod and automatically replaces a pod in case of any failure or unresponsiveness. Deployments are Kubernetes object that helps to keep your application running. They do this by creating and managing Pods, the basic deployment units in Kubernetes.

A Deployment uses a Pod template to define the desired state of its Pods. The Pod template specifies the containers that should run in each Pod, the volumes that should be mounted, and the labels that should be applied. When a Deployment’s Pod template changes, new Pods are automatically created one at a time.

replica2

Image Source: https://scoutapm.com/blog/kubernetes-uses-and-introduction

What are Rolling Updates and Recreate Strategies in Deployments?

The rolling update provides an orderly migration from one version to a newer version. The rolling update is used in such situations when a new version of an application comes, and you have to switch to a newer version. In the rolling update, all the running pods will be replaced with the newer application version by systematically terminating the older version of the application pods.

A recreate deployment strategy is an all-or-nothing process that lets you update an application immediately, with some downtime. With this strategy, existing pods from the deployment are terminated and replaced with a new version. This means the application experiences downtime from the time the old version goes down until the new pods start successfully and start serving user requests.

Deployment with ReplicaSet

Deployments are generally used with the replicaset as they are used to manage replicsets. With the help of deployment, you can roll back to a previous Deployment revision. You have the option to utilize a Deployment while managing a ReplicaSet. With a Deployment, you can generate a fresh version of a ReplicaSet and transfer the current pods from an older version to the new one. Subsequently, the Deployment is capable of removing outdated and unused ReplicaSets.

So, Replicaset ensures replicas of pods are available, whereas deployment is responsible for managing different versions of the application. For deployment, the replica set can’t rollout or rollback to different application versions nor maintain any revisions.

Deployment Manifest with strategy

Below is the yaml file for Deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: facebook
spec:
  strategy:
    type: RollingUpdate #Bydefault (RollingUpdate/Recreate)
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  revisionHistoryLimit: 10
  paused: false
  replicas: 3
  minReadySeconds: 10
  selector:
    matchLabels:
      role: webserver
      jane: akil
    matchExpressions:
      - {key: version, operator: In, values: [v1, v2, v3]}
  template:
    metadata:
      name: web
      labels:
        role: webserver
        version: v3
        tier: frond
        jane: akil
    spec:
      containers:
      - name: web
        image: nginx:1.20-perl
        ports:
        - containerPort: 80
          protocol: TCP

apiVersion: apps/v1

kind: Deployment

metadata:

namespace: facebook

spec:

strategy:

type: RollingUpdate #Bydefault (RollingUpdate/Recreate)

rollingUpdate:

maxSurge: 2

maxUnavailable: 1

revisionHistoryLimit: 10

paused: false

replicas: 3

minReadySeconds: 10

selector:

matchLabels:

role: webserver

jane: akil

matchExpressions:

- {key: version, operator: In, values: [v1, v2, v3]}

template:

metadata:

labels:

role: webserver

version: v3

tier: frond

jane: akil

spec:

containers:

- name: web

image: nginx:1.20-perl

ports:

- containerPort: 80

protocol: TCP

Key elements of the above YAML file:

We are creating a deployment type file Strategy which means if any changes are there, it will apply them.
The Rolling Update will check if the container serves any request. After the request is served, it will apply the changes.
A revision history limit means several changes that can perform. It will keep track of all revisions in the form of revisions.
MaxSurge means whenever a revision is applied, it will create a specified number of containers according to the values given it will apply it to the pod.

Conclusion

Deployments and ReplicaSet are an important component of Kubernetes, which helps you not only deploy your application but also helps manage replicas of your pods. And with deployments, you can perform rolling updates and maintain different versions of your application.

Making IT Networks Enterprise-ready – Cloud Management Services

Accelerated cloud migration
End-to-end view of the cloud environment

Get Started

About CloudThat

CloudThat is a leading provider of Cloud Training and Consulting services with a global presence in India, the USA, Asia, Europe, and Africa. Specializing in AWS, Microsoft Azure, GCP, VMware, Databricks, and more, the company serves mid-market and enterprise clients, offering comprehensive expertise in Cloud Migration, Data Platforms, DevOps, IoT, AI/ML, and more.

FAQs

1. What is the major difference between ReplicaSet and Deployment?

ANS: – While a ReplicaSet guarantees the presence of a designated count of pod replicas, a Deployment operates at a higher level and oversees ReplicaSets while offering declarative updates to Pods and various other beneficial functionalities.

2. What is the major difference between ReplicationController and Deployment?

ANS: – The recommended approach for replication now involves utilizing a Deployment to configure a ReplicaSet. A ReplicationController maintains a designated number of pod replicas, ensuring constant pod availability or a homogeneous group of pods.