第2章：コントロールプレーン設計
Control Plane はクラスタの制御系であり、API の可用性・整合性・運用性を左右します。本章では、HA 構成と運用観点を整理します。
学習目標
- Control Plane の主要コンポーネントと障害モードを説明できる
- マネージド/自前運用で設計責任がどこにあるかを整理できる
- 監視/ログ/復旧の観点で Control Plane を運用設計できる
扱う範囲 / 扱わない範囲
扱う範囲
- API Server/Controller/Scheduler/etcd の役割
- HA の基本パターン（マルチ Control Plane、etcd トポロジ）
- API まわりの運用（認証、監査、レイテンシ、証明書）
- マネージドと自前運用の差分（責任範囲）
扱わない範囲
- 特定プロバイダの構築手順
- KMS/外部 IdP 等の詳細な製品設定
定義（この章の用語）
- Control Plane（コントロールプレーン）: Kubernetes の制御系（API Server / Controller / Scheduler / etcd 等）
- HA（High Availability）: 単一障害点を排除し、障害時もサービスを継続できる状態
背景（なぜ重要か）
- Control Plane は「クラスタを操作できるか」を左右します。障害時は復旧作業そのものが阻害されます。
- マネージド/自前運用で責任範囲が異なります。責任分界が曖昧だと監視/復旧の抜け漏れが発生します。
手順/例：設計の進め方（型）
- API の SLO（可用性/レイテンシ）を定義する（後述: 「Control Plane の可用性をどう定義するか」）
- 責任範囲（マネージド/自前運用）を整理し、運用対象を棚卸しする
- HA パターンを選択し、復旧手段（バックアップ/リストア、代替策）まで含めて設計する（後述: 「HA パターン（概略）」）
- 監視/ログ/復旧を運用物（Runbook、チェックリスト、演習計画）として整備する（第3章、第9章、付録A）
Control Plane の可用性をどう定義するか
設計の起点は「API の SLO」です。
- 可用性:
kubectlが使える/使えないだけでなく、API エラー率を定義する - レイテンシ: 運用上許容できる API 応答時間（P95/P99 等）を定義する
- メンテナンスウィンドウ: 変更ができない時間帯の制約を明文化する
HA パターン（概略）
マネージド Kubernetes
- Control Plane の HA はプロバイダが提供することが多いです。
- 利用者側は「アップグレードポリシー」「メンテナンスイベント」「監査ログ」「API 監視」等の運用を設計します。
自前運用（kubeadm 等）
- 複数 Control Plane ノード + ロードバランサを基本とします。
- etcd は stacked / external の選択が必要です。
- 証明書更新、バックアップ、復旧手順が必須です。
注意点（運用）
kubectl get --raw='/readyz?verbose'等の参照は、環境により権限や到達性の制約があります（要確認）。- etcd のバックアップがあっても、リストア手順と演習がない場合は復旧できません（第3章）。
- 重大障害時は「変更凍結」「読み取り専用運用」等の暫定方針を先に決め、拙速な操作で影響を拡大させないようにします。
実務チェック観点（最低5項目）
- API SLO（可用性/レイテンシ）と監視指標が定義されている
- etcd のバックアップ/リストア手順があり、演習されている
- 監査ログ（audit）/認証ログの保持とアクセス権が定義されている
- Control Plane のアップグレード/メンテナンスに伴う影響評価手順がある
- 重大障害時の暫定復旧（変更凍結、読み取り専用運用等）の方針がある
よくある落とし穴
- API の可用性を曖昧にし、監視と復旧設計が不足する
- etcd のバックアップはあるが、リストア演習がなく実効性がない
まとめ / 次に読む
- 次に読む: 第3章：etcd設計とバックアップ