Kubernetes and Containers

A container is not a thing. There is no container object in the Linux kernel. What there is: a process, started with some namespaces of its own, with its filesystem root moved, and with limits attached through cgroups. Docker is a very good user interface over those three primitives.

That is not trivia. It is the difference between guessing and knowing when a pod will not start, and it is why this series begins by building a container runtime in about 150 lines of Go using nothing but the standard library. Once you have watched a PID namespace make your process think it is PID 1, docker run stops being magic, and so does everything Kubernetes layers on top of it.

Kubernetes is a loop, not a deployer

The second idea worth having before the syntax: Kubernetes does not run your application. It runs a reconciliation loop. You declare the state you want, controllers compare it against reality, and they act to close the gap. That is the whole model, repeated for every kind of object.

Everything people find surprising falls out of it:

• Deleting a pod does not delete it. If a Deployment says three replicas, the controller notices two and creates a third. “Self-healing” is just the loop doing its job.
• kubectl apply is not a command that runs, it is a statement of intent. The command returning success means the desired state was recorded, not that anything is working.
• Services exist because pod IPs change. A pod is disposable and its address goes with it, so the stable thing has to live somewhere else.

The fundamentals article teaches this on a local kind cluster, which is the right place to learn it — no cloud account, no bill, and you can delete the whole thing and start again.

CrashLoopBackOff is not an error

It is the single most-searched Kubernetes failure and the name misleads people. CrashLoopBackOff means the container has exited repeatedly and the kubelet is now waiting longer between restarts. It is the backoff, not the fault. The fault happened before it, and by the time you look, the logs you want belong to a container that is already gone:

kubectl logs <pod> --previous

That flag is most of the diagnosis. The rest is a short list of causes worth memorising, and the article works through all six: the app crashing on startup, missing config, a liveness probe that fails before the app is ready, OOMKilled — exit code 137, a wrong command or entrypoint, and a dependency that is not up yet.

Exit code 137 deserves its own line. It means the kernel killed the process for exceeding its memory limit. No application error, no stack trace, nothing in the logs — which is exactly why people spend an afternoon on it.

The expensive mistakes are architectural

The technical failures cost you an afternoon. The ones in What Teams Got Wrong About Kubernetes in 2025 cost quarters: a service mesh installed for a problem nobody had, autoscaling configured for traffic that never arrived, Helm charts nobody read running with cluster-admin, an internal developer platform built for six engineers.

They share one root cause, which the article names as the meta-mistake: adopting the solution to a problem you have not got yet, because it is what large organisations do. Kubernetes rewards that instinct badly — every component you add is a component you now operate.

Worth reading early, not last, because the cheapest version of that lesson is somebody else’s.

How to read this

New to all of it: Docker Compose first — multi-container on your laptop, no orchestrator — then Kubernetes fundamentals on a local cluster. Do not start on EKS. You will spend your attention on IAM and VPCs instead of on Kubernetes.

Comfortable with Docker, new to Kubernetes: fundamentals, then the kubectl cheat sheet as a working reference, then EKS with eksctl when you want a real cluster.

Already operating a cluster: the two that will earn their time are CrashLoopBackOff — for the mental model, even if you know the flag — and the 2025 mistakes.

Curious how it works underneath: Containers From Scratch in Go is the most interesting article in this series and it needs a Linux machine, since it uses namespaces and cgroups directly.

What you need

Docker, and kind or Docker Desktop for a local cluster. kubectl and eksctl plus an AWS account for the two EKS articles — and read their cleanup sections, because an EKS control plane bills by the hour whether or not anything is running on it. The from-scratch article needs real Linux; the rest are fine on macOS.