OK, your service runs in the cluster locally — but what about the database, the queue, the cache? This is the chapter the previous ones deliberately put off.
Part nine of the series is about stateful dependencies. We stand up PostgreSQL, Redis, and RabbitMQ INSIDE the local cluster (Helm or a "raw" manifest), wire them into Tilt, and sort out PersistentVolumes, migrations, and seeding on startup. The point is parity: if the database lives in the same cluster with the same charts that ship to staging, you get unified DNS and service discovery for free (the app finds the DB by the name postgres, not localhost:5432), shared Secrets/ConfigMaps, and you catch manifest problems before prod — not on a Friday evening.
An honest warning, without which this chapter would do more harm than good: as of 2025-09-29 the public Bitnami images moved behind a paid Broadcom subscription, so blindly recommending bitnami/* in 2026 is no longer an option. What to do instead — Chainguard drop-in charts, official operators, or a deliberate pin to a legacy tag. For dev, the most predictable path is a "raw" manifest of three objects (Deployment + Service + PVC) with the official postgres:17 image.
Plus: the biggest surprise — in k3d data is ephemeral by default (fixed with --volume $HOME/...:/var/lib/rancher/k3s/storage@all), migrations as a separate Job (not in the app's initContainer — that's an antipattern), and when to mock a managed service (RDS/SQS) with LocalStack and when not to. https://dorokhovich.com/blog/local-k8s-dependencies-databases-queues?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-dependencies-databases-queues
Top comments (0)