Kubernetes and Containers

A container is a single process tree packaged with its own filesystem, libraries, and dependencies, isolated from the host using Linux kernel features. The Containerization lesson covers how that isolation works and why it is so much lighter than a virtual machine. You build the application into an image, push it to a Container Registry so other machines can pull it, and tag it carefully so you always know exactly what is running, which is the subject of the Image Versioning lesson.

Kubernetes is the layer that runs those images at scale. You do not tell it the steps to take. You tell it the end result you want, and it figures out the steps. The Declarative vs Imperative lesson is the hinge here: instead of running commands one by one, you write a description of the world you want and submit it. This shift is what makes the rest of Kubernetes possible.

The Orchestration lesson ties it together. Kubernetes schedules containers onto machines, watches their health, replaces failures, and exposes them to the network. You stop thinking about individual servers and start thinking about a pool of capacity that runs whatever you ask it to.

The single most important idea in Kubernetes is the reconciliation loop. You declare a Desired State Configuration, the cluster records it, and a controller continuously compares desired state against actual state and acts to close the gap. The Controllers and Reconciliation Loops lessons explain this engine in detail. If you ask for three replicas and one crashes, the controller notices two are running and starts a third. Nothing intervenes manually. The loop just runs forever.

Different workload shapes get different controllers. DaemonSets put exactly one copy on every node, which is how log collectors and node agents work. StatefulSets give each replica a stable identity and its own storage, which is what databases and queues need. Jobs and CronJobs run work to completion on a schedule rather than running forever. Init Containers run setup steps before the main container starts. Each is a variation on the same control loop with different guarantees.

When the built-in resources are not enough, you extend Kubernetes itself. Custom Resource Definitions let you teach the cluster a new object type, and Operators pair a CRD with a controller that knows how to manage a specific application, like running a Postgres cluster the way a human expert would. This is how the platform grows without forking it.

Scaling is automatic when you set it up. The Auto-Scaling lesson covers scaling the number of pods based on load and growing the cluster itself when there is nowhere left to schedule. You define a target, like a CPU threshold, and the system adds or removes capacity to hold that target.

State is the hard part of any distributed system, and Kubernetes handles it through storage abstractions. Volume Management covers attaching storage to containers, and Persistent Volumes cover storage that outlives any single pod so a restarted database keeps its data. Networking adds two more pieces: Ingress Controllers route outside traffic to the right service with TLS and path rules, and Network Policies act as a firewall between pods so a compromised service cannot reach everything else.

Security runs through the whole stack. The Container Security lesson covers minimal images, dropping privileges, scanning for known vulnerabilities, and limiting what a container can do at runtime. The Immutable Infrastructure, Config Drift Prevention, and Desired State Configuration lessons reinforce a single discipline: never patch a running container by hand. Change the declaration, roll a new version, and let the cluster converge. That is what keeps a large fleet predictable.

Google runs nearly everything on a container orchestrator and built Kubernetes from the lessons of its internal Borg system, which is why the open source project maps so closely to how hyperscale infrastructure actually works. The control loop, the scheduler, and the desired-state model all come straight from running planet-scale services.

Spotify, Airbnb, and most large engineering organizations use Kubernetes to give every team a self-service platform. A team ships an image and a declaration, and the cluster handles placement, scaling, restarts, and rollouts. The Operator pattern shows up everywhere too: companies package their stateful systems, from databases to message brokers, as Operators so on-call engineers are not manually running recovery steps at 3 AM.

The common thread is use of capacity, not micromanagement of machines. Whether you run ten services or ten thousand, the model is identical: declare what you want, let controllers reconcile it, and treat infrastructure as immutable and replaceable. That uniformity is why the same skills transfer across almost every company running modern backend systems.