Nobody knew which server the app was on. Kubernetes, explained with an apartment building

One day, one of Contoso's three app servers crashed due to a disk error. An on-call engineer found that four out of eleven containers running on the server were not listed on the wiki page, which had been last updated in March. One of those containers was responsible for payment callbacks, and for 50 minutes, customers were unable to pay and receive confirmations because nobody knew which server the payment callback container was on.

Nobody had been hacked; they simply ran 30 containers manually using shell scripts and a wiki page that was quickly out of date. TL;DR: the issue was that containers started manually had no owner, desired state, or memory. When a server went down, a human had to manually remember and restart the containers, hoping the version was correct.

Who was affected? Customers lost payments, the on-call engineer spent hours on archaeology, the business lost 50 minutes of downtime that could have been fixed automatically, and security secrets were stored in plaintext files without proper access controls. The solution was to define what was desired (3 copies of the web app, specific version, and configuration) and let Kubernetes manage it.

This could be done using a single file instead of a script and a wiki page. The cost of using Kubernetes on a laptop was free, while managed control planes on Azure, AWS, and Google cost about $0.10 per hour, or roughly $73 per month. A quick test showed that deleting a pod automatically replaced it with a new one within seconds.

Kubernetes is like an apartment building - the cluster is the building, nodes are the servers, and pods are the rooms. Deployments keep specified numbers of rooms occupied with specific versions, receiving traffic from services via services. Namespaces keep team and production environments separate using ConfigMaps for non-secret settings and Secrets for sensitive information.