DEV Community

Gaberial Sofie
Gaberial Sofie

Posted on

I built a production-like local Kubernetes setup in 16 parts — here's the recap and where to grow next

#kubernetes #devops #tutorial #k3d

This is the capstone of a series on running a genuinely production-like local Kubernetes environment. The whole point was environment parity: catch manifest, RBAC, and service-discovery problems on your laptop instead of from a 3am alert.

What the setup is

k3d (k3s in Docker) cluster dev with a built-in registry -> a FastAPI image that's the same artifact prod ships -> real manifests (Deployment/Service/Ingress, not docker-compose) -> a fast inner loop via Tilt -> PostgreSQL alongside -> ConfigMap/Secret config -> liveness/readiness probes + requests/limits -> observed by hand via kubectl + k9s.

Three directions to grow (don't adopt all at once)

  • GitOps (Argo CD / Flux, both CNCF Graduated). Git becomes the single source of truth; an in-cluster controller reconciles reality toward it. Argo CD's edge for beginners is a rich web UI (the Application CRD as an object tree); Flux is the GitOps Toolkit (controllers, image automation, OCI) but has no native UI. Common pattern: Argo for apps, Flux for infra — but pick one.
  • Observability stack (kube-prometheus-stack, Prometheus Operator, OpenTelemetry). One Helm command gives you Prometheus + Grafana + Alertmanager + exporters; scrape your app with a ServiceMonitor CRD, no hand-edited Prometheus config. Honest caveat: this stack is heavy and can take down a weak k3d cluster — trim components or cap requests. OpenTelemetry unifies traces/metrics/logs (auto-instrumentation for FastAPI).
  • Remote-cluster tools (Telepresence, mirrord). For the hard cases where local can't hold all the dependencies. mirrord's key nuance is the incoming-traffic mode: mirror (your process gets a copy of traffic — safe on shared clusters) vs steal (your process intercepts the Pod's traffic — diverts others' requests, use carefully). Telepresence intercepts via a VPN/tun model (needs root + an in-cluster component).

The measured posture: here's the ladder, don't climb it all at once. Reach for remote-dev tools only when a local cluster genuinely can't handle the scenario.

Full article: https://dorokhovich.com/blog/local-k8s-conclusion-and-next-steps?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-conclusion-and-next-steps

Top comments (0)