Parks platform validates that API service continues while one control-plane node is drained for patching. Under what HA condition is this safe?
Select an answer to reveal the explanation.
Short Explanation
Rolling a control-plane node is fine when the rest of the choir can still hit majority—and clients keep dialing the VIP. Drain one brain, patch it, bring it back, while quorum holds. Do that on a lonely single-member etcd and you’ve scheduled an outage.
Full Explanation
Parks platform can drain one control-plane node for patching safely when remaining etcd members still form majority quorum and other apiservers remain reachable via the HA endpoint. Rolling a brain is fine when the rest of the choir still hits majority and clients keep dialing the VIP. Cordoning all workers at the same time as the control-plane drain is unnecessary and harmful to workloads. Any single etcd member existing is not enough—quorum size and survivors matter. Scaling Ingress controllers to zero is unrelated to whether control-plane quorum survives maintenance. Exam caveat: Same drain on a non-HA single control plane schedules an API outage. Operational check: Confirm 3+ healthy etcd members, drain one CP node, patch/reboot, verify API via VIP throughout, then uncordon/rejoin membership health. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.