Config Sync

解決する課題

Kubernetes クラスタが増えるほど、誰がいつ何を kubectl apply したのかが追えなくなり、クラスタごとに設定が少しずつズレていきます。Config Sync は Git を唯一の信頼の起点（Single Source of Truth）に据え、クラスタの状態を Git の内容へ継続的に収束させることで、この「構成ドリフト」を根本から防ぎます。

• クラスタへの変更を手作業の kubectl apply から Git のコミット経由に置き換えたい（監査・レビュー・ロールバックを Git に集約）
• 複数クラスタ・複数チームに共通設定（名前空間・RBAC・ネットワークポリシーなど）を一括で配り、一貫性を保ちたい
• 誰かがクラスタ上で直接書き換えた変更（ドリフト）を自動で Git の状態へ戻したい
• ポリシー（許可レジストリ・必須ラベルなど）を継続的に強制し、逸脱を見つけて修正したい
• マルチクラスタの構成を宣言的に管理し、再現性のある運用にしたい

Config Sync は GitOps の一実装で、CNCF エコシステムの Argo CD や Flux と同じ系統に位置づけられます。GKE Enterprise（旧 Anthos）の Config Management 機能群の中核として提供され、オープンソースの実装も公開されています。

主要概念と用語

• 信頼の起点（Source of Truth）: 設定の正本を置く場所。Git リポジトリ、OCI イメージ、または Helm チャートを指定できる
• RootSync: クラスタ全体（クラスタスコープのリソースを含む）を同期するためのリソース。プラットフォーム管理者が用いる
• RepoSync: 特定の名前空間に限定して同期するリソース。チーム単位で名前空間内のリソースだけを管理させる用途に向く
• reconciler（リコンサイラ）: Source of Truth とクラスタの実状態を比較し、差分をクラスタへ適用し続ける同期エンジン本体
• ドリフト是正（drift correction）: クラスタ上で直接行われた変更を検知し、Source of Truth の宣言内容へ自動的に戻す動作
• 同期モード: リポジトリ構成の形式。階層的な構造の hierarchy と、ディレクトリ構成が自由な unstructured がある
• フリート（fleet）: 複数のクラスタを論理的にまとめた集合。フリート単位で Config Sync をまとめて有効化・配布できる
• Policy Controller: Open Policy Agent（OPA）/ Gatekeeper をベースにしたポリシー強制機能。Config Sync と組み合わせて違反リソースを制約する
• nomos: Config Sync を操作・検証する CLI。リポジトリの妥当性チェックや同期状態の確認に使う

仕様・制限・クォータ

• Source of Truth として Git・OCI・Helm をサポート。Git は任意のホスティング（Cloud Source Repositories・GitHub・GitLab など）を利用できる
• 同期対象は Kubernetes の宣言的リソース（YAML マニフェスト）。命令的な操作や任意スクリプトの実行を行う仕組みではない
• 1 クラスタに RootSync と複数の RepoSync を併用でき、クラスタスコープと名前空間スコープの管理を分担できる
• 同期間隔（ポーリング周期）は設定可能で、短くするほど反映は速いがリポジトリ側への負荷が増える
• GKE のほか、GKE Enterprise（マルチクラウド・オンプレを含むフリート）に登録したクラスタで利用できる
• ドリフト是正の対象や強さは構成に依存し、reconciler が管理対象としたリソースに対して働く

具体的な対応バージョンや上限値はリリースで変動するため、設計時は公式ドキュメントで最新値を確認してください。

内部の仕組み

Config Sync はクラスタ内に reconciler と呼ばれるコントローラを常駐させ、指定した Source of Truth（Git・OCI・Helm）を定期的にポーリングします。取得した宣言的設定とクラスタの実状態を突き合わせ、差分があればクラスタへ適用して、宣言した状態へ継続的に収束させます。これは Kubernetes のコントローラと同じ「観測して、あるべき状態へ近づける」制御ループの考え方です。

