Kubernetes Fundamentals: Deployments, ReplicaSets, Namespaces & Contexts Explained

Kubernetes: How It Works

Kubernetes is a container orchestration system that manages the deployment, scaling, and maintenance of containerized applications. It follows a declarative model, where you define what you want, and Kubernetes ensures it happens.

🛠 Key Components and Their Roles

📜 How Kubernetes Works in 5 Steps

1. You Define a Desired State (via YAML or CLI)

   • Example: You define a Deployment with 3 replicas.

2. Kubernetes Watches & Enforces the State

   • The Deployment Controller creates a ReplicaSet.

   • The ReplicaSet Controller ensures 3 Pods exist.

3. Pods Run Containers (Actual Application Execution)

   • Each Pod contains one or more containers that run your app.

   • If a Pod crashes, Kubernetes automatically replaces it.

4. Networking & Exposure (Optional)

   • If other services or users need access, a Service is used.

   • Load balancing can be done via Ingress or LoadBalancer.

5. Continuous Monitoring & Scaling

   • If traffic increases, you can scale up by increasing replicas.

   • Rolling updates replace old versions without downtime.

   • If something breaks, Kubernetes rolls back automatically.

You can think of Deployments and ReplicaSets as just configuration files (YAML or JSON) that describe how Kubernetes should manage the application. Kubernetes itself, through its controllers, actually enforces and maintains these definitions.

Summary in Simple Terms:

• Deployment & ReplicaSet → Just definitions written in YAML files.

• Kubernetes Control Plane → The real system that watches these definitions and makes sure the actual state of the cluster matches them.

• Controllers (inside Kubernetes) → Continuously monitor and enforce the desired number of Pods.

Key Takeaways:

✅ Deployments and ReplicaSets are not active processes—they are just declarations.
✅ Kubernetes does the actual work of creating, deleting, and maintaining Pods.
✅ Controllers like the Deployment Controller and ReplicaSet Controller make sure everything stays in sync.

Analogy:

• A Deployment is like a Recipe 📜 → It tells Kubernetes how many servings (Pods) of a dish should be made.

• Kubernetes is the Chef 👨‍🍳 → It follows the recipe and makes sure the correct number of servings exist.

• If a serving gets ruined (Pod crashes), the Chef makes a new one!

How Does a ReplicaSet Manage Pods?

A ReplicaSet Controller (a process inside Kubernetes) continuously monitors and ensures that the required number of Pods are running. It follows this cycle:

1. You define a ReplicaSet with a replicas count (e.g., 3).

2. The ReplicaSet Controller watches the cluster to check the actual number of running Pods.

3. If fewer Pods exist (e.g., a Pod crashes), the controller creates new ones.

4. If more Pods exist (e.g., you manually create extra ones), the controller terminates the excess.

5. This cycle continues constantly, making sure the system is in the desired state.

⚙ Example Flow of a Deployment

1⃣ You create a Deployment

Deployment → ReplicaSet → Pods → Containers

• Deployment creates a ReplicaSet.

• ReplicaSet ensures 3 Pods are running.

• Pods run containers with your app.

• If a Pod dies, ReplicaSet replaces it.

3⃣ If you update the image (kubectl apply), Kubernetes:

• Creates a new ReplicaSet for the updated version.

• Gradually replaces old Pods with new ones (Rolling Update).

🌐 Namespace & Context in Kubernetes

Both Namespaces and Contexts help organize and manage access to Kubernetes clusters, but they serve different purposes.

🗂 Namespace: Organizing Resources Within a Cluster

A Namespace in Kubernetes is a virtual cluster inside your main Kubernetes cluster. It allows you to group and isolate resources (like Deployments, Pods, and Services) within a single cluster.

Why Use Namespaces?

✅ Organize resources (e.g., separate environments: dev, staging, prod).
✅ Prevent resource conflicts (e.g., multiple teams working in the same cluster).
✅ Control access using Role-Based Access Control (RBAC).

🛠 Context: Managing Multiple Clusters & Users

A Context in Kubernetes is a shortcut that allows you to switch between different clusters, user accounts, and namespaces quickly.

Why Use Contexts?

✅ Easily switch between clusters (e.g., local, staging, production).
✅ Manage different users with different access permissions.
✅ Remember default namespace so you don’t have to specify it every time.

Summary: Namespace vs. Context

What Are Kubernetes Nodes?

In Kubernetes, nodes are the worker machines that run your applications. A node can be a physical machine or a virtual machine (VM) in the cluster.

Types of Nodes in Kubernetes

1. Master Node (Control Plane)

   • Manages the cluster and schedules workloads.

   • Runs critical components like:

     • kube-apiserver: Handles communication with the cluster.

     • kube-scheduler: Assigns Pods to worker nodes.

     • controller-manager: Manages controllers (e.g., node, deployment, and replica set controllers).

     • etcd: Stores cluster state and configurations.

2. Worker Nodes

   • Run application workloads.

   • Each worker node has:

     • Kubelet: Talks to the control plane and manages containers on the node.

     • Container Runtime: Runs containers (e.g., Docker, containerd).

     • Kube-proxy: Handles networking and service communication.

How Nodes Work in Kubernetes?

1. A Pod is scheduled to a Node

   • The scheduler decides which node should run a Pod based on available resources.

2. Kubelet ensures the Pod runs

   • Kubelet on the worker node talks to the control plane and ensures the Pod runs as expected.

3. Containers Run Inside the Pod

   • The container runtime (e.g., Docker) pulls images and runs the containers inside the Pod.

4. Kube-proxy Manages Networking

   • Handles load balancing and network rules so that services can communicate across nodes.

How Many Nodes Can Kubernetes Have?

• Single-node clusters (for testing, like Minikube).

• Multi-node clusters (for production, can scale to thousands of nodes).

Why Nodes Matter?

• More nodes = better availability and scalability.

• If a node fails, Kubernetes automatically moves Pods to another node.