Kubernetes Fundamentals

Kubernetes is a system for running and managing containerized applications across a group of machines, automatically keeping them in the state you asked for.

Docker solves how to package and run one container on one machine. Kubernetes solves a different, harder problem: given hundreds of containers that need to run across dozens of machines, how do you decide where each one runs, keep them running when things fail, route traffic to them, and roll out new versions safely — all without a human manually managing every container by hand.

The core building blocks

Kubernetes architecture splits every cluster into a control plane that makes decisions and worker nodes that run your application Pods, as the diagram under “What Is Kubernetes?” above shows. The control plane holds the API Server, etcd, the Scheduler, and the Controller Manager. Each worker node runs a kubelet that starts and watches the containers on that machine. The “Cluster Architecture” chapter later in this guide covers each component.

Docker gave us portable, isolated processes. Kubernetes answers the next question: how do you run thousands of them reliably, at scale, across machines that will inevitably fail?

A single Docker host with a restart policy can recover a crashed container. But it can't recover from the host itself dying, can't intelligently decide which of 50 machines has room for a new container, can't roll out a new version without downtime, and can't automatically add capacity when traffic spikes. These are exactly the problems an orchestrator is built to solve.

Every Kubernetes cluster splits cleanly into two halves: a control plane that decides, and worker nodes that execute.

The control plane runs a handful of specialized processes — none of which run your application code. The API Server is the front door: every request, from kubectl, from a CI pipeline, from an internal controller, goes through it and nowhere else. etcd is a distributed key-value store holding the entire cluster's desired state. The Scheduler decides which node a new Pod should run on. Controllers (collectively the Controller Manager) continuously watch for drift between desired and actual state and correct it.

You almost never create a Pod directly in production — you create a Deployment, and Kubernetes manages the Pods for you through a ReplicaSet.

Pods are ephemeral and their IPs change constantly — a Service gives applications one stable address to depend on.

A Service selects Pods by label (e.g. app: web) and maintains a continuously-updated list of their IPs, called Endpoints. Clients connect to the Service's stable ClusterIP and DNS name; Kubernetes' networking layer (kube-proxy) transparently routes that connection to one of the healthy backing Pods.

Kubernetes doesn't just start your application once — it continuously watches and corrects, and can grow or shrink capacity automatically.

If a container inside a Pod crashes, the kubelet on that node restarts it in place according to the Pod's restartPolicy (the Pod object stays). If a Pod itself is lost — its node fails or it is evicted — the ReplicaSet controlling it notices the mismatch between desired count and current count, and creates a replacement, usually on a different node. If an entire node goes down, every Pod on it is eventually rescheduled elsewhere. If CPU load rises, the Horizontal Pod Autoscaler (HPA) can increase the replica count automatically, and scale back down once load subsides.

The same container image should run in every environment — configuration differences and durable data are handled through dedicated Kubernetes objects, not baked into the image.

A Service alone gives you internal, IP-based access — Ingress adds HTTP-aware routing (hostnames, paths, TLS) for traffic coming from outside the cluster.

An Ingress resource defines rules like "requests to /api go to the app-svc Service" or "requests to admin.example.com go to the admin-svc Service." An Ingress Controller (a piece of software running in the cluster) watches these rules and configures a reverse proxy or load balancer accordingly.