Kubernetes explained: the architecture, and whether you actually need it

Kubernetes (k8s) is a system for running containers across many machines—automatically placing them, restarting them when they crash, scaling them up and down, rolling out updates without downtime, and giving them stable network identities. It is powerful but complex, usually overkill for a homelab or single-server app, where Docker Compose can handle similar tasks with fewer moving parts. Kubernetes earns its complexity at scale and is a genuine career skill.

WHAT PROBLEM IT SOLVES

Compose runs containers on one host. When you have several machines and need containers spread across them, automatically rescheduled when a node dies, scaled on demand, and updated with zero downtime, you need an orchestrator. Kubernetes is the industry-standard one (descended from Google's internal "Borg" system). You declare the desired state ("I want 3 replicas of this app"), and Kubernetes continuously works to make reality match—the reconciliation loop at the heart of everything it does.

THE ARCHITECTURE

CONTROL PLANE (The Brain, Usually on Dedicated Nodes)

API SERVER: The front door—every command and component talks to it. kubectl talks to this.
ETCD: The cluster's database—a key-value store holding the entire desired and current state. Back this up; lose ETCD, and you lose the cluster’s memory.
SCHEDULER: Decides which node each new pod runs on, based on resources and constraints.
CONTROLLER MANAGER: Runs the reconciliation loops that drive actual state toward desired state (if a pod dies and you wanted 3, it makes a new one).

WORKER NODES (Where Your Containers Actually Run)

KUBELET: The agent on each node that starts and supervises containers as the API server instructs.
CONTAINER RUNTIME (e.g., containerd): Actually runs the containers.
KUBE-PROXY: Handles the networking rules that make Services work.

THE CORE OBJECTS YOU WORK WITH

You declare these in YAML and apply them with kubectl apply.

POD: The smallest unit—one or more containers that share a network address and storage. Usually one container per pod. Pods are disposable and get replaced, never "fixed in place."
DEPLOYMENT: Manages a set of identical pod replicas—handles rolling updates, rollbacks, and self-healing (keeps the number of replicas you asked for). This is what you deploy apps as.
SERVICE: A stable network endpoint and load balancer in front of a set of pods. Types: ClusterIP (internal only), NodePort (a port on every node), LoadBalancer (an external load balancer).
INGRESS: HTTP routing into the cluster by hostname and path—essentially a managed reverse proxy, backed by an ingress controller like nginx-ingress or Traefik.
CONFIGMAP AND SECRET OBJECTS: Hold configuration and sensitive values, kept out of the image.
NAMESPACE: Logical partitions of one cluster (dev, prod, per-team).
PERSISTENTVOLUME AND PVC: How pods get durable storage since pods themselves are ephemeral.

THE DISTRIBUTIONS

Kubernetes isn't one download; it comes in different flavors:

MANAGED CLOUD: EKS (AWS), GKE (Google), AKS (Azure)—the provider runs the control plane. The most common way companies use Kubernetes.
FULL SELF-MANAGED: KubeAdm-built clusters—you run everything, most work.
LIGHTWEIGHT (Homelab Answer): K3s (Rancher—a single binary, trimmed-down, the de facto homelab and edge choice), k0s, MicroK8s. For local development: Kind and Minikube (a throwaway cluster on your laptop). If you're doing Kubernetes at home, it's almost certainly K3s.

NETWORKING

Every pod gets its own IP; a CNI plugin (Flannel for simple, Calico or Cilium for network policy and scale) wires them together. Services provide stable endpoints; an ingress controller routes outside HTTP traffic in. This is one of the harder parts of Kubernetes.

THE COMPLEXITY TAX

Kubernetes has a steep learning curve and a lot of operational overhead—control-plane upgrades, ETCD backups, certificate rotation, CNI quirks, and YAML sprawl (Helm, the k8s package manager, and operators exist to tame it). Every one of these is work you don't have with Compose. Adopt it when the benefits (multi-node self-healing, auto-scaling, zero-downtime deploys, a real platform for many teams) are worth that tax—not before.

WHEN TO USE IT VS NOT

USE KUBERNETES WHEN: You have multiple nodes, need self-healing across hosts, want horizontal auto-scaling, require zero-downtime rolling deploys, run many microservices, have a team, or are deliberately learning it for a job (a completely valid homelab reason).
DO NOT USE IT WHEN: It's one machine, a handful of services, or a solo operator—Docker Compose is the correct, boring answer, and reaching for Kubernetes there just buys you complexity.

THE HOMELAB PATH

Start with Docker and Compose; graduate to K3s only when you genuinely have multiple nodes and want orchestration (or want the resume line). Worth knowing: Orchestration is not automatically the "grown-up" choice—plenty of serious infrastructure runs on Compose and VMs. Our own five-year plan bets its cloud phase on Proxmox and VMs, not Kubernetes, because the right tool depends on the workload, not on what's fashionable.

flowchart TD
    A[API Server] --> B[ETCD]
    B --> C[Scheduler]
    C --> D[Controller Manager]
    D --> E[Kubelet on Worker Node]
    E --> F[Container Runtime (e.g., containerd)]
    F --> G[Kube-Proxy]

Related: Docker in depth · VM vs container