Kuberenetes(k8s) Architecture

Before you deep dive into the article go visit docker first !

Kubernetes is just an orchestrator of containers, If you don’t know what are containers, you might feel nothing

With Docker you learn:

• How to package an app into a container (Dockerfile).

• How to run and manage containers (docker run, docker ps, docker exec).

• How to expose ports, map volumes, and define multiple services (docker-compose).

Once you’re comfortable with that, you’re ready to explore how Kubernetes scales this idea to hundreds or thousands of containers running across many machines.

What is Kubernetes?

Kubernetes (often called K8s) is a container orchestration platform.

It answers real-world questions like:

• How do I run containers across multiple machines?

• How do I restart containers automatically if they fail?

• How do I balance traffic between multiple container replicas?

• How do I update apps without downtime?

In short: Docker runs containers, Kubernetes manages them at scale.

🏛 Kubernetes Architecture (Deep Dive)

Let’s break the architecture into two sides:

• Control Plane → the brain of the cluster

• Worker Nodes/Nodes → the muscle that actually runs your containers in the form of Pods which are controlled by Control Place/Master Machine

---

Pod — The Smallest Unit

• A Pod is the smallest deployable object in Kubernetes.

• Think of a pod as a wrapper around one or more containers.

• Every pod gets:

  • A unique IP address in the cluster.

  • Optionally shared storage volumes.

  • Shared lifecycle (if pod dies, all containers inside die).

Example:
If you deploy an app in Tomcat container , then that container here can be referred to as pod, Most of the pods contains single container and at some times there might be multiple containers in a single pod

Node — The Worker Machine

• A Node is a physical or virtual machine in your cluster, like a VM in local cloud, or an EC2 instance in AWS or a Azure VM in Azure

• It runs pods assigned by the control plane(Master Machine).

• Each Node has three main components:

  • Kubelet → agent that talks to control plane and manages pods(receives instruction from Master Machine and implement them in Nodes)

  • Container Runtime (Docker, containerd, CRI-O) → actually runs the containers.

  • Kube-proxy → handles pod-to-pod networking and load balancing.

Example:
A Node could run 5 Nginx pods + 3 Redis pods.

Cluster — Group of Nodes

• A Cluster = control plane + worker nodes.

• From your perspective, you don’t care which specific machine your app runs on — you just tell Kubernetes “I want 5 replicas” and the cluster ensures it happens.

Example:
Your cluster may have 3 Nodes. Kubernetes decides how to spread 10 Pods across them.

Control Plane — The Brain

The Control Plane makes global decisions about the cluster. It ensures the actual state matches your desired state.

Components of the control plane:

• API Server

  • The front door.

  • Every request (kubectl apply, kubectl get pods) goes here.

  • Exposes Kubernetes API.

• etcd

  • A distributed key-value store.

  • Stores the cluster’s state (which pods exist, which nodes are alive, configs, etc.).

• Scheduler

  • Decides where new Pods should run.

  • Example: If Node A is overloaded, it sends new Pods to Node B.

• Controller Manager

  • Ensures the cluster state matches what you declared.

  • Example: If you said “3 replicas” and 1 pod dies, the controller recreates it.

Together, these components form the city government of Kubernetes, while worker nodes are the buildings running your workloads.

Namespace — Logical Separation

• A Namespace is like a folder inside your cluster. There will be multiple pods across multiple nodes so it is difficult to organise them, so namespace comes handy here

• Helps organize resources (dev, staging, prod). You can distribute you pods across these namespaces

• These namespaces are irrespective of nodes,

• You create pods in the dev namespace asking for 4 pods of various application containers.

  • Pod 1 → scheduled on Node 1

  • Pod 2 → scheduled on Node 2

  • Pod 3 → also on Node 2

  • Pod 4 → back on Node 1

All 4 Pods belong to the dev namespace, but they are spread across multiple Nodes.