避免在升级至 etcd v3.6 时产生僵尸集群成员

概述

在维护基于 Kubernetes 的生产环境时，etcd 的版本升级是一项关键且需谨慎操作的任务。本文档聚焦于在从 etcd v3.5 升级到 v3.6 过程中可能遇到的一个特定风险：产生“僵尸集群成员”（Zombie Cluster Members）。这些是已被移除但又重新出现并加入共识的节点，会导致整个 etcd 集群不可用。理解此问题的根源并遵循正确的升级路径，是保障 etcd 可靠性、避免重大事件的关键 SRE 实践。

核心概念

僵尸集群成员 (Zombie Members)

僵尸成员是指那些在 etcd 集群元数据中已被标记为移除、不再参与共识的节点，但由于数据不一致问题，在升级或重启后意外地重新加入集群并尝试参与 Raft 共识。这会破坏集群的选举和日志复制过程，最终导致整个集群停止服务。

存储不一致：v2store 与 v3store

问题的根源在于 etcd 集群成员信息的两个存储位置：

  • v2store：etcd v3.5 及更早版本中，成员信息的真实来源（source of truth）。
  • v3store：etcd v3.6 起，成员信息的真实来源。

在某些历史操作或故障场景下，这两个存储中的成员列表可能变得不一致。当升级到 v3.6（以 v3store 为准）时，v2store 中残留的旧成员信息会导致僵尸成员“复活”。

安全升级路径

为解决此问题，etcd 社区在 v3.5.26 版本中引入了修复机制。官方推荐的唯一安全升级路径是先升级到 v3.5.26 或更高版本。该版本会自动检测并修复 v2store 与 v3store 之间的不一致，从而确保在后续升级到 v3.6 时不会出现僵尸成员。

实践

安全升级操作步骤

为确保 etcd 集群从 v3.5 平安升级到 v3.6，必须严格遵守以下步骤：

  1. 第一步：升级至 v3.5.26 将集群中所有 etcd 节点升级到 v3.5.26 或更高版本（如 v3.5.27）。这是整个升级流程中至关重要的一步，其目的是触发自动修复机制，同步 v3store 与 v2store 的成员数据。

  2. 第二步：等待并确认集群健康 在所有节点完成 v3.5.26 升级后，必须等待并验证集群完全健康。使用 etcdctl endpoint health 等工具检查每个成员的状态，确保它们均处于 healthy 且 leader 选举正常。此等待过程是为了让修复机制完全生效。

  3. 第三步：升级至 v3.6 在确认集群健康后，方可开始将集群升级到目标版本 v3.6.x。此时，由于成员数据已在 v3.5.26 阶段被修复，升级过程将是安全的。

重要提示：如果由于软件包或供应商原因，v3.5.26 版本暂时不可用，应推迟向 v3.6 的升级，直至能够获取到 v3.5.26 或更高版本。没有已知的安全绕过此路径的方法。

已知问题触发场景（供参考）

虽然遵循安全路径即可避免问题，但了解触发源有助于风险排查：

  • 旧版 etcdctl snapshot restore 工具缺陷 (v3.4)：恢复快照时未正确移除旧成员，导致成员信息残留。
  • 使用 --force-new-cluster 标志 (v3.5.22 之前)：强制创建单成员集群时，可能未完全清理旧成员信息。此问题已在 v3.5.22 中修复。
  • 启用 --unsafe-no-sync 标志：这可能导致成员变更只写入 v3store 而未写入预写日志，造成崩溃后数据不一致。此标志通常不推荐使用。

SRE 要点

  • 与可靠性的关联：etcd 是 Kubernetes 控制平面的核心数据库，其可用性直接决定了整个集群的可靠性。由升级操作引发的僵尸成员问题属于典型的“变更引发的故障”（Configuration Change Induced Failure），是 SRE 必须通过流程控制来预防的。严格的、分阶段的升级操作是变更管理中的最佳实践。
  • 与可观测性的关联：在执行升级操作前后，必须对 etcd 集群进行详尽的健康检查。这不仅仅是检查 etcdctl 的健康状态，还应监控集群的延迟、Leader 选举频率、磁盘 I/O 等 SLI。任何在升级后出现的异常指标都应触发调查，以确认是否遇到了此类数据不一致问题。
  • 最佳实践与常见反模式：
    • 最佳实践：始终阅读并遵循官方发布的、针对特定版本的升级指南。在计划窗口内进行升级，并分阶段在生产环境中推行（例如先在预发布环境验证）。升级路径中包含的验证步骤（如等待健康）与升级步骤本身同等重要。
    • 常见反模式：直接从低版本跳跃到高版本升级；忽略中间必要的过渡版本（如 v3.5.26）；在升级过程中引入其他未经测试的配置更改。
  • 相关指标 (SLI/SLO/SLA)：应为 etcd 服务定义明确的 SLO，例如：p99 的 API 请求延迟应低于 50ms、集群可用性应超过 99.9%。任何破坏此 SLO 的变更（包括版本升级）都应被视为高风险操作，并需要有详细的回滚计划。升级操作的成功与否，最终应以其不降低或能持续满足 SLO 为衡量标准。
  • 关联页面：etcd-overview， kubernetes-cluster-upgrade

总结：对于 etcd 的重大版本升级，SRE 的核心职责是规避风险。本次 etcd v3.5 到 v3.6 的升级路径清晰地表明，跳过关键的修复性中间版本（v3.5.26）会直接导致生产故障。因此，建立并严格执行包含版本依赖检查的升级手册，是保障基础组件可靠性的基石。