AutoHealing using Kubernetes Deployment

Before we jumped into practical session firstly we need to understand about kubernetes deployments, ReplicaSets.

Replication Controller

• A single pod may not be sufficient to handle the user traffic. Also if this only pod goes down because of a failure, K8s will not bring this pod up again automatically

• In order to prevent this, we would like to have more than one instance or POD running at the same time inside the cluster

• Kubernetes supports different controllers(Replicacontroller & ReplicaSet) to handle multiple instances of a pod. Ex: 3 replicas of nginx webserver

• Replication Controller ensures high availability by replacing the unhealthy/dead pods with a new one to ensure required replicas are always running inside a cluster

• So, does that mean you can’t use a replication controller if you plan to have a single POD?

No! Even if you have a single POD, the replication controller can help by automatically bringing up a new POD when the existing one fails.

• Another reason we need replication controller is to create multiple PODs to share the load across them.

• Replica controller is deprecated and replaced by Replicaset.

ReplicaSets are a higher-level API that gives the ability to easily run multiple instances of a given pod

• ReplicaSets ensures that the exact number of pods(replicas) are always running in the cluster by replacing any failed pods with new ones

• The replica count is controlled by the replicas field in the resource definition file

• Replicaset uses set-based selectors whereas replicacontroller uses equality based selectors

Deployment

• A Deployment provides declarative updates for Pods and ReplicaSets.

• You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.

• It seems similar to ReplicaSets but with advanced functions

• Deployment is the recommended way to deploy a pod or RS

• By default Kubernetes performs deployments in rolling update strategy.

• Below are some of the key features of deployment:

✓ Easily deploy a RS

✓ Rolling updates pods

✓ Rollback to previous deployment versions

✓ Scale deployment

✓ Pause and resume deployment

Deployment Strategy

• Whenever we create a new deployment, K8s triggers a Rollout.

• Rollout is the process of gradually deploying or upgrading your application containers.

• For every rollout/upgrade, a version history will be created, which helps in rolling back to the working version in case of an update failure

• In Kubernetes there are a few different ways to release updates to an application

• Recreate: terminate the old version and release the new one. Application experiences downtime.

• RollingUpdate: Release a new version in a rolling update fashion, one after the other. It’s the default strategy in K8s. No application downtime is required.

• Blue/green: Release a new version alongside the old version then switch traffic

Now, we will learn how to write a YAML manifest file for deployments and how we can wrap our pods into deployments.

Firstly, we need to install the Minikube Cluster and start it. To install minikube cluster you can refer to my blog:

ketangrover.hashnode.dev/kubectl-and-miniku..

Now, we will start the cluster:

minikube start

When we create a pod on minikube cluster and after that, we delete it accidentally or because of some network issue, our pod gets deleted. Now, if someone trying to access our application will not be able to use it as we can't recover the pod but by using deployment we enhance the feature of Autohealing and as soon as we delete a pod, deployment will immediately create a new pod with a different IP address and our application will start running on that pod.

Deployments are just a YAML file in which we write the whole requirement like pods and ReplicaSets information and some basic parameters. So, after starting our cluster we will create a new file deployment.yml.

vim deployment.yml

write the code inside your deployment.yml

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

Here in this file, we have described some parameters according to our needs like apiVersion, kind, name and container information which describes the container image in our case we are using nginx and using container port 80.

Also, we have given them some labels because if our pods got deleted and recovered a new IP address will be given to them and by using labels it will deploy the same application were using before.

Now to run your deployment use the command:

kubectl apply -f deployment.yml

Check if your deployment is created or not:

kubectl get deployments

Then check for pods:

kubectl get pods -o wide

Now try to delete a pod using the command and you will see even after the deletion of the pod, a new pod will be created but with a different IP address but with the help of labels users can still access the application.

The main working of Kubernetes Deployments is that it will create ReplicaSets which will keep track of Kubernetes pods and as soon as a pod gets deleted it will autoheal it by creating a new pod with a different IP Address.

That's a wrap............