直接回答：K8s 组件间全部走 mTLS：API server 证书、etcd 证书、kubelet 客户端证书、front-proxy、各 controller 的 kubeconfig。任一过期对应链路立刻 x509: certificate has expired 瘫痪——kubelet 证书过期节点 NotReady、etcd 证书过期控制面只读、API server 证书过期 kubectl 与所有 controller 失联。kubeadm 集群默认有效期一年，周年祭是经典事故。

展开解析：连锁反应按爆炸半径：API server 服务端证书——所有客户端（kubectl、controller-manager、scheduler、kubelet）连不上，集群“脑死亡”但工作负载还在跑；CA 本身过期（默认 10 年）——所有派生证书的信任根没了，等于全集群重签，最惨烈；kubelet 客户端证书——节点批量 NotReady 触发驱逐风暴；service account 的 token 签名密钥对——Pod 内访问 API 失败。监控：kubeadm certs check-expiration 定期跑接告警（剩 30 天黄牌）；blackbox 探测 API server 的 TLS 有效期；Prometheus 采集 apiserver_client_certificate_expiration_seconds 等内置指标。轮换方法：kubeadm certs renew all 加控制面组件重启（静态 Pod 自动重建）；kubelet 开了 serverTLSBootstrap/rotateCertificates 可自动轮换；生产最佳实践是自动化——cert-manager 管集群内服务证书，控制面证书用配置管理（Ansible）定期 renew；多云/托管集群由厂商托管但也要确认 SLA。事故后的恢复顺序：先恢复 CA 与 API server（kubectl 能连），再 etcd，再 kubelet——由内向外。预防性架构：关键证书有效期录入 CMDB 加日历提醒这种“笨办法”救过无数团队。

追问方向：轮换 CA 为什么不能直接换新？静态 Pod 的控制面组件如何触发重启生效？

（约 500 字）