Kubernetes

A container packages your application and its dependencies into one runnable unit, usually built with Docker. One container is easy to run by hand. The problem starts when you have 200 containers spread across 30 servers and you need them to stay healthy, talk to each other, and survive a server crash at 3 AM without a human watching.

Kubernetes is the system that runs those containers for you. You tell it I want five copies of this web server, each with 512 MB of memory, reachable at this address. It finds machines with spare capacity, starts the containers there, and keeps five running. If one crashes, it starts a replacement. If a whole machine dies, it moves that machine's containers somewhere else. Nobody gets paged.

The word comes from Greek for helmsman. People shorten it to k8s, with the 8 standing in for the eight letters between k and s. Google released it as open source in 2014, based on an internal system called Borg, and it is now governed by the Cloud Native Computing Foundation.

A Kubernetes cluster has two kinds of machines. The control plane is the brain. It holds the API server that every command talks to, etcd which is a distributed key value store that records the entire desired and actual state of the cluster, the scheduler that decides which machine a new container should run on, and controllers that watch for differences between what you asked for and what is actually running. Worker nodes are the machines that run your containers. Each worker runs a kubelet agent that takes orders from the control plane and a container runtime like containerd that actually starts the containers.

The core idea is the reconciliation loop. You declare the desired state, for example three replicas of a Deployment. A controller constantly compares desired against actual. If only two pods are running, it creates a third. If four are running because of a stale request, it kills one. This control loop runs forever, which is why Kubernetes is described as declarative rather than imperative. You never say start a container, you say there should be three, and the system figures out the steps.

The smallest unit you deploy is a Pod, which is one or more containers that share a network address and storage. You rarely create Pods directly. Instead you create a Deployment, which manages Pods and handles rolling updates. A Service gives a stable address and load balances across the Pods behind it, because individual Pods get new IP addresses every time they restart.

Kubernetes pays off when you run many services that need to scale independently, self heal, and roll out updates without downtime. A team running 20 microservices across a fleet of servers gets real value from automated scheduling, rolling deployments, and health checks that would otherwise be hand rolled scripts.

It is overkill for a single application on one or two servers. The learning curve is steep, the YAML is verbose, and a real production cluster pulls in networking plugins, ingress controllers, monitoring, and secrets management. Many small teams are better served by a platform as a service like Heroku, Render, or Fly.io, or by a simpler container service like AWS ECS, where the orchestration is hidden from you.

The other cost is operational. Running your own cluster means patching, upgrading, and debugging the control plane, etcd backups, and certificate rotation. Most teams avoid this by using a managed offering such as Amazon EKS, Google GKE, or Azure AKS, where the cloud provider runs the control plane and you only manage worker nodes and your applications.

Say you run an online store. Black Friday hits and traffic jumps ten times. You set a HorizontalPodAutoscaler that watches CPU usage on your checkout service. When average CPU crosses 70 percent, Kubernetes adds more Pods, up to a limit you set, say 50. When traffic drops that night, it scales back down to 5 so you stop paying for idle machines.

During the sale you also ship a bug fix. You update the Deployment with a new container image. Kubernetes does a rolling update: it starts new Pods with the fixed code, waits for each to pass its health check, then removes old Pods one at a time. If the new version starts crashing, you run a one line rollback and it returns to the previous image. Customers never see an error page, and you did all of this by editing a few lines of YAML rather than by SSHing into servers.