Lesson 68: Workload Controllers — Deployments
What We’re Building Today
A production-grade log processing platform deployed on Kubernetes, demonstrating every deployment pattern you’ll encounter operating systems at Netflix/Spotify scale:
Three-tier microservices architecture — FastAPI log ingestor, Kafka-backed log processor, React analytics dashboard, all orchestrated through Kubernetes Deployments with full resource governance.
Zero-downtime rolling updates with surgical
maxSurge/maxUnavailableconfiguration and readiness gate enforcement — the same pattern Airbnb uses for their 1,500+ service fleet.ReplicaSet genealogy inspection — understanding why Kubernetes maintains multiple inactive ReplicaSets and what that costs you operationally.
HPA wired to Kafka consumer lag via KEDA, so your Deployment scales against actual queue depth rather than CPU — a pattern unavoidable at any serious message throughput.
Why This Matters
The Deployment controller is where Kubernetes shifts from container scheduling to declarative operational contract. You’re not telling Kubernetes how to start a process — you’re declaring the invariant state of an application across its entire lifecycle: how many replicas, what update strategy, when to halt a rollout, how to recover from a bad revision.
Teams that treat Deployments as “just a YAML wrapper around Pods” consistently hit the same failure modes: rollouts that silently break traffic, ReplicaSet proliferation consuming etcd quota, HPA thrash from misconfigured stabilization windows, and cascading restarts from readiness probes that pass at startup but fail under load. Understanding the Deployment controller’s reconciliation loop — and precisely where the guarantees end — is the operational competency that separates staff-level Kubernetes engineers from mid-level ones.
At Spotify, the shift to treating
maxUnavailable: 0as a default for stateless services reduced customer-facing error spikes during deploys by over 80%. That single parameter encodes a reliability contract.


