There is a scene in Anna Karenina where Levin, frustrated by everything going wrong on his farm, sits down and realises that the problem is not the farm. The problem is that he has been applying the wrong mental model to it.
I thought about this scene last Tuesday at 2am while staring at a CrashLoopBackOff that made no sense.
The pod logs were clear. The configuration was correct. The resource limits were fine. And yet: crash, loop, back off, repeat.
The actual problem — which I found forty-five minutes later — was that I had been thinking about the pod as a single process when it was, in fact, two containers sharing a network namespace and fighting over the same port.
Wrong mental model. Classic Levin.
The literature-infrastructure parallel nobody asked for
I have been reading a lot of nineteenth-century Russian literature this year, alongside building out a small k3s cluster at home. It was not intentional. Both things just happened to need attention at the same time.
But the longer I spent inside both worlds, the more the resonances became impossible to ignore.
Tolstoy and Dostoevsky are both obsessed with one question: why do intelligent people make catastrophic decisions? The answer, consistently, is not stupidity. It is that they are operating from a flawed model of reality. They know the facts. They have the data. But the frame they are using to interpret that data is wrong.
Kubernetes is the same. The facts are in the logs. The data is in the metrics. But if your mental model of how pods, nodes, services, and namespaces relate to each other is incomplete — you will read the correct output and draw the wrong conclusion every single time.
The manual is the novel
The thing about both War and Peace and the Kubernetes documentation is that they reward rereading far more than first reads.
The first time you read War and Peace, you are tracking plot. The second time, you notice the philosophy. The third time, you realise the philosophy is actually about epistemology — about how we know what we know, and how wrong we usually are.
The first time you read the Kubernetes networking docs, you are trying to make your pod talk to another pod. The second time, you are trying to understand why your service is not routing correctly. The third time, you realise you have been misunderstanding what a ClusterIP actually does for eighteen months.
Both are documents that contain more than you can absorb on a single pass. Both require you to sit with them.
A thing I keep coming back to
In the epilogue of War and Peace, Tolstoy writes that history is not made by great men making decisive choices. It is made by millions of small, unconscious forces acting together in ways that no one planned.
I find this enormously comforting when a deployment fails in a way that technically should not be possible.
No one planned for the race condition. No single decision caused it. It was millions of small configuration choices, made by different people at different times, arriving simultaneously at a single catastrophic moment.
This does not make debugging easier. But it does make it feel less like personal failure.