Config Sync のアーキテクチャ

このページでは、 Google Cloud で実行されるホスト型コンポーネントや、Google Kubernetes Engine(GKE)Enterprise エディション クラスタで実行されるオープンソース コンポーネントなど、Config Sync のアーキテクチャについて説明します。アーキテクチャについて学習すると、Config Sync をより深く理解でき、発生した問題のデバッグと解決に役立つ可能性があります。

Config Sync のアーキテクチャは、時間の経過とともに変化しています。

  • Config Sync バージョン 1.5.1 では、新しいマルチリポジトリ モードが追加されました。このモードでは、RootSync オブジェクトと RepoSync オブジェクトごとに Reconciler を使用する、よりスケーラブルなマルチテナント アーキテクチャが使用されます。これにより、独立した権限管理、独立したスケーリング、複数の独立した障害ドメインが可能になります。
  • Config Sync バージョン 1.18.0 では、自動アップグレード機能が追加されました。自動アップグレードが有効になっていると、ConfigManagement Operator と ConfigManagement オブジェクトがクラスタから削除されます。代わりに、フリート(GKE Hub)サービスがクラスタ上のオープンソース コンポーネントを直接管理します。自動アップグレードを無効にしても、ConfigManagement Operator は引き続き使用されます。
  • Config Sync バージョン 1.19.0 では、オプションの単一リポジトリ モードが削除されました。このモードでは、コンポーネントが少ないシンプルなアーキテクチャを使用しましたが、スケーリングが難しく、マルチテナンシーをサポートしていませんでした。そのため、このモードは新しいマルチリポジトリ モードに置き換えられました。詳細については、マルチリポジトリ モードに移行するをご覧ください。
  • Config Sync バージョン 1.20.0 では、自動アップグレードが無効になっている場合でも、ConfigManagement Operator と ConfigManagement オブジェクトが完全に削除されました。代わりに、フリート(GKE Hub)サービスがクラスタ上のオープンソース コンポーネントを直接管理します。

次のセクションでは、さまざまなバージョンの Config Sync について、Config Sync のアーキテクチャ(コンポーネントと依存関係を含む)を、 Google Cloud Google Kubernetes Engine(GKE)Enterprise エディション クラスタ内とクラスタ上で示します。

Config Sync のオブジェクトとリソースの関係を示す図

Config Sync バージョン 1.20.0 以降では、フリート サービスが、以前の ConfigManagement Operator や ConfigManagement オブジェクトを使用せずに、クラスタ上の Config Sync コンポーネントを直接管理します。Config Sync を自動的にアップグレードするように Fleet サービスを構成することも、必要に応じて Config Sync を手動でアップグレードすることもできます。

このアーキテクチャは、自動アップグレードが有効になっている Config Sync バージョン 1.18.0 以降にも使用されます。

Config Sync のインストールには複数の手順があり、各手順でクラスタに追加のコンポーネントがデプロイされます。

  1. クラスタで Config Sync を有効にすると、次のコンポーネントが追加されます。

    • ConfigSync カスタム リソース定義(CRD)
    • config-sync という名前の ConfigSync オブジェクト。
    • reconciler-manager という名前の Deployment の Reconciler Manager。
    • resource-group-controller-manager という名前の Deployment の ResourceGroup コントローラ。
    • otel-collector という名前の Deployment の OpenTelemetry Collector
    • 省略可: admission-webhook という名前の Deployment の Config Sync Admission Webhook。Config Sync Admission Webhook は、ドリフト防止を有効にした場合にのみインストールされます。

    これらのリソースとオブジェクトは、Config Sync のインストール時に自動的に作成されるため、直接変更しないでください。

  2. RootSync および RepoSync オブジェクトを作成すると、次のコンポーネントが追加されます。

    • RootSync オブジェクトに対して、root-reconciler-ROOTSYNC_NAME という名前の Reconciler Deployment。root-sync という名前の RootSync オブジェクトの場合、Reconciler Deployment の名前は root-reconciler です。
    • RepoSync オブジェクトに対して、ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH という名前の Reconciler Deployment。repo-sync という名前の RepoSync オブジェクトの場合、Reconciler Deployment の名前は ns-reconciler です。

Config Sync のオブジェクトとリソースの関係を示す図

Config Sync バージョン 1.19.x 以前では、手動アップグレードを使用する場合、フリート サービスが ConfigManagement Operator を管理し、ConfigManagement Operator がクラスタの Config Sync コンポーネントを管理します。

Config Sync バージョン 1.18.x 以降では、自動アップグレードを使用する場合、1.20.0 以降のアーキテクチャが使用されます。

