Config Sync の概要

Config Sync を使用すると、クラスタ運用担当者とプラットフォーム管理者は、一貫した方法で構成やポリシーをデプロイできます。これらの構成とポリシーは、個々の Kubernetes クラスタだけでなく、ハイブリッド環境とマルチクラウド環境にまたがる複数のクラスタや、クラスタ内の複数の Namespace にデプロイできます。このプロセスにより、大規模な環境での構成とポリシー管理作業を簡素化、自動化できます。Config Sync を使用すると、開発チームは管理者が設定したポリシー ガードレールを適用しながら、クラスタ内の Namespace を個別に管理することもできます。

Config Sync は Kubernetes 自体と同じ原則を使用しています。中央の Kubernetes の宣言型の構成ファイル(構成ファイル)のセットを使用して、登録済みのクラスタの状態を継続的に調整します。構成ファイルは 1 つ以上の Git リポジトリに格納され、Config Sync は構成された Kubernetes オブジェクトの整合性を維持します。この GitOps アプローチ(Configuration as Code とも呼ばれます)を使用することで、監査、トランザクション管理、レビュー、バージョン管理が可能なプロセスを使用して、共通の構成を管理し、デプロイできます。

次の図では、プラットフォーム管理者が、クラスタと Namespace に構成ファイルを適用することで 3 つの異なるクラスタに一貫した構成を作成しています。

プラットフォーム管理者が複数の構成ファイルをクラスタにデプロイしています。

Config Sync のメリット

Config Sync を使用する主なメリットは次のとおりです。

  • 「シャドウ オペレーション」のリスクを軽減する: 十分に検証されていない変更がライブクラスタに push されると、文書化された構成とライブ環境の違いを理解するのが難しくなります。クラスタ構成に対するすべての変更が必ず Config Sync を介して適用されるようにすることで、Kubernetes API への直接アクセスを禁止し、Git の信頼できる情報源と比較して変更を追跡できます。
  • GitOps のベスト プラクティスを使用する: ライブ環境に変更が 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 つのファイルで複数の構成ファイルを宣言することもできます。Config Sync は 3 種類のファイル(.yaml.yml.json)を読み取ります。他の拡張子のファイルは無視されます。

構成ファイルを作成する前に、構成ファイルに記述する Kubernetes オブジェクトについて理解しておく必要があります。

詳細については、構成ファイルの概要Kubernetes オブジェクトの構成をご覧ください。ここに構成ファイルの作成方法が記載されています。

リポジトリ

リポジトリ(またはリポ)は、構成ファイル(Config Sync 自体の構成ファイルも含む)が保存されている Git リポジトリです。Config Sync を構成するときに、変更をモニタリングするリポジトリ、ブランチ、サブディレクトリを構成します。

Config Sync を使用すると、複数のリポジトリの構成を同じクラスタのセットに同期できます。複数のリポジトリの同期を有効にすると、追加の機能を利用できます(たとえば、ドリフト防止オブジェクトのミューテーションを無視するなど)。この機能は、ルート リポジトリのみを使用し、Namespace リポジトリを使用しない場合でも有効にできます。詳細については、複数のリポジトリから同期するをご覧ください。

ルート リポジトリと Namespace リポジトリを作成できます。

  • ルート リポジトリ: このリポジトリを使用すると、クラスタ スコープ名前空間スコープの構成ファイルを同期できます。ルート リポジトリは、管理者レベルの認証情報を使用してアプリケーションの名前空間にポリシーを適用し、構成ファイルで宣言された状態をずれているローカルの変更をオーバーライドします。各クラスタに設定できるルート リポジトリは 1 つのみです。通常、このリポジトリは中央管理者によって管理されます。

    ルート リポジトリには次の 2 つの構造を使用できます。

    • 非構造化: 非構造化ソース形式を使用すると、リポジトリ内の構成ファイルを最適な方法で整理できます。この形式は、kustomizekpthelm などのツールで構成ファイルを整理または生成する場合に特に便利です。ほとんどのユーザーには、非構造化形式の使用をおすすめします。詳細については、非構造化リポジトリの使用をご覧ください。

    • 階層型: 階層型または構造化されたソース形式では、構成ファイルをシステム構成、クラスタ メタデータ、クラスタレベルの構成、名前空間構成などのカテゴリに分類して整理できます。また、ディレクトリ構造に基づいて複数の名前空間で構成の階層構造を継承することもできます。詳細については、名前空間の構成をご覧ください。Config Sync のデフォルトのリポジトリ形式は階層型です。詳細については、階層リポジトリの概要をご覧ください。

  • 名前空間リポジトリ: 名前空間リポジトリはオプションです。名前空間スコープの構成ファイルを保存し、クラスタ間で特定の名前空間に同期できます。名前空間リポジトリの設定と制御を管理者以外のユーザーに委任することもできます。名前空間リポジトリには非構造化形式を使用する必要があります。詳細については、名前空間リポジトリからの同期の構成をご覧ください。

複数のクラスタを構成する

Config Sync を使用すると、ハイブリッド環境とマルチクラウド環境にまたがる複数のクラスタに一貫した方法で構成やポリシーをデプロイできます。

Config Sync では、次のオプションを使用して複数のクラスタを構成できます。

クラスタを登録することを強くおすすめします。クラスタを登録すると、Google Cloud Console からすべてのクラスタの現在のステータスをモニタリングし、Config Sync で登録済みのクラスタの構成と管理を一元的に行うことができます。詳細については、クラスタの登録Config Sync の構成Config Sync バージョンのアップグレードをご覧ください。

名前空間を構成する

Config Sync で名前空間を構成すると、次のことが可能になります。

  • 登録済みで接続しているクラスタ全体で、名前空間スコープのポリシー(RBAC ロールなど)を使用して、Kubernetes 名前空間のプロビジョニングを一貫した方法で行うことができます。名前空間スコープのポリシーを使用すると、クラスタ内でマルチテナンシーの実装と管理をより簡単に行うことができます。
  • 構成ファイルを複製することなく、複数の関連する名前空間にポリシーを適用します。特定の名前空間または名前空間セットの構成をオーバーライドまたは拡張できるため、テナント間で一貫したポリシーを簡単に適用できます。

これらの機能は、リポジトリの形式(非構造化階層型か)によって動作が異なります。

非構造化リポジトリの場合は、Hierarchy Controller を使用して、クラスタに定義したポリシーを名前空間の階層全体に伝播できます。詳細については、Hierarchy Controller の概要をご覧ください。

階層型リポジトリの場合は、抽象名前空間という名前空間グループを使用して、伝播する名前空間ポリシーを制御できます。抽象名前空間では、リポジトリのディレクトリ ツリーを使用して名前空間を階層的に整理する必要があります。詳細については、名前空間と名前空間スコープ オブジェクトの構成名前空間の継承の概要をご覧ください。

どちらのリポジトリの形式(非構造化か階層型か)でも、ラベルセレクタを使用して階層外の名前空間セットをターゲットに設定できます。

nomos コマンド

Config Sync には API が用意されています。nomos(Windows の場合は nomos.exe)コマンドは、この API を使用してインストール ステータスを確認し、構成ファイルを検証します。

詳細については、nomos コマンドの使用をご覧ください。

次のステップ