Before a weekend control-plane upgrade, a city platform team wants durable recovery for cluster state. What lifecycle action should they take?
Select an answer to reveal the explanation.
Short Explanation
Upgrades without an etcd snapshot are like remodeling without photos of the wiring—good luck putting it back. Grab a snapshot of etcd before you touch the control plane so the API object world can be restored if Friday goes sideways. App YAML exports help, but they are not the same as the cluster’s source of truth in etcd.
Full Explanation
Before a weekend control-plane upgrade, a city platform team should take an etcd snapshot (for example etcdctl snapshot save) so cluster API state can be restored if the change fails. Upgrades without a snapshot are like remodeling without photos of the wiring—application YAML exports help, but etcd is the live source of truth for objects. Exporting only Deployment YAML is not a full cluster backup of Secrets, leases, RBAC, and other live objects. Snapshotting worker root disks only misses that control-plane object state lives in etcd, not exclusively on each kubelet. Copying /var/log/pods into object storage cannot recreate etcd contents from logs. Exam caveat: etcd snapshot ≠ Git manifest export; both may be useful, but snapshot is the datastore recovery point. Operational check: etcdctl snapshot save to secure storage, verify snapshot status, proceed with upgrade, and keep restore steps rehearsed in the municipal runbook. 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.