Launching your Kubernetes Cluster with Deployment[Day 31-Task]

1. What Is K8s Deployment?

Kubernetes has auto-scaling and auto-healing features which is why it is so a famous orchestration tool nowadays. This means if you delete a pod accidentally or if a pod gets crashed for any reason it will recreate automatically within a second, this feature is called auto-healing, and this will make sure that your application won't face any downtime.

If your application gets a high load due to the number of users increasing or any other reasons, the number of pods will be increased automatically to distribute the load among them, this feature is known as the auto-scaling feature.

Both can be possible with the help of the Deployment object of k8s.

This Deployment object will make sure that in any situation current state should match the desired state that means if any pod gets deleted automatically it will create to make the desired state equal to the current state. But the deployment object doesn't do it directly, it does it with the help of Replica Set[A pod Controller].

In the Replica set, we mention that number that should maintain the current state and desired state concept and also the auto-scaling feature, if loads increase the number of pods also gets increased[as replica means a copy of something]. Inside a deployment yaml file, we mention the replica set number.

We Keep Deployment on top of pods, declare the desired state, and allow the deployment controller to automatically reach that end goal most efficiently. A deployment allows us to describe an application's life cycle, such as which images to use for the app, the number of pods there should be, and how they should be updated.

The difference between Replicaset and Deployment is that A ReplicaSet ensures that a specified number of pod replicas are running at any given time and available too. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other valuable features.

2. Deployment Strategies:

1. Rolling Update: A Deployment object has this important feature that is, suppose you want to update your application to a newer version that means your running pods will get created into a newer version but somehow if it gets failed then also it can roll back to your previous version without facing any downtime.

   A new ReplicaSet with the new version will launch and replicas of the old version are terminated systematically as replicas of the new version launch. Eventually, all pods from the old version are replaced by the new version. But it will delete the pods one by one that is the first pod will get deleted then the newer one will be created.

2. Recreate Deployment: 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. A recreate strategy is suitable for development environments, or when users prefer a short period of downtime.

3. Blue/Green Deployment: A blue/green (or red/black) deployment strategy enables you to deploy a new version while avoiding downtime. Blue represents the current version of the application, while green represents the new version. A blue/green deployment eliminates downtime and reduces risk because you can immediately roll back to the previous version if something occurs while deploying the new version. It also helps avoid versioning issues because you change the entire application state in one deployment.

3. Create one Deployment file to deploy a sample todo-app on K8s using the "Auto-healing" and "Auto-Scaling" features.

To create a deployment yaml file you do not need to create a pod yaml file differently as inside a deployment file we are creating a pod at the end of the day just by adding some extra features to control the pod's lifecycle.

Step 1: Start the Minikube Instance and start the Minikube cluster by using the Minikube start command.

Then clone a GitHub project (django-todo-cicd) from the repository.

https://github.com/messaoudimaher/django-todo-cicd.git

Go inside of django-todo project folder.

Step 2: There is a docker file present so we need an image from that image we will a container inside of a pod with the help of Deployment.

Step 3: Build the docker image by using the docker build command.

Step 4: Check the docker image. Then we will push the image into the docker hub by using the docker push command.

Step 5: This is the docker hub, the image has been pushed successfully.

Step 6:

create a Kubernetes folder and go inside it.

Create a deployment file.

Here kind should be mentioned as Deployment,

The deployment's label and pod's(From the Template section) label names should be the same to identify the pod.

In the Deployment's Spec section define the replica number and selector, match labels will help to identify the label name as there can be many numbers of pods.

Kubectl apply command will create the deployment.

kubectl get deploy will show the deployment status .

As of now, there is only a single pod present from the kubectl get pods command we can see.

Step 7:Auto healing Feature.

If we delete one pod here, it will recreate the other pod then n there, check the Pod's Age time from the pod's status.

Step 8: Auto-scaling

When you change the replica count in a Kubernetes deployment from 2 to 4, you're instructing Kubernetes to scale down the number of pods running for that particular deployment to 2. Kubernetes will choose one pod to terminate, reducing the total count to match the desired state specified by the new replica count. So by Scaling up or Scaling down the Replica count you can handle the loads as per the requirement.

Step 9:

• To get more about the pod's information (such as IP address)by using kubectl get pods -o wide and get the IP address.

• 

  To check whether your application is running locally or not, go inside of Minikube cluster by using minikube ssh command.

• Run curl pod's ip , the application is running inside of minikube cluster but no one can access it from outside the world(we need an external ip for that) as there is another concept behind it called Services.

Thank you for reading! Your support means the world to me. Let's keep learning, growing, and making a positive impact in the tech world together.