Oboe
No history yet

How kubernetes work

Welcome! It's great to help you unpack how Kubernetes works. Before we dive into the core architecture, I'd love to know a bit about what brings you here and what your background looks like.

What brings you to learning Kubernetes, and how much prior experience do you have with containers like Docker?

I need to learn it for a new job or upcoming project quickly.

Since you're on a fast track to learn Kubernetes for your new job, let's skip the fluff and look at the big picture: what exactly is container orchestration, and how does Kubernetes fit in?

The Shipping Port of the Cloud

If you already use , you know it's fantastic for packaging an application and its dependencies into a single, neat container. But what happens when your application grows and you need to run one hundred of those containers across ten different servers? If one server crashes, who moves the containers to a healthy server? If traffic spikes, who spins up twenty more container copies and balances the incoming user requests across them? That is where container orchestration comes in. Think of Kubernetes as the highly automated foreman of a massive shipping port. Docker provides the physical shipping containers, but is the orchestration system—the cranes, the routing schedules, and the digital manifests—that coordinates where those containers go, ensures they are running smoothly, and automatically scales them up or down based on demand.

A comparison showing a single container on a host alongside a control tower coordinating multiple container hosts.

I've sketched out a quick visualization above to help contrast Docker's single-host focus with the fleet-wide automation that Kubernetes manages.

Next, we need to look at how Kubernetes splits this massive orchestration job into two distinct parts: the brains that make the decisions, and the muscle that runs the actual work.

Give me a quick worksheet on the difference between Docker and K8s

You got it! I've kicked off a structured worksheet to help solidify the differences between Docker and Kubernetes before we dive deeper into the architecture.

Docker vs. Kubernetes: Understanding the DifferenceWorksheet
While that worksheet builds, let's explore how Kubernetes actually splits its workload. At its core, Kubernetes divides a cluster into two primary jobs: the Control Plane (the brain) and the Worker Nodes (the muscle). In a physical shipping port, the Control Plane is the air-conditioned tower where the managers look at the big picture, track inventory, and decide which crane goes where. The Worker Nodes are the actual docks and container ships on the ground doing the heavy lifting of storing and moving cargo. Let's look at how this split works.

The Brain: The Control Plane

The is responsible for making global decisions about your cluster. It detects when containers crash, schedules new ones when traffic spikes, and keeps track of the entire cluster's health. It consists of several microservices working in tandem, such as the API Server (the gateway), etcd (the database of record), the scheduler (which decides which node runs which workload), and controller managers (which constantly make sure your system's actual state matches what you wanted). For instance, if you tell Kubernetes "I want 3 copies of my web server running," the Control Plane is what notices if one copy dies and instantly schedules a replacement.

The Muscle: Worker Nodes

The are the physical or virtual machines where your applications actually run. Each node contains three key components: the Container Runtime (which physically runs the container, like containerd), the Kubelet (an agent that acts like a local foreman, taking instructions from the Control Plane and reporting back), and the Kube-Proxy (which manages the networking rules so traffic can reach your containers).

The Kubernetes architecture split showing the control plane with its core components on the left and two worker nodes on the right.

I've outlined this architectural split in the visualization above to show exactly how the Control Plane talks to the Worker Nodes. Next, we need to talk about how Kubernetes ensures your application stays running through a concept called Desired State vs. Actual State.