The Kubernetes inner dev loop is slow AND lies to you — here's why
If you've ever shipped a service to Kubernetes for the first time, you know the feeling: the edit→result loop that took a fraction of a second with uvicorn --reload suddenly takes 2–5 minutes, and code that "worked locally" dies in the cluster for reasons you never had to think about.
This is the opener of a new series on local Kubernetes development. It's a mental-model piece, not a tutorial — the goal is to name the two distinct problems most people blur together.
Key takeaways
-
The inner loop is the loop you crank dozens of times an hour: edit → build → run → check → fix, before you ever
git push. Keeping it in the seconds is what protects your flow. -
Kubernetes wedges four extra steps into that loop:
docker build, update manifest,docker push, apply and wait for the Pod. That's the 2–5 min/iteration tax — vs ~1–5 s with file-sync/hot-reload (a 95%+ reduction). -
The local cluster can't see images in your local Docker daemon. Skip the push/import step and you get a Pod stuck in
ImagePullBackOff. -
The
:latesttrap:myapp:latestdefaults toimagePullPolicy: Always, so the kubelet re-pulls every start. Use specific tags +IfNotPresent. -
Low fidelity is the other half of the pain: OOMKilled, CPU throttling, NetworkPolicy blocks, readiness failures, RBAC denials — a whole class of bugs invisible under bare
uvicornordocker compose. - Reframe shift-left as environment fidelity. As Testkube puts it: "testing earlier in a CI container that doesn't match your cluster isn't shift-left — it's just failing faster in the wrong environment."
The running example throughout the series is myapp: a Python 3.12 + FastAPI HTTP API on port 8080 that depends on PostgreSQL, run on a local k3d cluster.
Top comments (0)