クラスタ全体を扱う RootSync はクラスタスコープのリソース（名前空間・ClusterRole など）も含めて同期でき、プラットフォーム管理者が共通基盤を配布するのに向きます。名前空間に閉じた RepoSync は、その名前空間内のリソースだけを対象にするため、チームに自分の名前空間のみを Git 経由で管理させる委譲モデルを作れます。

クラスタ上で誰かが直接リソースを書き換えると、reconciler は次の照合で差分を検知し、Source of Truth の内容へ自動的に戻します（ドリフト是正）。これにより、クラスタの実態は常に Git の履歴と一致し、変更はすべて Git のコミットを通すという運用が成立します。

設計パターン / ベストプラクティス

• すべての変更を Git のコミット経由にし、kubectl apply での直接変更を運用ルールとして禁止する
• 共通基盤は RootSync、チーム別アプリは RepoSync に分け、最小権限で委譲する
• Policy Controller を併用し、必須ラベル・許可レジストリ・特権コンテナ禁止などのポリシーを継続的に強制する
• フリートに登録した複数クラスタへ同じ Source of Truth を配布し、本番・ステージングの構成差を環境別ディレクトリで管理する
• リポジトリは nomos で事前検証し、不正なマニフェストが同期される前に CI で弾く
• 同期間隔は反映速度とリポジトリ負荷のバランスで決め、過度に短くしない
• 機密値は Git に直接置かず、Secret Manager や外部シークレット連携と組み合わせる

運用・監視

• 同期状態は nomos status や RootSync / RepoSync のステータスで確認し、同期エラーやドリフトを把握する
• Cloud Monitoring / Cloud Logging と統合し、reconciler のメトリクスとログを収集して同期失敗を検知する
• Google Cloud コンソールのフリート向け Config Management 画面で、各クラスタの同期状態を一覧で確認できる
• 同期が止まったときは、Source of Truth への到達性（認証・ネットワーク）と、マニフェストの妥当性をまず疑う
• ポリシー違反は Policy Controller の監査結果として可視化され、違反リソースを継続的に洗い出せる
• リポジトリへ問題のあるコミットが入った場合は Git のリバートで元へ戻す（ロールバックも Git の操作に集約される）

コスト

Config Sync 自体は GKE Enterprise（Config Management 機能群）の一部として提供され、フリート管理の枠組みの中で利用します。料金体系はエディションや契約形態で変わるため、断定的な金額ではなく定性的に捉えてください。

直接の課金よりも、手作業の構成管理を Git に集約することで運用工数とヒューマンエラー由来の障害コストを下げる効果が大きいサービスです。具体的な料金は公式の料金ページで確認してください。

セキュリティ

• 変更がすべて Git を通るため、誰が何を変えたかがコミット履歴として残り、レビューと監査が効く
• Source of Truth への認証は鍵ファイルのハードコードを避け、Workload Identity Federation for GKE などで安全に行う
• Policy Controller で許可レジストリのみ・必須ラベル・特権コンテナ禁止などを強制し、危険な構成のデプロイを防ぐ
• RepoSync で名前空間に権限を閉じ、チームがクラスタ全体へ影響を及ぼせないようにする
• ドリフト是正により、攻撃者やオペミスによる無断のクラスタ変更を自動で元へ戻せる
• 機密情報は Git に平文で置かず、Secret Manager など専用のシークレット管理と連携する

関連サービス・比較

Config Sync は GKE Enterprise の Config Management を構成する一機能で、ポリシー強制を担う Policy Controller と密接に連携します。Config Sync が「あるべき状態を配る」役割、Policy Controller が「逸脱を防ぐ・検知する」役割を担い、両者を組み合わせて宣言的なガバナンスを実現します。

ハンズオン / CLI例

# フリートに登録したクラスターで Config Sync を有効化（例: 設定ファイル経由）
gcloud container fleet config-management enable

# 適用する設定ファイルの雛形を取得して編集する
gcloud container fleet config-management apply \
  --membership=demo-cluster \
  --config=config-management.yaml \
  --project=PROJECT_ID

# 各メンバークラスターの同期ステータスを一覧で確認
gcloud container fleet config-management status --project=PROJECT_ID

# クラスター内で nomos を使って同期状態を詳しく確認
nomos status