Config Sync の概要

Config Sync は、クラスタ オペレータが Git リポジトリに保存された「コンフィグ」と呼ばれるファイルを使用して単一のクラスタ、マルチテナント クラスタ、マルチクラスタ Kubernetes デプロイメントを管理できるようにするものです。

一部のコンフィグは Kubernetes オブジェクトのマニフェストです。それ以外のコンフィグはオブジェクトのマニフェストではなく、Config Sync 自体が必要とする情報を提供します。コンフィグは YAML または JSON で記述できます。Config Sync はこれらのファイルの更新を監視し、関連するすべてのクラスタに変更を自動的に適用します。

Configuration as Code のアプローチを使用すると、Kubernetes でデプロイされたアプリケーションの管理にすでに使用しているのと同じ原則に従って、Google Kubernetes Engine クラスタの構成を管理できます。Config Sync を使用すると、次のことができます。

  • 変更がライブ環境に push される前に必ずコードがチェックされるようにし、どの commit によって構成変更が発生したかを正確に監査する。
  • 「シャドウ オペレーション」のリスクを軽減する。つまり、入念に検証されていない変更がライブクラスタに push され、文書化された構成とライブ環境の違いを理解するのが難しくなる事態を防ぎます。クラスタ構成に対するすべての変更が必ず Config Sync を使用して伝播されるようにし、Kubernetes API への直接アクセスを禁止できます。
  • 数百ものクラスタへの構成変更を 1 つの Git commit で適用する。kubectl apply コマンドを手動で何千回も実行するスクリプトを記述しなくて済みます。
  • 各クラスタに適用されたメタデータに基づいて、ある特定の変更が関連クラスタだけに push されるようにする。
  • 継続的インテグレーション / 継続的デプロイ(CI / CD)パイプラインを使用して変更をテストし、テストに合格したときに自動的に変更を適用する。
  • 「元に戻してから調査」戦略を使用し、破壊的な変更をロールバックしてライブクラスタを正常な動作状態に戻してから、問題のある変更を修正して新しい commit として適用する。この戦略をとれば、構成関連のサービス停止によるダウンタイムが短縮されます。

Config Sync は、クラスタの状態を Git リポジトリと同期させます。Config Sync Operator カスタム コントローラが Git リポジトリとクラスタの状態をモニタリングし、ユーザーが選んだ各 Kubernetes オブジェクトについてそれらを常に一致させます。リソースへの変更の適用が失敗した場合、そのリソースは最後の既知の正常な状態にとどまります。

Config Sync は、単一の Git リポジトリから単一のクラスタまたは複数のクラスタを構成できます。

要件

Config Sync の実装の中核には Namespaceラベルアノテーションがあり、最初にこれらのコンセプトをしっかり理解しておくと役立ちます。

コンフィグを記述する前に、その Kubernetes オブジェクトで使用できる必須フィールドとオプション フィールドを理解する必要があります。

さらに、Config Sync は新しい用語とコンセプトも導入します。これらについては Config Sync のコンセプトで簡単に説明されており、そこに各コンセプトの詳細を示すリンクがあります。

新しいコンセプト

Config Sync の中心には以下の新しいコンセプトがあります。

構成

「コンフィグ」は、YAML または JSON で記述された Kubernetes 構成の宣言です。Config Sync はこれらのファイルを読み取って 1 つ以上のクラスタに適用し、Kubernetes オブジェクトまたはリソースをそれらのクラスタに作成または構成します。コンフィグは Git リポジトリに保存されます(リポの定義も参照)。コンフィグには、kubectl edit または kubectl apply を使用して Kubernetes クラスタに適用できる構成情報を含めることができます。クラスタにすでに存在するカスタム リソースを構成することもできます。1 つのファイルで複数のコンフィグを定義できます。

詳細については、コンフィグの作成をご覧ください。

リポ

リポは、コンフィグ(Config Sync 自体のコンフィグを含む)が保存されている Git リポジトリを意味します。すべてのコンフィグは同じリポに保存されている必要があります。Config Sync を構成するときに、変更を監視するリポ、ブランチ、サブディレクトリを構成します。

リポの構造は重要であり、リポの使用で詳しく説明されています。

抽象名前空間ディレクトリ

Config Sync は抽象名前空間と呼ばれるメカニズムを備えています。これにより、コンフィグを複製することなく複数の関連する Namespace にポリシーを適用し、特定の Namespace または Namespace のセットに対するコンフィグをオーバーライドまたは拡張できます。抽象名前空間は、リポ内のファイル システム形式の階層に基づいて働きます。

リポ内では、namespaces/ サブディレクトリのディレクトリ構造により、ファイル システムのツリーに似たメカニズムを使用してどのポリシーを Namespace に適用するかが決定されます。名前空間はサブディレクトリにネストでき、このサブディレクトリのことを「抽象名前空間ディレクトリ」と呼びます。

詳細については、Namespace の継承をご覧ください。

ファイルの表示と確認

Config Sync には API が用意されています。この API を消費する nomos および nomos.exe コマンドを使用して、リポのセットアップやコンフィグの検証を簡単に行うことができます。

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

次のステップ