Config Sync のアーキテクチャ

このページでは、Config Sync のアーキテクチャについて説明します。Config Sync で作成されたコンポーネントについて学習すると、Config Sync をより深く理解でき、発生した問題のデバッグと解決に役立つ可能性があります。

次の図は、Google Kubernetes Engine（GKE）Enterprise エディション クラスタ上の Config Sync とその関連リソースのアーキテクチャを示しています。

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

この図では、ユーザーが信頼できる情報源を作成し、機能マネージャーを使用して Config Sync をインストールしています。

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

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

    • config-management-operator という名前の Deployment の ConfigManagement Operator。
    • ConfigManagement カスタム リソース定義（CRD）と config-management という名前のオブジェクト。
    • 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 のインストール時に自動的に作成されるため、変更は必要ありません。

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

    • 各 RootSync に対する、root-reconciler-ROOTSYNC_NAME という名前の Reconciler Deployment。
    • 各 RepoSync に対する、ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH という名前の Reconciler Deployment。

Config Sync の Deployment、Pod、コンテナ

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

Deployment 名 Deployment の Namespace Deployment の説明 レプリカ数 Pod 名の正規表現 コンテナ数 コンテナ名
config-management-operator config-management-system ConfigManagement Operator は、Config Sync がインストールされているすべてのクラスタで実行されます。ConfigManagement オブジェクトを監視し、Reconciler Manager や OpenTelemetry Collector などの Config Sync コンポーネントを管理します。 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
  • reconciler-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 コンポーネントについて詳しく説明します。

    ConfigManagement Operator およびオブジェクト

    ConfigManagement Operator は ConfigManagement オブジェクトを監視し、Config Sync の動作に必要な他のコンポーネントを作成して管理します。

    Operator の作動

    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.sourceType が git の場合に有効です。
    helm-sync Reconciler コンテナが読み取り可能なローカル ディレクトリに、Helm チャートをチャート リポジトリから pull してレンダリングします。 spec.sourceType が helm の場合に有効です。
    oci-sync Reconciler コンテナが読み取り可能なローカル ディレクトリに、構成ファイルを含む OCI イメージを Container Registry から pull します。 spec.sourceType が oci の場合に有効です。
    gcenode-askpass-sidecar git-sync コンテナで使用するために、GKE メタデータ サービスから Git 認証情報をキャッシュに保存します。 spec.sourceType が git で、spec.git.auth が gcenode または 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-system の root-sync という名前の RootSync オブジェクトの場合、対応する ResourceGroup オブジェクトも config-management-system Namespace の root-sync という名前になります。

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

    Admission 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 オブジェクトの作成について詳しくは、複数の信頼できる情報源からの同期を構成するをご覧ください。

    次のステップ