Kubernetes 本番運用における etcd 分断の兆候と復旧手順:実運用からの教訓

etcd 分断が起きる典型的なシナリオ

etcd 分断は、クラスタメンバー間のネットワーク接続が一時的に途絶える、あるいは fsync が遅延して Raft のログレプリケーションが遅れる状況で発生する。CoreOS 時代からの etcd 公式ドキュメントには、5 ノードクラスタで 2 ノード同時障害までを許容する Quorum 要件が明記されており、この境界を超えると書き込み不能状態が続く。

Kubernetes 環境で etcd 分断が顕在化する主な状況は 3 パターンある。1 つ目は、ホスト側の高負荷 (I/O 飽和・NUMA を跨ぐスケジューリング) による fsync 遅延。2 つ目は、control-plane 用ネットワークの一時的な断絶——ゾーン間通信の障害で発生する。3 つ目は、etcd DB サイズが実質的な上限 (デフォルト 8 GB) に近づいたことによる compaction 遅延と、それに続くリーダー交代の連鎖である。

分断の予兆:数日前から出ている 3 種のメトリクス

実運用の経験からは、分断が突発的に起きるように見える多くのケースで、実際には数時間から数日前に予兆メトリクスが変化している。まず etcd_server_leader_changes_seen_total の増加。健全なクラスタではこの値は数週間で変化しない。1 日で複数回増えているクラスタは、リーダーの安定性が失われつつある。

次に etcd_disk_wal_fsync_duration_seconds の 99 パーセンタイル。100 ms を超える状態が持続するクラスタは、Raft のログレプリケーションが遅延しやすく、リーダー選出のタイムアウト (デフォルト 1 秒) を突破しやすい。もっとも、これは短時間のスパイクでは判断せず、10 分以上の移動平均で観察する必要がある。

最後に DB サイズ。etcd_mvcc_db_total_size_in_bytes がクォータ上限 (デフォルト 2 GiB、Kubernetes 環境では 8 GiB に拡張することが多い) の 60% を目安として超えると、実運用の観察では compaction 遅延が発生しやすくなる傾向があり、これがリーダー選出遅延の遠因になる。ただし、DB サイズと分断の関係は間接的で、直接的な原因ではなく複合要因の 1 つと捉えるほうが実態に即している。

復旧手順の失敗パターン

分断発生後、経験の浅いオペレーターが陥る失敗パターンとして、片側のクラスタを「アクティブとみなして書き込みを許可する」判断が挙げられる。Quorum を失ったクラスタから強制的にメンバーを削除して過半数を回復させる操作 (etcdctl member remove) は、正しい手順で行わないと、双方のパーティションで書き込みが継続する状態——本来の split-brain——を発生させる。

正しい復旧手順は、原則として次の順序である。第 1 に、書き込みを完全に停止する。第 2 に、健全なスナップショットから新しいクラスタを構築する。第 3 に、Kubernetes API サーバーの向き先を差し替える。第 4 に、旧クラスタのプロセスを停止する。この順序を守れば、二重書き込みは物理的に発生しない。

スナップショットが古い、あるいは取得されていない場合、上記手順は現実的でない。そのため、スナップショット運用 (通常は 1 時間ごとに Object Storage へアップロードし、直近 24 時間分を保持) は、etcd 運用における最重要の予防措置である。イベント駆動ワークフローにおける冪等性の設計パターンで扱う冪等性の考え方は、復旧後のイベント再送処理でも重要になる。

アーキテクチャの観点からの再発防止

復旧手順の整備は当然必要だが、それだけでは根本的な解決にならない。長期的には、ホスト側の I/O 性能を確保する (SSD の分離、fsync 経路の隔離)、etcd 専用ネットワークを構築する、そして DB サイズを定期的に圧縮する運用を組織的に導入する必要がある。

また、コントロールプレーンの複雑性を増やす追加コンポーネント——たとえばマルチクラウド環境におけるサービスメッシュ選定で扱うサービスメッシュの CRD——は etcd への書き込み量を増やす。導入前に etcd の負荷分析を行う姿勢は、実運用における基本動作として組織に定着させたい。

etcd 分断は防ぎきれない障害ではなく、予兆観察と復旧手順の熟練で被害を最小化できる領域である。基幹刷新のような大規模プロジェクトの失敗パターンと同様、対応の質は「その場の判断力」よりも「事前準備の徹底度」に強く依存する。