Config Sync のインストールには複数の手順があり、各手順でクラスタに追加のコンポーネントがデプロイされます。

  1. クラスタで Config Sync を有効にすると、次のコンポーネントが追加されます。

    • config-management-operator という名前の Deployment の ConfigManagement Operator。
    • ConfigManagement カスタム リソース定義(CRD)。
    • config-management という名前の ConfigManagement オブジェクト。
    • reconciler-manager という名前の Deployment の Reconciler Manager。
    • resource-group-controller-manager という名前の Deployment の ResourceGroup コントローラ。
    • otel-collector という名前の Deployment の OpenTelemetry Collector
    • 省略可: admission-webhook という名前の Deployment の Config Sync Admission Webhook。Config Sync Admission Webhook は、ドリフト防止を有効にした場合にのみインストールされます。

    これらのリソースとオブジェクトのほとんどは、Config Sync のインストール時に自動的に作成されるため、直接変更しないでください。ただし、ConfigManagement オブジェクトには、直接変更できるフィールドがいくつかあります。詳細については、ConfigManagement フィールドをご覧ください。

  2. RootSync および RepoSync オブジェクトを作成すると、次のコンポーネントが追加されます。

    • RootSync オブジェクトに対して、root-reconciler-ROOTSYNC_NAME という名前の Reconciler Deployment。root-sync という名前の RootSync オブジェクトの場合、Reconciler Deployment の名前は root-reconciler です。
    • RepoSync オブジェクトに対して、ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH という名前の Reconciler Deployment。repo-sync という名前の RepoSync オブジェクトの場合、Reconciler Deployment の名前は ns-reconciler です。

Config Sync の Deployment、Pod、コンテナ

次の表に、Config Sync の Deployment、Pod、コンテナの詳細を示します。

