When we start learning Kubernetes, it is important to understand why each concept exists. This guide walks through the evolution of Kubernetes components—from basic containers to advanced deployment strategies.

Each step solves a limitation of the previous one, helping us understand how Kubernetes manages applications in real-world environments. and background process what it is done.

1. Container

• A container is a lightweight, portable unit that packages application code and its dependencies.

• It runs consistently across different environments—development, testing, and production.

Problem with Containers:

• Containers do not restart automatically if they fail.

• No built-in mechanism for scaling or managing multiple instances.

• Manual effort is required to monitor and recover failed containers.

2. Pod

• A Pod is the smallest building block in Kubernetes.

• It can contain one or more containers ( but as a best practice one pod has only one container => 2 containers in one pod also used in sidecar containers) that share storage, network, and lifecycle.

Observe If anything happen to the pod suddenly deleted or crashed. It show No resources found.
It not automatically Running State, If you need that pod, you need to apply manually again.

Problem with Pods:

• pod is ephemeral. (If due to any issues pod is deleted can’t up automatically)

• Pods are not self-healing. If a Pod crashes, it won’t restart automatically.

• No replication or scaling features by default.

• Manual intervention is needed to maintain availability.

2. Replication Controller (RC) -

A Replication Controller (RC) is a Kubernetes component that ensures a specified number of identical Pods are always running in the cluster.

If a Pod crashes or is deleted, the RC automatically creates a new one to maintain the desired count. It helps with basic fault tolerance and horizontal scaling.

Key Features:

• Maintains a fixed number of Pod replicas.

• Automatically replaces failed or terminated Pods.

• Supports manual scaling by changing the replica count.

THIS IS SAMPLE ReplicationController YAML FILE

apiVersion: v1
kind: ReplicationController
metadata:
  name: javawebrc
  namespace: test
  labels:
    name: javarc
spec:
  replicas: 3
  selector:
    app: javawebapp
  template:
    metadata:
      name: javawebpod
      labels:
        app: javawebapp
    spec:
      containers:
        - name: javawebcon
          image: mamathabandi/maven-web-app:1.0.0
          ports:
           - containerPort: 8080

Why We are Going for Replication Controller Instead of POD

Before RC, Pods had to be managed manually. If a Pod failed, it wouldn’t restart unless someone run again. This was not practical for production systems.

RC solves these problems:

• Self-healing: Automatically recreates Pods if they fail.

• Scalability: Easily increase or decrease the number of Pods.

• Consistency: Ensures the desired state is always maintained.

In short, RC introduced automation and reliability to Kubernetes workloads, making it a foundational step toward more advanced controllers like ReplicaSet and Deployment.

Observe In this ReplicationController is created and replicas=3 so it create 3 Pods. If anything happen to POD deleted or crashed. It automatically restart state.

pod/javawebrc-gwtsh is deleted. That pod replaces with pod/javawebrc-wp2xz running. see timestamp 7s

Differences between POD and ReplicationController

4. ReplicaSet (RS)

• RS is the modern version of RC.

• It uses label selectors to manage Pods more flexibly.

• RS is used internally by Deployments.

Why RS over RC?

• RS supports advanced label selectors means it is support for both equality-based selector and set-based selector..

• It is more efficient and widely adopted in modern Kubernetes setups.

Equality-based selector:

In Equality based selector we use matchLabels inside selector

Set-based Selector

Set-Based Selector Keywords (OneWord Definations)

Example Usage in matchExpression

selector:
  matchExpressions:
  - key: app
    operator: In
    values:
    - javawebapp1
    - javawebapp2

This matches Pods where the label app is one of the listed values.

In Set-based selector we use matchExpressions inside selector.

Difference Between Replication Controller (RC) and ReplicaSet (RS)

Comparison of RC and RS:

First see ReplicationController:

1. Selector is optional to match with Labels.

2. Without writing selector field also it automatically matches to Labels.

