Certificate expiration is approaching for kubeadm-managed certificates on a civic control plane. Which action reduces the risk of API outages due to expired certs?
Select an answer to reveal the explanation.
Short Explanation
Expired control-plane certs are like letting the building’s badge system lapse—suddenly nobody gets through the door. Renew with kubeadm’s certificate tooling before the calendar bites, and bounce the static pods that still clutch old files. Waiting until the API is already dark is a rough way to learn cert lifetimes.
Full Explanation
As kubeadm-managed certificates approach expiration on a civic control plane, renew them (for example kubeadm certs renew) before expiry and restart affected control-plane components as required. Expired control-plane certs are like letting the building badge system lapse—renew on the calendar, then bounce static pods still clutching old files. Deleting all of /etc/kubernetes/pki and rebooting so kubelet regenerates the cluster CA automatically is destructive and incorrect. Disabling client certificate authentication and switching the API to anonymous HTTP removes essential security controls. Extending only worker kubelet client certs ignores that control-plane serving certificates also expire under kubeadm. Exam caveat: Proactive renewal beats emergency outage recovery when apiserver TLS dies. Operational check: kubeadm certs check-expiration, renew needed certs, restart control-plane static pods/containers, and re-check expiration dates and API 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.