Library Deployments no longer create or heal pods after replica changes, while existing running pods keep serving. Which component is most likely down?
Select an answer to reveal the explanation.
Short Explanation
Controllers are the building's autopilot: without kube-controller-manager, desired replica counts stop getting fixed even though today's running pods may still hum along. Scale or heal changes just sit there.
Full Explanation
Deployments and ReplicaSets reconcile through controllers in kube-controller-manager. When that component is down, existing running pods can keep serving library traffic, but creating, scaling, or healing pods after replica changes stalls because nothing is watching desired versus actual replica counts. That matches “no create/heal, existing pods fine.” kube-proxy does not create ReplicaSets; it implements Service clustering on nodes. Blaming kube-proxy confuses dataplane with workload controllers. CoreDNS is unrelated to Deployment reconciliation; controllers talk to the API server without needing DNS to resolve the apiserver for every replica fix. metrics-server feeds resource metrics for HPA and kubectl top; controllers do not refuse all Deployment reconciliation merely because live CPU samples are absent. Exam caveat: Other controllers (job, node, endpoint) also live in controller-manager—symptoms can be broader than Deployments. Still, the stem’s replica create/heal focus points squarely at controller-manager, not proxy/DNS/metrics. Operational check: Inspect kube-controller-manager static pod/logs and leader lease; restore it; change a Deployment’s replicas and confirm a new ReplicaSet/pod appears; verify civic namespaces resume self-healing after node or pod loss.