第12章：自動化と運用標準化

クラスタ運用は、テナント数・変更頻度が増えるほど「手作業」では破綻します。
本章では、Desired State（あるべき状態）をコードとして管理し、標準（テンプレ/ポリシー/変更管理）を自動適用するための論点を整理します。

学習目標

運用標準の対象（何を標準化するか）と、単位（クラスタ/環境/テナント）を定義できる
Git を source of truth とする変更フロー（レビュー、検証、適用、ロールバック）を設計できる
GitOps/IaC/Policy as Code の役割分担と導入順序を説明できる
ドリフト（手動変更）を抑止し、証跡を残す運用に落とし込める

扱う範囲 / 扱わない範囲

扱う範囲

標準化の範囲（namespace、RBAC、PSS、Quota、アドオン、監視/ログ、バックアップ）
GitOps の基本（差分適用、ドリフト検知、環境昇格、ロールバック）
IaC による基盤管理（クラスタ/周辺インフラの変更管理）
Policy as Code（ガードレールとしてのポリシー適用）

扱わない範囲

特定ツール（Argo CD/Flux/Terraform 等）の詳細手順
組織論（体制/予算）そのものの設計

何を標準化するか（例）

「標準化すると運用コストが下がるもの」から着手します。

テナント払い出し: namespace、RBAC、PSS、Quota/LimitRange（第7章/第8章）
監視/ログ: 最小ダッシュボード、アラートの重要度、Runbook 連携（第9章/第11章）
復旧: バックアップ、復旧演習、証跡（第3章/付録A）
変更管理: アップグレード計画、検証、ロールバック/中断条件（第10章）

GitOps（Desired State の運用）

GitOps は「Git を正（source of truth）として、クラスタの状態を収束させる」運用モデルです。
重要なのはツールではなく、変更フローと責任分界です。

変更フロー（最小）: 1) 変更提案（PR）
2) レビュー（Code Owners、セキュリティ/運用観点の承認）
3) 自動検証（静的チェック、差分確認、ポリシー検証）
4) 適用（段階適用、canary、実施ログ）
5) 検証（smoke test、SLO 影響確認）
6) ロールバック（手順と判断基準を定義）

リポジトリ構成は一例として、以下の分離が実務的です。

clusters/（環境別の差分: prod/stg）
addons/（CNI/CSI/Ingress、監視/ログ等の基盤）
tenants/（namespace、RBAC、Quota などの払い出しテンプレ）

IaC（基盤とライフサイクル管理）

クラスタ運用は Kubernetes だけで完結せず、周辺（ネットワーク、IAM、ストレージ、DNS/LB）と一体です。

IaC は「周辺インフラ」を含む変更の再現性と証跡を担保します。
GitOps は「クラスタ内リソース」の継続的な収束に向きます。

両者を分離し、境界（どこまで IaC、どこから GitOps）を明確化すると運用が安定します。

Policy as Code（ガードレール）

ポリシーは「禁止事項の自動チェック」であり、標準逸脱を早期に検知できます。

PSS（第7章）を基本線とし、例外は明示的に管理
リソース制約（requests/limits、Quota）の未設定を拒否/警告
望ましくない設定（特権コンテナ、危険な hostPath 等）の検知

ポリシーを厳格にしすぎると、回避策（例外 namespace の乱立）を誘発するため、段階導入（warn → enforce）を推奨します。

実務チェック観点（最低5項目）

source of truth（Git/Runbook 等）が定義され、手動変更（ドリフト）を抑止する運用がある
テナント払い出し（namespace/RBAC/PSS/Quota 等）がテンプレ化され、再現性が担保されている
変更フロー（レビュー、検証、段階適用、ロールバック）が標準化され、証跡が残る
Policy as Code によりガードレールが実装され、例外は期限/根拠付きで管理されている
運用物（Runbook/チェックリスト/フロー）がポストモーテムから継続更新されている

よくある落とし穴

GitOps を導入したが責任分界が曖昧で、結局手動変更が残りドリフトが常態化する
ポリシーを一度に厳格化し、現場が迂回策に流れて標準が崩壊する

まとめ / 次に読む

次に読む: 付録A：運用チェックリストPack