Deployment 名 Deployment の Namespace デプロイメントの説明 レプリカ数 Pod 名の正規表現 コンテナ数 コンテナ名
config-management-operator config-management-system 手動アップグレードを使用する場合、ConfigManagement Operator は、Config Sync バージョン 1.19.x 以前がインストールされているクラスタで実行されます。ConfigManagement オブジェクトを監視し、Reconciler Manager や OpenTelemetry Collector などの他の Config Sync コンポーネントを管理します。Config Sync バージョン 1.20.0 以降では、ConfigManagement Operator は Fleet(GKE Hub)サービスの拡張機能に置き換えられました。 1 config-management-operator-.* 1
  • manager
  • reconciler-manager config-management-system Reconciler Manager は、ConfigManagement オブジェクトで Config Sync が有効になっているすべてのクラスタで実行されます。RootSync および RepoSync オブジェクトを監視し、それぞれに対して Reconciler Deployment を管理します。 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
  • root-reconciler config-management-system ルート Reconciler Deployment は、RootSync オブジェクトごとに作成されます。 1 root-reconciler-.* 3~51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
  • ns-reconciler config-management-system すべての RepoSync オブジェクトに対して Namespace Reconciler Deployment が作成されます。 1 ns-reconciler-.* 3~51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
  • otel-collector config-management-monitoring OpenTelemetry Collector は、ConfigManagement オブジェクトで Config Sync が有効になっているすべてのクラスタで実行されます。config-management-system Namespace と resource-group-system Namespace で実行されている Config Sync コンポーネントから指標を収集し、これらの指標を Prometheus と Cloud Monitoring にエクスポートします。 1 otel-collector-.* 1
  • otel-collector
  • resource-group-controller-manager resource-group-system ResourceGroup コントローラは、ConfigManagement オブジェクトで Config Sync が有効になっているすべてのクラスタで実行されます。ResourceGroup オブジェクトを監視し、インベントリにおける各オブジェクトの現在の調整ステータスで更新します。すべての RootSync オブジェクトと RepoSync オブジェクトに対して ResourceGroup オブジェクトが作成され、信頼できる情報源から Reconciler によって適用されたオブジェクトのリストをインベントリできます。 1 resource-group-controller-manager-.* 2
  • manager
  • otel-agent
  • admission-webhook config-management-system Config Sync Admission Webhook は、ConfigManagement オブジェクトでドリフト防止が有効になっている各クラスタで実行されます。Kubernetes API リクエストをモニタリングし、Config Sync で管理されているリソースの変更や削除を防止します。Config Sync Admission Webhook はデフォルトで無効になっています。 2 admission-webhook-.* 1
  • admission-webhook
  • 1 これらのコンテナが作成されるタイミングの詳細については、Reconciler コンテナをご覧ください。

    主要コンポーネント

    以降のセクションでは、重要な Config Sync コンポーネントについて詳しく説明します。

    フリート サービスと ConfigSync オブジェクト

    Config Sync バージョン 1.20.0 以降、および自動アップグレードが有効になっているバージョン 1.18.0 以降では、GKE Fleet サービスがクラスタの Config Sync コンポーネントを直接管理します。

    Config Sync の管理

    フリート サービスは、クラスタの ConfigSync オブジェクトも管理します。Fleet サービスは、 Google Cloud API への入力に基づいて ConfigSync オブジェクトの仕様とステータスの両方を更新し、Config Sync コンポーネントのステータスを反映します。

    Config Sync のインストール構成を変更するには、 Google Cloud API を使用する必要があります。ただし、 Google CloudAPI または Kubernetes API を使用して、Config Sync インストールの構成と健全性をモニタリングできます。

    ConfigManagement Operator と ConfigManagement オブジェクト

    Config Sync バージョン 1.19.x 以前では、手動アップグレードを使用する場合、GKE Fleet サービスが ConfigManagement Operator を管理し、ConfigManagement Operator がクラスタの Config Sync コンポーネントを管理します。

    Config Sync の管理

    Config Sync のインストール構成を変更するには、主に Google Cloud API を使用します。ただし、Kubernetes API を使用して ConfigManagement オブジェクトに変更を加えることもできます。詳細については、ConfigManagement フィールドをご覧ください。

    ConfigManagement Operator は、ConfigManagement オブジェクトを監視して仕様の変更を検出し、クラスタ上の Config Sync コンポーネントを管理して仕様を反映し、Config Sync コンポーネントのステータスを反映するように ConfigManagement オブジェクトのステータスを更新します。

    ConfigManagement Operator は、cluster-admin 権限を必要とするコンポーネントをインストールするため、ConfigManagement Operator には cluster-admin 権限も必要です。

    Reconciler Manager と Reconciler

    Reconciler Manager は、クラスタ構成の同期を維持する個々の Reconciler の作成と管理を行います。

    Reconciler Manager は、RootSync オブジェクトごとにルート Reconciler を作成し、RepoSync オブジェクトごとに Namespace Reconciler を作成します。Config Sync では、単一のモノリシック Reconciler を共有するのではなく、この設計を使用します。これにより、単一障害点が減り、個々の Reconciler を独立してスケーリングできるため、信頼性が向上します。

    ルート Reconciler と Namespace Reconciler は、信頼できる情報源から構成ファイルを自動的に取得し、それらを適用してクラスタ内で必要な状態を適用します。

    次の図は、Reconciler Manager が各ルート Reconciler と Namespace Reconciler のライフサイクルの制御を処理する方法を示しています。

    Reconciler Manager がルート Reconciler を制御する方法を示す図 Reconciler Manager が Namespace Reconciler を制御する方法を示す図

    Reconciler コンテナ

    Reconciler Pod にデプロイされる特定のコンテナは、構成の選択によって異なります。次の表に、各 Reconciler コンテナの機能と、Config Sync がそれらを作成するための条件を示します。

    コンテナ名 説明 条件
    reconciler 同期とドリフト修正を処理します。 常に有効。
    otel-agent 他の Reconciler コンテナから指標を受信し、それらを OpenTelemetry Collector に送信します。 常に有効。
    git-sync Reconciler コンテナが読み取り可能なローカル ディレクトリに、構成ファイルを Git リポジトリから pull します。 spec.sourceTypegit の場合に有効です。
    helm-sync Reconciler コンテナが読み取り可能なローカル ディレクトリに、Helm チャートをチャート リポジトリから pull してレンダリングします。 spec.sourceTypehelm の場合に有効です。
    oci-sync Reconciler コンテナが読み取り可能なローカル ディレクトリに、構成ファイルを含む OCI イメージを Container Registry から pull します。 spec.sourceTypeoci の場合に有効です。
    gcenode-askpass-sidecar git-sync コンテナで使用するために、GKE メタデータ サービスから Git 認証情報をキャッシュに保存します。 spec.sourceTypegit で、spec.git.authgcenode または gcpserviceaccount の場合に有効になります。
    hydration-controller Reconciler コンテナが読み取り可能なローカル ディレクトリへの Kustomize 構成の作成を処理します。 ソースに kustomize.yaml ファイルが含まれている場合に有効です。

    上の表に示されているように、通常、各 Reconciler Pod 内のコンテナ数は 3~5 個です。reconciler コンテナと otel-agent コンテナは常に存在します。信頼できる情報源のタイプを指定すると、追加される同期コンテナが決まります。また、表に記載されている構成変更を行った場合、hydration-controller コンテナと gcenode-askpass-sidecar コンテナが作成されます。

    ResourceGroup コントローラと ResourceGroup オブジェクト

    ルート Reconciler と Namespace Reconciler は、設定した RootSync オブジェクトと RepoSync オブジェクトごとに ResourceGroup インベントリ オブジェクトを作成します。各 ResourceGroup オブジェクトには、その RootSync オブジェクトまたは RepoSync オブジェクトの Reconciler によって信頼できる情報源からクラスタに同期されたオブジェクトのリストが含まれています。次に、ResourceGroup コントローラは ResourceGroup オブジェクト内のすべてのオブジェクトを監視し、同期されたオブジェクトの現在の調整ステータスで ResourceGroup オブジェクトのステータスを更新します。これにより、個々の各オブジェクトのステータスを自分でクエリするのではなく、ResourceGroup オブジェクトのステータスを確認して、同期ステータスの概要を把握できます。

    ResourceGroup オブジェクトの名前と Namespace は、対応する RootSync オブジェクトまたは RepoSync オブジェクトと同じです。たとえば、Namespace config-management-systemroot-sync という名前の RootSync オブジェクトの場合、対応する ResourceGroup オブジェクトも config-management-system Namespace の root-sync という名前になります。

    ResourceGroup オブジェクトを作成または変更しないでください。Config Sync の動作に干渉する可能性があります。

    アドミッション Webhook

    ドリフト防止を有効にすると、Config Sync Admission Webhook が作成されます。ドリフト防止は、変更リクエストをプロアクティブにインターセプトし、変更を許可する前に信頼できる情報源と照合します。

    ドリフト防止を有効にしない場合でも、Config Sync は自己回復メカニズムを使用して構成のずれを元に戻します。自己回復により、Config Sync はマネージド オブジェクトを継続的にモニタリングし、本来の状態から逸脱した変更を自動的に元に戻します。

    RootSync および RepoSync オブジェクト

    RootSync オブジェクトは、指定された信頼できる情報源を監視し、そのソースのオブジェクトをクラスタに適用するルート Reconciler を作成するように Config Sync を構成します。デフォルトでは、各 RootSync オブジェクトのルート Reconciler に cluster-admin 権限があります。このデフォルトの権限により、ルート Reconciler はクラスタ スコープのリソースと Namespace スコープのリソースの両方を同期できます。必要に応じて、spec.override.roleRefs フィールドを構成してこれらの権限を変更できます。RootSync オブジェクトは、クラスタ管理者が使用するように設計されています。

    RepoSync オブジェクトは、指定されたソースを監視し、そのソースのオブジェクトをクラスタ内の特定の Namespace に適用する Namespace Reconciler を作成するように Config Sync を構成します。Namespace Reconciler は、その Namespace 内の Namespace スコープのリソースを、ユーザー指定のカスタム権限と同期できます。RepoSync オブジェクトは、Namespace テナントで使用するように設計されています。

    フリート サービスによる RootSync オブジェクトの管理方法

    Google Cloud コンソール、Google Cloud CLI、Config Connector、Terraform で Config Sync をインストールすると、Config Sync は Google Cloud API への入力に基づいてフリート サービスによって管理されます。

    Config Sync のインストールがフリート サービスによって管理されている場合は、必要に応じて、root-sync という名前の最初の RootSync オブジェクトを管理することもできます。これにより、クラスタに手動で何かを直接適用しなくても、クラスタで GitOps をブートストラップできます。最初の RootSync オブジェクトをフリート サービスで管理しない場合でも、必要な RootSync オブジェクトと RepoSync オブジェクトをクラスタに直接適用できます。

    root-sync という名前の RootSync オブジェクトは、Google Cloud API、具体的には config-management apply API の spec.configSync セクションへの入力に基づいて作成されます。この API は RootSync フィールドのサブセットのみを公開するため、これらのフィールドは root-sync で管理されているとみなされ、他のフィールドは管理対象外とみなされます。マネージド フィールドはGoogle Cloud API を使用してのみ編集できます。非マネージド フィールドは、kubectl を使用して編集できます。

    追加の RootSync および RepoSync オブジェクト

    追加の RootSync オブジェクトまたは RepoSync オブジェクトを作成するには、kubectl コマンドライン ツールまたは別の Kubernetes クライアントを使用できます。また、最初の root-sync オブジェクトを使用して、GitOps で追加の RootSync オブジェクトまたは RepoSync オブジェクトを管理することもできます。これを行うには、root-sync の同期元として構成されている信頼できる情報源に YAML マニフェストを追加します。この手法を使用して最初の root-sync の構成を管理することはできません。一部のフィールドはフリート サービスによって管理されているためです。GitOps を通じて root-sync オブジェクトを管理するには、Config Connector または Terraform を使用します。追加の RootSync オブジェクトと RepoSync オブジェクトの作成について詳しくは、複数の信頼できる情報源からの同期を構成するをご覧ください。

    次のステップ