Observe without writing selector also it matches app=javawebapp

Next See ReplicaSet

1. In Replicaset selector is mandatory field to write

2. If we didn't write Selector it through error Selector: Required Value

Observe without writing selector it through Selector: Required Value

5. DaemonSet (DS)

• DS ensures that a Pod runs on every Node in the cluster.

• Commonly used for system-level tasks like logging, monitoring agents, or networking agents.

• One Pod per Node:

  DaemonSets guarantee that a single pod runs on each selected node

When we run kubectl get all -A -o wide, we see kube-proxy and weave-net always running in the background because they are deployed as DaemonSets to ensure one Pod runs on every Node for networking and service routing.

DaemonSet Yaml

How to declare daemon we use nginx Instead of logging file for understanding. but in realtime used for logging, monitoring purpose of nodes deployed in 2 nodes only.

We created a DaemonSet using an Nginx pod to understand how it runs one pod per node. In real-world scenarios, DaemonSets are used for logging, monitoring, or networking agents.

After applying the DaemonSet, it was scheduled only on slave nodes, not on the control plane node. This is because the control plane node has a taint that prevents regular workloads from being scheduled:

Tolerations:

Add this under spec.template.spec in your DaemonSet:

tolerations:
- key: "node-role.kubernetes.io/control-plane"
  operator: "Exists"
  effect: "NoSchedule"

We added a toleration to our DaemonSet so that it can be scheduled on control plane nodes, which are normally restricted by taints. This is useful for system-level Pods like logging or monitoring agents that must run on every node—including control plane nodes.

Without this toleration, the DaemonSet Pods will only appear on worker nodes (which have no taints).

Problem with RS: No Version Control

• The change won’t reflect in existing Pods.

• RS does not support rollback or reversion or reverting to previous versions.

• You must manually delete Pods or recreate the RS to apply changes.

• Suppose I deploy a Pod with image version 2.0.2.

• Later, you update the RS YAML to use image 1.0.0 and reapply it.

• Even though apply again also it won’t reflect changes see AGE of POD 7m37s and it is pointing to 2.0.0

6. Deployment

A Deployment is In Kubernetes, is a higher-level object that manages ReplicaSets and ensures that a specified number of pods are running at all times. It provides features like rolling updates, rollbacks, and scaling.

With Deployment, you can:

• Update your application without downtime.

• Roll back to a previous version if something goes wrong.

• Maintain revision history for tracking changes.

Deployments internally manage ReplicaSets and ensure that the desired state of your application is always maintained.

Deployment Strategies are 2 types:

1. Recreate Strategy

2. RollingUpdate strategy

1. Recreate Strategy

Definition:

• Terminates all existing Pods before creating new ones with the updated configuration.

Behavior:

• All old Pods are stopped first.

• Then, new Pods are created with the updated version.

Use Case:

• Suitable when downtime is acceptable or when the application cannot run multiple versions simultaneously.

Drawback:

• Causes downtime during the update process.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: javadeploy
  namespace: test
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: javawebapp
  template:
    metadata:
      name: jabawebpod
      labels:
        app: javawebapp
    spec:
      containers:
        - name: javawebcon
          image: kkeducation12345/spring-app:1.0.5
          ports:
            - containerPort: 8080

Step 1: Used image version 1.0.5 in deploy.yaml

kubectl apply -f deploy.yaml
kubectl get all -n test

→ Creates Pods in the background using Deployment.

Step 2: Edited deploy.yaml and changed image to 1.0.2

vi deploy.yaml  # change image version to 1.0.2
kubectl apply -f deploy.yaml
kubectl get all -n test

→ New Pods created with updated version.
→ Old Pods terminated (Recreate strategy).
→ Pod age shows recent (e.g., 9s), confirming update.
→ Deployment revision is tracked automatically.

Conclusion:

Even if only the Pod template changes, Deployment reflects updates. This overcomes RS and DS limitations—versioning and rollback are possible.

