Loutresのメモ

etcd v3.5.26: 3.5→3.6 アップグレード前提修正

4 min read

概要

LWKD（Week Ending 2025-12-14 / 掲載ページ 2025-12-18）で紹介された **etcd v3.5.26（2025-12-17）**は、etcd 3.5 系の保守リリースであり、3.5 → 3.6 のアップグレードでクラスタが壊れうる「zombie members」問題に対する“事前修復（前提修正）”が含まれます。

変更内容（何が変わったか）

  • etcd v3.5.26 では、v2store と v3store のメンバー情報の不整合によって v3store 側に残ってしまった zombie member を、サーバが検出してクリーンアップ（削除）する仕組みが追加されました（PR #20995）。
  • 具体的には、v2store には存在しないのに v3store には存在するメンバーを「zombie」とみなし、v3store（バックエンド）から削除する処理が入っています。
  • CHANGELOG でも “Fix zombie members in v3store” として v3.5.26 の変更点に明記されています。
  • 併せて、依存関係更新（例: Go 1.24.11 でのビルド、golang.org/x/crypto 更新と CVE 対応）や、etcdctl snapshot restore のタイポ修正も入っています（CHANGELOG）。

背景（なぜこの変更が必要か）

  • etcd v3.5 以前では、クラスタメンバーシップの「正」は v2store 側で、v3store も併存していました。
  • v2store 廃止計画の一環として v3.6 では v3store がメンバーシップの source of truth になります。
  • その結果、古いクラスタ等で v2store と v3store のメンバー情報がズレていると、3.6 へのアップグレード後に「過去に削除したはずのメンバー」が復活したように見え、合意形成に影響して クラスタが操作不能になる可能性があります（Issue #20967 / etcd blog）。

影響（運用者/利用者/開発者への影響、注意点、移行）

  • Kubernetes では 全てのクラスタデータが etcd に保存されるため、etcd のメンバーシップ破綻はコントロールプレーン障害に直結し得ます。
  • etcd 3.5 → 3.6 を予定している場合、公式ガイドおよび SIG etcd の案内として、まず 全メンバーを 3.5.26 以上へ更新し、健康状態を確認してから 3.6 に進むことが推奨されています。
  • 3.5.26 に更新できない事情があるなら 3.6 へのアップグレードを延期すべき、という立場も明示されています（etcd blog）。
  • 運用上は、アップグレード作業前に Kubernetes 側の観点でも バックアップ（スナップショット）計画を再確認しておくのが前提になります。

用語メモ（用語の軽い説明）

  • zombie member: 過去に削除したはずの etcd メンバーが、ストア不整合の影響でアップグレード後に“復活”して見える（参加しようとする）状態/そのメンバー。
  • v2store / v3store: etcd 内部に併存してきたストア。v3.5 以前はメンバー情報の基準が v2store 側にあり、v3.6 で v3store が基準になる。
  • snapshot（スナップショット）: etcd のデータをファイル化したバックアップ。障害時の復元に使う。
  • Raft ConfChange: Raft の設定変更（メンバー追加/削除等）を表すログエントリ種別。

参考リンク

グラフビュー

バックリンク