Config Sync を使用すると、クラスタ運用担当者とプラットフォーム管理者は、一貫した方法で構成やポリシーをデプロイできます。これらの構成とポリシーは、個々の Kubernetes クラスタだけでなく、ハイブリッド環境とマルチクラウド環境にまたがる複数のクラスタや、クラスタ内の複数の名前空間にデプロイできます。このプロセスにより、大規模な環境での構成とポリシー管理作業を簡素化し、自動化できます。Config Sync を使用すると、開発チームは管理者が設定したポリシー ガードレールを適用しながら、クラスタ内の名前空間を個別に管理することもできます。
Config Sync は Kubernetes 自体と同じ原則を使用しています。中央の Kubernetes の宣言型の構成ファイル（構成ファイル）のセットを使用して、登録済みのクラスタの状態を継続的に調整します。構成ファイルは 1 つ以上の Git リポジトリに格納され、構成済みの Kubernetes オブジェクトの間で整合性が維持されます。この GitOps アプローチ（Configuration as Code とも呼ばれます）を使用することで、監査、トランザクション管理、レビュー、バージョン管理が可能なプロセスを使用して、共通の構成を管理し、デプロイできます。
次の図は、プラットフォーム管理者がクラスタとクラスタ内の名前空間に構成ファイルを適用して、3 つの異なるクラスタに一貫した構成を作成する方法を示しています。
Config Sync のメリット
Config Sync を使用する主なメリットは次のとおりです。
- 「シャドウ オペレーション」のリスクを軽減する: 十分に検証されていない変更がライブクラスタに push されると、文書化された構成とライブ環境の違いを理解するのが難しくなります。クラスタ構成に対するすべての変更が必ず Config Sync を介して伝播されるようにすることで、Kubernetes API への直接アクセスを禁止し、Git の信頼できる情報源と比較して変更を追跡できます。
- コードレビューを必須にする: ライブ環境に変更が push される前に、Config Sync でコードレビューを行い、どの commit によって構成変更が発生したかを正確に監査できます。
- 構成関連の停止によるダウンタイムを削減する: Config Sync では、「元に戻してから調査」という戦略を使用します。破壊的な変更をロールバックしてライブクラスタを正常な動作状態に戻してから、問題のある変更を修正して新しい commit として適用します。
- 継続的インテグレーション / 継続的デプロイ（CI / CD）パイプラインを使用する: CI / CD ワークフローを使用して、任意のツールと形式で構成のレンダリング、変更のテスト、検証を行い、テストに合格したときに変更を自動的に commit します。その後、Config Sync が変更を適用し、以降の構成のずれをモニタリングして修正します。
Config Sync について
前提条件
Config Sync は、実装のコア部分として名前空間、ラベル、アノテーションを使用しています。プロダクトを使い始める前に、これらのコンセプトをよく理解しておくことをおすすめします。
クラスタの構成
Config Sync では、Git の信頼できる単一の情報源から構成の共通セットとクラスタレベルのポリシー（Policy Controller の制約など）を作成し、登録済みで接続しているクラスタに一貫した方法で適用できます。クラスタを構成する前に、構成とリポジトリを作成しておく必要があります。
構成ファイル
構成ファイルは、YAML または JSON で記述された Kubernetes 構成の宣言です。Config Sync は構成ファイルを読み取り、1 つ以上のクラスタに適用します。これにより、クラスタ内の Kubernetes オブジェクトやリソースを作成または構成します。また、Config Sync 自体が必要とする情報を提供します。構成ファイルには、kubectl edit または kubectl apply を使用して、Kubernetes クラスタに適用可能な任意の構成情報を含めることができます。1 つのファイルで複数の構成ファイルを宣言することもできます。
構成ファイルを記述する前に、その Kubernetes オブジェクトで使用できる必須フィールドとオプション フィールドを把握する必要があります。
詳細については、構成ファイルの概要と Kubernetes オブジェクトの構成をご覧ください。ここに構成ファイルの作成方法が記載されています。
リポジトリ
リポジトリ（またはリポ）は、構成ファイル（Config Sync 自体の構成ファイルも含む）が保存されている Git リポジトリです。Config Sync を構成するときに、変更をモニタリングするリポジトリ、ブランチ、サブディレクトリを構成します。
Config Sync を使用すると、複数のリポジトリの構成を同じクラスタのセットに同期できます。複数のリポジトリの同期を有効にすると、追加の機能を利用できます（たとえば、オブジェクトのミューテーションを無視するなど）。この機能は、ルート リポジトリのみを使用し、名前空間リポジトリを使用しない場合でも有効にできます。詳細については、複数のリポジトリから同期するをご覧ください。
ルート リポジトリと名前空間リポジトリを作成できます。
ルート リポジトリ: このリポジトリを使用すると、クラスタ スコープと名前空間スコープの構成ファイルを同期できます。ルート リポジトリは、管理者レベルの認証情報を使用してアプリケーションの名前空間にポリシーを適用し、構成ファイルで宣言された状態をずれているローカルの変更をオーバーライドします。通常、ルート リポジトリは中央の管理者が管理します。各クラスタに存在するルート リポジトリは 1 つだけです。
ルート リポジトリには次の 2 つの構造を使用できます。
非構造化: 非構造化ソース形式を使用すると、リポジトリ内の構成ファイルを最適な方法で整理できます。この形式は、kustomize、kpt、helm などのツールで構成ファイルを整理または生成する場合に特に便利です。ほとんどのユーザーには、非構造化形式の使用をおすすめします。詳細については、非構造化リポジトリの使用をご覧ください。
階層型: 階層型または構造化されたソース形式では、構成ファイルをシステム構成、クラスタ メタデータ、クラスタレベルの構成、名前空間構成などのカテゴリに分類して整理できます。また、ディレクトリ構造に基づいて複数の名前空間で構成の階層構造を継承することもできます。詳細については、名前空間の構成をご覧ください。Config Sync のデフォルトのリポジトリ形式は階層型です。詳細については、階層リポジトリの概要をご覧ください。
名前空間リポジトリ: 名前空間リポジトリはオプションです。名前空間スコープの構成ファイルを保存し、クラスタ間で特定の名前空間に同期できます。名前空間リポジトリの設定と制御を管理者以外のユーザーに委任することもできます。名前空間リポジトリには非構造化形式を使用する必要があります。詳細については、名前空間リポジトリからの同期の構成をご覧ください。
複数のクラスタを構成する
Config Sync を使用すると、ハイブリッド環境とマルチクラウド環境にまたがる複数のクラスタに一貫した方法で構成やポリシーをデプロイできます。
Config Sync では、次のオプションを使用して複数のクラスタを構成できます。
kubectl applyコマンドの手動実行ではなく、Git を使用して一連のクラスタに対する構成変更をオーケストレートできます。詳細については、Anthos Config Management を使用した安全なロールアウトをご覧ください。- 各クラスタに適用されたメタデータに基づいて、特定の変更が関連クラスタだけに push されるように制御できます。詳細については、クラスタのサブセットのみを構成するをご覧ください。クラスタ メタデータの管理は、リポジトリの形式が非構造化か階層型かによって少し異なります。
クラスタを登録することを強くおすすめします。クラスタを登録すると、Google Cloud Console からすべてのクラスタの現在のステータスをモニタリングし、Config Sync で登録済みのクラスタの構成と管理を一元的に行うことができます。詳細については、クラスタの登録、Config Sync の構成、Config Sync バージョンのアップグレードをご覧ください。
名前空間を構成する
Config Sync で名前空間を構成すると、次のことが可能になります。
- 登録済みで接続しているクラスタ全体で、名前空間スコープのポリシー（RBAC ロールなど）を使用して、Kubernetes 名前空間のプロビジョニングを一貫した方法で行うことができます。名前空間スコープのポリシーを使用すると、クラスタ内でマルチテナンシーの実装と管理をより簡単に行うことができます。
- 構成ファイルを複製することなく、複数の関連する名前空間にポリシーを適用します。特定の名前空間または名前空間セットの構成をオーバーライドまたは拡張できるため、テナント間で一貫したポリシーを簡単に適用できます。
これらの機能は、リポジトリの形式（非構造化か階層型か）によって動作が異なります。
非構造化リポジトリの場合は、Hierarchy Controller を使用して、クラスタに定義したポリシーを名前空間の階層全体に伝播できます。詳細については、Hierarchy Controller の概要をご覧ください。
階層型リポジトリの場合は、抽象名前空間という名前空間グループを使用して、伝播する名前空間ポリシーを制御できます。抽象名前空間では、リポジトリのディレクトリ ツリーを使用して名前空間を階層的に整理する必要があります。詳細については、名前空間と名前空間スコープ オブジェクトの構成と名前空間の継承の概要をご覧ください。
どちらのリポジトリの形式（非構造化か階層型か）でも、ラベルセレクタを使用して階層外の名前空間セットをターゲットに設定できます。
nomos コマンド
Config Sync には API が用意されています。nomos コマンドと nomos.exe コマンドは API を使用します。階層形式のリポジトリを設定するプロセスと構成ファイルの検証を簡単に行うことができます。
詳細については、nomos コマンドの使用をご覧ください。