Docker Proves Your App Runs. Kubernetes Proves It's Operable.
A deep dive into why your container works smoothly on Docker but fails on Kubernetes, explained through core architectural differences.
Stock photo for illustration only, not from the actual event
- At 2:47 AM, the pod says Running, but curl requests return a timeout.
- The exact same container image worked on the first try locally via docker run.
- Docker performs a minimal job of starting a process and mapping a port without checking for scaling robustness.
- Kubernetes forces applications to handle network discovery and lifecycle management autonomously.
It is 2:47 AM. The pod says Running. The logs are clean, no stack trace, no red text, nothing you can grep. kubectl get pods shows 1/1. Everything about this deployment is, technically, fine.
You curl it from your laptop and get a timeout. You curl it from inside the cluster and get connection refused. You exec into the pod and the process is sitting right there, listening, apparently healthy. You built this exact image, ran it locally three hours ago with docker run, and it worked the first try. Nothing in the code changed between then and now. Only the environment did.
Before diving in, the author spent the last three months working inside a terminal, laptop, and mobile via Termux, testing real DevOps and Linux workflows on a phone, while also exploring contributions to the Kubernetes documentation. This topic comes straight from weeks of debugging in terminal tabs rather than chasing engagement.
If you have shipped anything to Kubernetes, you already know that 2:47 AM moment. And if you have googled your way out of it, you have read variations of the same advice: bind to 0.0.0.0 instead of 127.0.0.1, add a readiness probe, stop using localhost, check your ConfigMap. All of that advice is correct. None of it sticks, because it is merely a list of symptoms dressed up as an explanation.
As engineers transition applications from local development to production clusters, understanding the operational boundaries of container runtimes versus orchestrators is critical. The gap in behavior highlights that orchestration platforms demand design patterns resilient to dynamic network topologies and automated lifecycle events.
Here is the actual explanation, in one sentence:
Docker proves your app runs. Kubernetes proves your app is operable.
Everything else in this piece is just that sentence, said four different ways, until it stops being a slogan and starts being how you actually debug.
- Docker has a tiny job: start a process, map a port, and done without worrying about service discovery.
- Kubernetes is not a stricter Docker; it is the first environment forcing your application to answer critical infrastructure questions on its own.
- Localhost inside a Kubernetes pod points to the pod itself, not another external service on the same network bridge.
- When a container process becomes PID 1, Linux kernel rules dictate that default signal behaviors like SIGTERM are ignored unless explicitly handled.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment