One city control-plane node is NotReady, yet etcd still has quorum on remaining peers and clients reach the API through the load-balanced VIP. How should this partial failure be interpreted?
Select an answer to reveal the explanation.
Short Explanation
HA is like three cashiers and one shared queue number board (the VIP). One cashier's lane closes, but shoppers still check out if the others and the board stay up—fix that one node.
Full Explanation
In an HA municipal control plane, one NotReady control-plane node does not automatically equal total API loss. When etcd still has quorum on remaining peers and clients reach the API through the load-balanced VIP, interpret the failure as partial: surviving peers and the VIP keep serving while that node is repaired. Claiming any single control-plane NotReady always means total cluster API loss ignores HA design and contradicts the stem’s working VIP plus intact quorum. VIP access working does not prove etcd has no peers or is running solely inside kube-proxy; the VIP fronts apiserver endpoints and is unrelated to that false claim. NotReady on one control-plane node does not delete all PersistentVolumeClaims cluster-wide; PVC objects live in etcd and persist independently of one node’s Ready flag. Exam caveat: Confirm etcd member count and quorum math, and ensure VIP health checks remove the bad backend. Stacked control-plane topologies couple node loss to etcd member loss—yet with quorum stated intact, API service can continue. Operational check: Verify etcd endpoint health and member list, confirm VIP backends, repair the NotReady host’s static pods and certificates, and rejoin it only after civic API health checks pass.