1. Why was Kubernetes invented?
Before Kubernetes, the way companies ran applications went through three major phases:
The Physical Server Era: Applications were run on physical hardware. If one app took up too much memory, other apps on that server would crash. It was expensive and wasteful.
The Virtual Machine (VM) Era: To solve the hardware problem, VMs allowed to run multiple isolated "virtual" computers on one physical server. This was better, but VMs were heavy and slow to start because each one needed its own full operating system.
The Container Era (Docker): Developers realized they didn't need a whole operating system for every app. They created "containers"—lightweight, isolated packages containing just the app and what it needs to run.
The Breaking Point: Containers were brilliant, and companies started using them for everything. But suddenly, instead of managing 10 large VMs, a company had to manage 1,000 tiny containers. If a container crashed in the middle of the night, someone had to manually restart it. If a website went viral, someone had to manually start 50 more containers to handle the traffic. It became a logistical nightmare.
Kubernetes was invented to be the automated "pilot" for the containers.
It handles the things humans are too slow to do:
Automated Scaling: If the app suddenly gets a spike in traffic, Kubernetes automatically creates more containers to handle the load, then scales them back down to save money when traffic drops.
Self-Healing:
If a container crashes, the server dies, or a network drops, Kubernetes instantly notices and starts a replacement container somewhere else without a human having to intervene.Automated Rollouts:
It allows developers to release new versions of an application slowly, behind the scenes. If the new version has a bug, Kubernetes automatically rolls it back to the old one before users notice.
Ultimately, Kubernetes was invented so developers could stop worrying about how their apps were running and get back to actually writing the code.
2. The main two components of Kubernetes architecture
The Control Plane Node (The Brain)
The Control Plane is responsible for making global decisions about the cluster. It does not run our applications; it manages the machines that do. Its job is to maintain the desired state of the cluster, respond to events (like a node crashing), and schedule workloads.The Worker Node (The Muscle)
A Worker Node is the machine (virtual or physical) where our actual application workloads (Pods and Containers) are executed. Its sole job is to do what the Control Plane tells it to do and report back on its status.
In a production cluster, we will have many worker nodes to distribute the load and provide redundancy.
3. The components of the Kubernetes Control Plane
- kube-apiserver (The Front Door)
This is the only component that interacts directly with the user (via kubectl) and the only component that talks directly to the database (etcd).
Function: It exposes the Kubernetes REST API. When we want to create, read, update, or delete any resource (like a Pod or a Deployment), we send that request here.
Security: It acts as the gatekeeper. It handles authentication, authorization, and admission control.
Scale: It is designed to scale horizontally. In a highly available (HA) cluster, we will run multiple instances of the API server behind a load balancer.
- etcd (The Source of Truth)
This is a consistent, highly-available, distributed key-value backing store.
Function: It holds the entire state of our cluster. Every configuration, every secret, and the desired state of every application is saved here.
The "Watch" Pattern: etcd allows the API server to "watch" for changes. If a change occurs in the database, the API server is immediately notified, which then notifies the other control plane components.
Crucial Rule: No other component (not the scheduler, not the controllers, not the worker nodes) is allowed to query etcd directly. They all must ask the API server.
- kube-scheduler (The Dispatcher)
When a new Pod is created in etcd, it doesn't have a node assigned to it yet. The scheduler's job is to find it a home.
Function: It watches the API server for newly created Pods with no assigned node, and selects a healthy worker node for them to run on.
Decision Making: It doesn't pick nodes randomly. It runs a two-step process:
-> Filtering: It eliminates nodes that can't run the Pod (e.g., the node doesn't have enough RAM, or the Pod requires a GPU that the node lacks).
-> Scoring: It ranks the remaining nodes to find the optimal placement (e.g., preferring a node that already has the required container image downloaded).
- kube-controller-manager (The Enforcer)
This is actually a single binary that compiles several distinct, infinite control loops (controllers) into one process.
Function: It continuously watches the current state of the cluster (via the API server) and compares it to the desired state (stored in etcd). If they don't match, it takes action to fix it.
Examples of internal controllers:
-> Node Controller: Notices when a worker node goes offline and responds.
-> ReplicaSet Controller: Ensures the correct number of Pods are running for a given application.
-> Job Controller: Watches for Job objects (one-off tasks) and creates Pods to run those tasks to completion.
- cloud-controller-manager (The Liaison - Optional)
If our cluster is running in the cloud (AWS, GCP, Azure), this component lets Kubernetes talk directly to the cloud provider's API.
Function: It separates cloud-specific control logic from the core Kubernetes code.
Examples: If we create a Kubernetes Service of type LoadBalancer, the cloud-controller-manager talks to AWS/GCP to actually spin up a physical load balancer resource in our cloud account and route traffic to our nodes.
4. The components of a Worker Node
- kubelet (The Node Captain)
The kubelet is the primary "agent" that runs on every single worker node in the cluster.
-> The Job: It constantly listens to the Control Plane's kube-apiserver for instructions. When the Scheduler assigns a Pod to its node, the kubelet is responsible for making sure the containers described in that Pod are actually running and healthy.
-> The Watchdog: It doesn't just start containers; it monitors them. If a container crashes, the kubelet tries to restart it based on its defined restart policy. It also continuously reports the node's health and resource usage (CPU/Memory) back to the Control Plane.
- Container Runtime (The Engine)
While the kubelet manages the concept of a Pod, it doesn't know how to actually run a container. That is the job of the Container Runtime.
-> The Job: It handles the low-level mechanics of pulling container images from a registry (like Docker Hub or AWS ECR), unpacking them, and running the isolated processes on the host operating system.
-> Examples: Kubernetes used to rely heavily on Docker, but today it uses runtimes that comply with the Container Runtime Interface (CRI), such as containerd or CRI-O.
- kube-proxy (The Network Traffic Cop)
Since Pods are constantly being created, destroyed, and moved around, their internal IP addresses are always changing. The kube-proxy ensures that network traffic still finds its way to the right place.
-> The Job: It runs on every node and maintains network rules (usually by manipulating iptables or IPVS on Linux).
-> The Routing: If an external request comes in for your web application, or if a backend service needs to talk to a database Pod on another node, kube-proxy ensures that the traffic is routed dynamically to the correct, currently active Pod, no matter which worker node it happens to be living on.
5. Nodes vs Pods
Node
-> A physical or virtual machine.
-> The Cloud Provider (if managed K8s) or Cluster Admin.
-> Long-lived.
-> Gets a host IP on the internal network.Pod
-> An abstraction wrapping one or more containers.
-> Kubernetes Control Plane (specifically the Scheduler).
-> Short-lived / Ephemeral.
-> Gets its own unique cluster-internal IP address.
-> Many run on a single Node.
Top comments (0)