A municipal parking citation API declares three replicas on OKE. One replica’s process exits unexpectedly. What does orchestration self-healing do so the declared count stays true?
Select an answer to reveal the explanation.
Short Explanation
Self-heal is like a spare tire that mounts itself. When a replica dies, the orchestrator starts another so the promised count is true again. Waiting for someone to SSH and restart is not self-healing.
Full Explanation
Declaring three replicas for the municipal parking citation API encodes a desired count the control plane must keep true. When one replica’s process exits, self-healing means the replica controller notices the live count dropped below desired and starts a replacement so the declared count is restored without waiting for a human. That loop is core to orchestration: desired versus actual, reconcile until they match. Paging an on-call engineer to SSH and docker start recreates the failed instance only when someone is awake, so the public API runs degraded until then—opposite of continuous reconciliation. Raising only a Monitoring alarm notifies people but leaves the replica count reduced; alarms observe, they do not create Pods. Rewriting the Deployment to zero replicas deliberately abandons the desired count and stops serving traffic, which is a manual outage choice rather than healing. Exam caveat: self-healing restores replica count for crash loops and node loss within policy, but a persistently failing image still crash-loops replacements until readiness and liveness probes and the image itself are fixed. Operational check: delete or kill one replica in a non-prod pool and confirm a new Pod appears and Ready endpoints return to three without manual docker start.