Deployment Controller
System Analysis
Normal Behavior
Observes changes to application manifests, manages rolling updates and canary releases according to surge and unavailability constraints, orchestrates ReplicaSet creation and pod scheduling, verifies container readiness probes, and cleanly drains legacy instances.
Failure Behavior
A newly deployed container image with a crashing startup dependency triggers an immediate CrashLoopBackOff cycle, cascading across the cluster nodes, exhausting worker CPU/memory reserves, and evicting healthy workloads.
Business Consequence
Misconfigured readiness probes and surge parameters cause the deployment controller to abruptly terminate healthy pods before new instances are capable of serving traffic, resulting in 502 Bad Gateway cascades and significant downtime during peak operational hours.
Visual Manifestation
"Kubernetes events spamming 'CrashLoopBackOff' and 'Unhealthy' while the replica count bounces chaotically between desired and zero."
Satirical Behavior
"A ruthless robot manager that fires the entire old staff before the new staff has even figured out how to open the front door."
Technical Terminology
Failure Indicators
System Architecture (Graph)
FAQ
How does it normally behave?
Observes changes to application manifests, manages rolling updates and canary releases according to surge and unavailability constraints, orchestrates ReplicaSet creation and pod scheduling, verifies container readiness probes, and cleanly drains legacy instances.
How does it fail?
A newly deployed container image with a crashing startup dependency triggers an immediate CrashLoopBackOff cycle, cascading across the cluster nodes, exhausting worker CPU/memory reserves, and evicting healthy workloads.
What is the business consequence?
Misconfigured readiness probes and surge parameters cause the deployment controller to abruptly terminate healthy pods before new instances are capable of serving traffic, resulting in 502 Bad Gateway cascades and significant downtime during peak operational hours.
What is a Deployment Controller and how does its declarative reconciliation loop operate?
In container orchestration platforms (like Kubernetes), a Deployment Controller is an autonomous control loop that continuously compares the desired state described in deployment manifests (e.g., image tag, replica count, resource limits) against the actual live cluster state. If a disparity exists—such as a developer updating a container version or a node failure destroying two pods—the controller executes actions (creating new ReplicaSets, provisioning replacement pods, and draining old pods) until actual state matches desired state.
How do misconfigured readiness probes and improper maxSurge / maxUnavailable settings cause rolling update outages?
If maxUnavailable is set too high (e.g., 50% or 100%), the controller terminates running healthy pods before new replicas are proven operational. If readiness probes are pointed to slow external dependencies (like an overloaded database), new pods fail health checks and get stuck, leaving the application with insufficient capacity. To ensure zero-downtime rolling deployments, configure maxUnavailable: 0, set a moderate maxSurge: 25%, and implement fast, localized readiness probes that verify internal application readiness independently of external dependencies.
Explore the system
AI Summary
Deployment Controller is a DELIVERY_AND_PLATFORM system in TinyCTO.tv. Observes changes to application manifests, manages rolling updates and canary releases according to surge and unavailability constraints, orchestrates ReplicaSet creation and pod scheduling, verifies container readiness probes, and cleanly drains legacy instances.