"But I've got a docker-compose.yaml, it spins up my service with a database — why would I run Kubernetes locally?"
This is the most common beginner misconception, and it's an expensive one. A Compose file is structurally NOT equivalent to Kubernetes manifests, and "works in compose" guarantees nothing about "works in k8s." Just look at the official Kompose converter, whose authors honestly warn you: depends_on is ignored, build: won't build an image, bind-mounts don't carry over, and the output is manifests with NO requests/limits, NO probes, and environment variables in plain text instead of a Secret. In other words, exactly the production-like properties we spin up a local cluster for are the ones Compose skips.
Part two of the local Kubernetes series is the philosophical one. What does "production-like environment" even mean? It's NOT "an exact copy of prod" (that won't fit on a laptop) — it's a deliberate narrowing of the dev/prod gap: the same Kubernetes minor version, the same type and version of backing services (PostgreSQL, not SQLite — hello, factor X of the Twelve-Factor App), real manifests, requests/limits, probes, ConfigMap/Secret, Ingress. And we deliberately simplify scale, managed services, and load testing.
The core idea: a production-like environment isn't one where "everything is like prod," it's one where you know EXACTLY what matches, what doesn't, and why. At the end — a checklist: "how close is my local setup to prod?" https://dorokhovich.com/blog/local-k8s-production-like-environments?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-production-like-environments
Top comments (0)