第3章：etcd設計とバックアップ
etcd は Kubernetes のクラスタ状態を保持する基盤であり、障害時の復旧性と性能に直結します。本章では、トポロジ選択とバックアップ/リストアの運用観点を整理します。
学習目標
- etcd の役割と、障害時に起きる影響を説明できる
- トポロジ（stacked / external）選択の論点を整理できる
- バックアップ/リストアを運用物として定義し、演習計画を立てられる
扱う範囲 / 扱わない範囲
扱う範囲
- etcd の役割（状態保存、整合性）
- トポロジの選択（stacked / external）
- バックアップ（snapshot）とリストアの考え方
- 運用指標（容量、レイテンシ）とアラート
扱わない範囲
- etcd の詳細なチューニングパラメータの網羅
- すべての障害シナリオ
定義（この章の用語）
- snapshot: etcd の特定時点の状態を保存したもの（バックアップの代表的な手段）
- RPO/RTO: 目標復旧時点/目標復旧時間。バックアップ頻度と復旧手順の要件になります。
背景（なぜ重要か）
- etcd が劣化すると API 全体が遅くなり、障害対応や運用作業が進まなくなります。
- 「バックアップがある」だけでは不足で、復旧できること（リストア演習と所要時間の把握）が必要です。
etcd が持つもの
- Kubernetes API オブジェクト（metadata/spec など）
- 状態変更の履歴（watch 等に影響）
注意:
- 大きすぎるオブジェクトや高頻度の書き込みは、etcd に負荷をかけます。
トポロジ選択（概略）
stacked etcd
- Control Plane ノード上で etcd を動かします。
- 構成が単純ですが、障害ドメインが近くなります。
external etcd
- etcd クラスタを Control Plane と分離します。
- 障害分離はできますが、運用対象が増えます（監視、バックアップ、証明書等）。
手順/例：バックアップ/リストア運用の型
- RPO/RTO を前提に、バックアップ頻度と保持期間を決める
- バックアップの取得（自動化）と成功判定（監視/アラート）を用意する
- 保管先を分離し、暗号化とアクセス権を標準化する（単一障害点を避ける）
- リストア手順を Runbook 化し、検証環境で定期的に演習して所要時間を記録する
バックアップ/リストア（運用観点）
- バックアップの頻度（RPO）と保持期間
- 取得方法（スナップショット、暗号化、保管先）
- リストア手順（検証環境での演習）
- 復旧手順とエスカレーション
注意点（運用）
- リストアはクラスタ停止を伴う場合があります。実施条件、影響範囲、判断責任者を事前に定義してください（要確認）。
- バックアップの保管先（オブジェクトストレージ等）も障害します。可用性とアクセス制御を設計に含めます。
- トポロジ（stacked / external）の選択は、障害分離と運用負荷のトレードオフです。組織の運用体制に合わせて決めます。
実務チェック観点（最低5項目）
- RPO/RTO とバックアップ頻度が整合している
- バックアップの保管先が単一障害点になっていない
- リストア演習が定期的に実施され、所要時間が記録されている
- etcd の容量/レイテンシに基づくアラートがある
- バージョンアップ時の互換性と手順が定義されている
よくある落とし穴
- バックアップは取っているが、リストア手順がない/演習がない
- etcd 容量の監視がなく、上限に近づいてから気付く
まとめ / 次に読む
- 次に読む: 第4章：ノード/ランタイム運用