"Works on my laptop" ≠ "survives in prod." And you can verify almost all of that difference locally in k3d.
Probe behavior, restarts from liveness, how a rolling update proceeds, how the app shuts down on a signal — k3d reproduces all of it like a real cluster. Which means the traps get caught at your desk, not in prod on a Friday evening.
In the new article (part 13) we add, one at a time, the things that make a service resilient to the Deployment:
• requests/limits and the key distinction: CPU is throttled when exceeded (slows down), but memory is NOT compressible — the process gets killed, that's OOMKilled with code 137;
• the three probes and who does what: liveness restarts a hung container, readiness pulls the Pod out of endpoints (no restart, DB checks go here too), startup gives a slow start room to come up;
• QoS classes and who gets evicted first (BestEffort);
• graceful shutdown: why the app must catch SIGTERM, the race with endpoints, and the cure — a preStop sleep;
• zero-downtime rollout: maxUnavailable: 0 + maxSurge: 1, and why zero downtime is fundamentally impossible without readiness.
At the end — a prod-readiness checklist. Read it: https://dorokhovich.com/blog/local-k8s-making-it-production-like?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-making-it-production-like
Top comments (0)