For better understanding describe the ReplicaSet to see which version is latest(running state) and which version is old (downstate).

kubectl describe replicaset.apps/javadeploy-578998884 -n test #Present running vesrion 1.0.2

kubectl describe replicaset.apps/javadeploy-578998884 -n test # Old Down vesrion 1.0.5

Rollback to Previous Deployment Version

After applying multiple updates to your Deployment (e.g., changing image versions), Kubernetes tracks each change as a revision. You can view and revert to any previous revision using the following commands.

1. View Deployment Revision History

kubectl rollout history deployment javadeploy -n test

→ Shows all revisions with change-tracking.

2. View Details of a Specific Revision

kubectl rollout history deployment javadeploy -n test --revision=1
kubectl rollout history deployment javadeploy -n test --revision=2
kubectl rollout history deployment javadeploy -n test --revision=3

→ Each revision corresponds to a specific image version:

• Revision 1: kkeducation12345/spring-app:1.0.5

• Revision 2: kkeducation12345/spring-app:1.0.2

• Revision 3: kkeducation12345/spring-app:1.0.3

3. Rollback to a Previous Revision

kubectl rollout undo deployment javadeploy -n test --to-revision=1

→ Reverts the Deployment to image version 1.0.5.

ROLLBACK TO PREVIOUS VERSION

Using kubectl rollout undo, we can revert to any previous image version based on revision history—this is one of the key advantages of using Deployment over RS or DS.

Observing Pod Downtime with Recreate Strategy

Step 1: Connect VS Code to Master Node via SSH

• Install Remote - SSH extension in VS Code.

• Open Command Palette:

    Ctrl + Shift + P → Remote-SSH: Connect to Host...
  

• Enter SSH details:

    ssh user@<master-node-IP>
  

• Once connected, open your deploy.yaml file and make changes directly in VS Code.

Step 2: Apply Deployment with Recreate Strategy

• In VS Code terminal:

    kubectl apply -f deploy.yaml
  

  On master node (or in another terminal), run:

    watch kubectl get po -n test
  

→ This command continuously (Every 2 seconds) monitors pod status in the test namespace.

2. RollingUpdate Strategy

Definition:

• Gradually replaces old Pods with new ones, ensuring that some Pods are always available during the update.

Behavior:

• Updates a few Pods at a time (based on maxUnavailable and maxSurge settings).

• Ensures zero downtime and smooth transition.

Use Case:

• Ideal for production environments where availability is critical.

Advantage:

• Supports rollback and maintains high availability during updates.

RollingUpdate Strategy: Zero Downtime Deployment

USING Watch see live status of pod every 2 seconds (for better understanding)

In this Example, We use the RollingUpdate strategy to deploy changes in kubernetes. This method ensures that at lease one Pod remains available at all times, avoiding downtime.

Steps to Observe Live POD Status:

1. Connect VS Code to Master Node via SSH

   • Use the Remote-SSH extension in VS Code.

   • Connect using:

       ssh user@<master-node-IP>
     

   • Open your deployment YAML file and make necessary changes.

2. Apply the Deployment

   • In the VS Code terminal, run:

       kubectl apply -f rollingdeploy.yaml
     

3. Monitor Pod Status in Real Time

   • On the master machine or in a separate terminal, run:

       watch kubectl get po -n test
     

   • This command continuously displays the current status of Pods in the test namespace.

What we Observe

• A new Pod starts before the old one is terminated.

• In your image, the new Pod is up in 7 seconds while the old Pod is still running.

• There is no downtime—at least one Pod is always available during the update.

Key Points

RollingUpdate ensures continuous availability. By using watch kubectl get po -n test, you can observe the live transition: new Pods start first, and only then are old Pods removed. This is ideal for production environments where uptime is critical.

By reading this blog, you will clearly understand what happens in the background of Kubernetes—from container creation to deployment—and how each component plays its role in managing applications efficiently.