Kubernetes,
and the desired state it chases.

Containers solved packaging: bundle an app with its dependencies so it runs the same everywhere. Great — for one container on one machine. But real systems run hundreds of containers across many machines, and that raises a swarm of hard questions: which machine does each container run on? What happens when one crashes, or a whole machine dies? How do containers find and talk to each other when they're constantly created and destroyed? How do you roll out a new version without downtime, or scale up under load?

Doing all that by hand doesn't work. Kubernetes is a container orchestrator: it automates placement, healing, networking, rollouts, and scaling across a cluster of machines. It turns "a fleet of containers on a fleet of servers" from a manual nightmare into something you declare and it manages.

You might expect Kubernetes to schedule containers directly. Instead the smallest unit is a pod: one (or a few tightly-coupled) containers that share a network address and storage and are always placed together on the same node. Most pods hold a single app container; a second "sidecar" container (a log shipper, a proxy) is added when it must live right next to the main one.

The crucial property: pods are ephemeral. They can be created, killed, and rescheduled at any moment — a pod has no stable identity or IP you should rely on. So you don't create pods by hand and babysit them; you declare a higher-level object that owns pods and replaces them as needed. That's the next piece.

A Deployment is how you actually run an app. You declare: "run N replicas of this container image, with these resources." Under the hood a ReplicaSet ensures exactly N identical pods exist — if one dies, it makes another; if you change N, it adds or removes pods. You never touch individual pods; you edit the Deployment's desired count and image.

Deployments also give you rolling updates: change the image and Kubernetes gradually replaces old pods with new ones, keeping the app available throughout, and can roll back if the new version misbehaves. This is the everyday interface: declare what you want running, and let the Deployment keep it that way.

Pods are ephemeral with changing IPs, so how does anything reliably reach them? A Service gives a stable virtual address and DNS name that fronts a dynamic set of pods (selected by label). Traffic to the Service is load-balanced across the healthy pods behind it, and as pods come and go the Service tracks them automatically. Your other services just call payments and never worry about which pods exist right now.

This is service discovery and load balancing built in: the Service is the stable front door over an ever-changing fleet. Types range from internal-only (ClusterIP) to externally exposed (LoadBalancer), and an Ingress adds HTTP routing on top. The pattern mirrors classic load balancing and service discovery — Kubernetes just makes it declarative.

Kubernetes is declarative: you don't issue commands ("start a pod on node 3"), you declare desired state ("I want 4 replicas of this running") and store it in the cluster. Then controllers run a continuous reconciliation loop: observe the actual state, compare it to the desired state, and take action to close any gap — forever.

This is why Kubernetes self-heals: a pod crashes, actual drops below desired, the controller notices the mismatch and creates a replacement — no human, no alert-driven fix, just the loop converging. Scaling, rollouts, and recovery are all the same loop chasing whatever state you declared.

When a new pod needs to run, the scheduler decides which node it lands on. It filters nodes that can't fit the pod (not enough CPU/memory, missing constraints) and scores the rest to pick a good home, balancing the cluster. You can influence it with resource requests/limits (how much CPU/memory a pod needs), node affinity (prefer/require certain nodes), and taints/tolerations (keep pods off, or allow onto, special nodes).

Getting resource requests right matters: request too little and pods get packed and starved; too much and you waste the cluster. The scheduler is the piece that turns "run this pod" into "run it here," and it's how Kubernetes uses a fleet of machines efficiently.

A few more pieces complete the picture. ConfigMaps and Secrets inject configuration and credentials into pods so images stay generic and environment-specific values live outside them. Health probes let Kubernetes know a container's real state: a liveness probe detects a hung container and restarts it; a readiness probe detects one that isn't ready to serve yet and holds traffic back until it is (crucial during startup and rollouts).

And autoscaling closes the loop on load: the Horizontal Pod Autoscaler (HPA) watches metrics like CPU and adds or removes replicas to match demand, while cluster autoscaling can add or remove nodes. Combined with self-healing, you get a system that repairs and resizes itself — the payoff for describing everything as desired state.

Kubernetes is powerful, and it's complex — a real operational surface with its own failure modes, upgrades, and learning curve. It earns that cost when you run many services across many machines and genuinely need automated scaling, self-healing, rolling deployments, and service discovery working together. At that scale, doing it yourself is worse.

But for a single app or a handful of services, Kubernetes is often over-engineering. A managed platform (PaaS), serverless functions, or simple container hosting will ship you faster with far less to operate, and you can adopt Kubernetes later if scale demands it. The honest question isn't "is Kubernetes good?" (it is) but "does my system have the scale and complexity that justify its complexity?"