🚀 (Day-03) ReplicaSet and Deployment

♻️ ReplicaSet

What is a ReplicaSet?

A ReplicaSet ensures the right number of Pods are always running. For example, if you want 3 replicas of your web app, the ReplicaSet will ensure that. If a Pod crashes, it will automatically spin up a new one.

Example:
Set replicas: 3 in your config, and Kubernetes will keep 3 Pods running. If one fails, the ReplicaSet creates a new one.

Key point:
ReplicaSet doesn't handle app updates; it just keeps the correct number of Pods running.

🛠 Hands-On Tasks

1. Create a ReplicaSet YAML file:

vi nginx-rs.yaml

2. Create the ReplicaSet:

kubectl create -f nginx-rs.yaml

3. Verify the Pods created by the ReplicaSet:

kubectl get pods
kubectl get pod -l app=nginx

4. Get detailed information about the ReplicaSet:

kubectl get rs nginx-rs -o wide
kubectl describe rs nginx-rs

5. Delete a Pod (watch the ReplicaSet recreate it):

kubectl get pod
kubectl delete pod nginx-rs-9vrt2 # Replace with the actual Pod name
kubectl get pod # Verify the ReplicaSet recreates the Pod

6. Delete the ReplicaSet and verify that the ReplicaSet and Pods have been removed:

kubectl delete rs nginx-rs
kubectl get rs
kubectl get po

This task demonstrates how ReplicaSets manage the desired number of Pods, ensuring a consistent number of replicas. When a Pod is deleted, the ReplicaSet automatically recreates it to maintain the specified count.

⚙️ Deployment

A Deployment manages ReplicaSets and provides features like rolling updates, rollbacks, and scaling, making it ideal for stateless applications. It simplifies the process of managing the application's lifecycle by automating updates and scaling

A ReplicaSet is like a helper that actually keeps the 3 Pods running. The Deployment creates a ReplicaSet, and this ReplicaSet takes care of the actual Pods.

What Does a Deployment Do?

• Manages Replicas: Ensures a specific number of app instances (Pods) are always running.

• Updates Apps: Helps to update the app’s version by automatically creating new Pods and removing old ones.

• Rollbacks: If something goes wrong with an update, you can roll back to a previous version.

Key Features:

• Rolling Updates: Deployments can update pods gradually to ensure minimal downtime.

• Rollbacks: If something goes wrong, you can easily roll back to a previous version.

• Scaling: You can easily scale the number of replicas.

How They Work Together:

• A ReplicaSet ensures the desired number of Pod replicas are running.

• The Deployment manages this ReplicaSet. Every time you update the Deployment (e.g., change the app version), a new ReplicaSet is created to handle the updated Pods, while the old ReplicaSet is scaled down.

• Deployment: Says "I want 3 Pods running."

• ReplicaSet: Follows this instruction and makes sure 3 Pods are running.

In short, Deployment is in charge, and ReplicaSet does the actual work of keeping the Pods running.

🛠 Hands-On Tasks

Task 1: Create and Deploy Nginx Pods

1. Create the Deployment YAML file:

vi dep-nginx.yaml

2. Apply the Deployment YAML:

kubectl apply -f dep-nginx.yaml

3. View the objects created by Kubernetes, Deployment and Replica Set:

kubectl get deployments
kubectl get rs
kubectl get pods

4. Access one of the Pods and check the Nginx version:

kubectl exec -it <pod_name> -- /bin/bash
nginx -v # view the Nginx version inside the Pod
exit # exit the pod

Replace <pod_name> with one of the Pod names listed in the previous command.

This task demonstrates creating a Kubernetes Deployment that manages the lifecycle of multiple nginx Pods, using a Recreate strategy to replace existing Pods with new ones during updates. You also verify the version of nginx running in the container.

Task 2: Update the Deployment with a Newer Image

1. Update the Nginx image in Pod using the below:

kubectl set image deployment/nginx-dep nginx-ctr=nginx:1.11

2. Describe the deployment and see that the old pods are replaced with newer ones:

kubectl describe deployments

• Scaled Down: The old ReplicaSet - Image 1.12.2 (e.g., nginx-dep-fb97cbf7f) is scaled down to 0, terminating the old Pods, ensuring only the updated Pods are running.

• Scaled Up: A new ReplicaSet -Image 1.11(e.g., nginx-dep-99ddcff8) is created to manage the updated Pods, and it's scaled up to 3 replicas.

• Recreate strategy, Kubernetes deletes old pods first, then creates new ones, causing downtime during the update.

3. Access one of the Pods and view the Nginx version:

kubectl exec -it <pod_name> -- /bin/bash # replace the actual Pod name
nginx -v # check the Nginx version insid ethe Pod
exit # exit the Pod

When you set the image to nginx:1.11, it pulls the latest patch of that version, which is 1.11.13. Specifying just 1.11 defaults to the latest available patch in the repository, so that's why the Pods show nginx/1.11.13

Task 3: Rollback of Deployment

1. View Deployment History: Check the rollout history with:

kubectl rollout history deployment/nginx-dep

2. Rollback the deployment: Revert to the previous version:

kubectl rollout undo deployment/nginx-dep --to-revision=1

3. Verify the status of Deployment and ReplicaSet:

kubectl get deployment -o wide   # Get detailed info abt Deployment, including image and replica details
kubectl get rs -o wide           # Verify all RS, showing image versions, replicas, and statuses

When you rolled back to version 1.12.2, the following occurred:

1. New Replica Set Creation: When you initially updated to 1.11, a new Replica Set (nginx-dep-99ddcff8) was created to manage the updated Pods.

2. Rollback to Previous Version: When you executed the rollback command, Kubernetes reverted to the previous Replica Set (nginx-dep-fb97cbf7f), which still manages the Pods running version 1.12.2.

3. Old Replica Set Status: The Replica Set for version 1.11 (nginx-dep-99ddcff8) is now scaled down to 0 because it’s no longer in use, while the Replica Set for version 1.12.2 remains active, managing the currently running Pods.

In summary, the system retains the Replica Sets for both versions for tracking purposes, but only the one for 1.12.2 is active.

4. Verify NGINX Version: Access one of the Pods to check the version:

kubectl get pods
kubectl exec -it <pod_name> -- /bin/bash # replac ewith the actual Pod
nginx -v # Check the Nginx version inside the Pod
exit # exit the Pod

Task 4: Cleanup the resources using the below command

Delete a deployment.

We can't delete the pod in the deployment without scaling out replicas; otherwise, it creates another one with the same configuration. So, the deployment file has to be removed.

kubectl delete -f dep-nginx.yaml

✅ Conclusion:

In this hands-on experience, we learned how to create and manage Kubernetes Deployments, which automatically manage ReplicaSets and Pods. We updated container images, rolled back changes, and explored how Deployments ensure the desired state is maintained. This powerful feature simplifies scaling and version control, making Kubernetes an essential tool for containerized applications in production environments.