etcd mTLS 证书轮换避坑

在自建 Kubernetes 集群的生命周期维护中，etcd 双向 TLS（mTLS）证书轮换是风险最高的操作之一。一旦证书信任链断裂或配置错配，不仅会导致 API server 无法读写集群状态，还可能造成 etcd 集群失去多数派法定人数（quorum），进而引发控制平面全面瘫痪。规避轮换过程中的服务中断风险，关键在于理解证书边界、维持严格的更新顺序，并在变更全程保障状态可验证与可回退。

信任链与证书边界错配

证书轮换最易发生的失误是破坏信任链的平滑过渡。etcd 涉及两条独立的通信链路：一类是 kube-apiserver 访问 2379 端口的客户端通信，另一类是 etcd 节点间在 2380 端口进行的 peer 通信。这两条链路通常具有不同的 CA 信任边界。

如果需要轮换根证书（CA），必须先实现双向信任过渡。常见故障通常出现在：API server 已经切换至仅信任新 CA，而 etcd 侧仍使用旧 CA 校验客户端证书；或者某个 etcd 节点的 peer 配置先于其他节点切断了对旧 CA 的信任。在替换文件前，必须确保信任库中预先注入包含新旧两套公钥的证书链，待所有组件完成证书更新后，再剥离旧 CA。

此外，证书的主体备用名称（SAN）配置不足是导致握手失败的隐蔽原因。新签发的服务端证书必须完整覆盖 API server 可能连接的所有 IP 地址与节点名称。若 SAN 缺少相应地址，客户端在完成握手时将直接报错拒绝连接。

滚动轮换的标准时序

在多节点集群中，etcd 依赖多数派机制维持共识，因此绝对禁止全量并发轮换。对于典型的三节点集群，任何时刻只能对单一成员执行变更，并应遵循清晰的时序推进：

• 变更前创建数据快照，并持久化存储在控制平面节点之外，确认当前所有成员健康状态与法定人数完好。
• 采用逐节点滚动方式替换证书。在 kubeadm 部署形态下，修改静态 Pod 清单会触发容器重建，这属于真实的进程重启而非热加载。
• 每次节点重启后，必须立即执行健康检查，确认其成功重新加入集群且 leader 选举稳定，方可推进下一个节点。
• 控制平面客户端证书的轮换应与 etcd 服务端解耦。更新 kube-apiserver 的客户端证书时，先确认新证书具备客户端认证用途，且其签发 CA 始终被 etcd 的 --trusted-ca-file 所受信。

验证与回滚底线

证书替换完成后，不能仅依靠进程监听状态判断服务可用性。应使用实际的客户端证书，通过工具主动发起针对 2379 端口的 TLS 握手测试，核对证书链验证状态；同时调用 API server 的健康检查路径，验证写路径是否畅通。

当轮换遇到不可逆的配置错误时，必须依靠预先准备的带外访问通道（如 SSH 登录）介入。首要处置是依据备份的静态 Pod 清单和历史证书快速回滚，恢复旧有通信信任，避免盲目尝试重置数据目录。快照恢复会生成新的数据目录与成员状态，属于灾难恢复动作，在证书轮换引发的通信中断中应作为最后的防线。保持变更记录的可核对性与可撤回性，是完成 etcd mTLS 证书平滑交替的根本保障。