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 Operator はインストールされません。
    • ConfigManagement カスタム リソース定義（CRD）と config-management という名前のオブジェクト。自動アップグレードを使用している場合、ConfigManagement CRD とオブジェクトはインストールされません。
    • reconciler-manager という名前の Deployment の Reconciler Manager。
    • resource-group-controller-manager という名前の Deployment の ResourceGroup Controller。
    • 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。
    • 各 RepoSync に対する、ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH という名前の Reconciler Deployment。

Config Sync の Deployment、Pod、コンテナ

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

Deployment 名 Deployment の Namespace デプロイメントの説明 レプリカ数 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 ルート調整ツール 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 オブジェクトに対して 名前空間調整ツール 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 と resource-group-system の名前空間で実行されている Config Sync コンポーネントから指標を収集し、これらの指標を Prometheus と Cloud Monitoring にエクスポートします。 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system ResourceGroup Controller は、ConfigManagement オブジェクトで Config Sync が有効になっているすべてのクラスタで実行されます。ResourceGroup オブジェクトを監視し、インベントリにおける各オブジェクトの現在の調整ステータスで更新します。すべての RootSync オブジェクトと RepoSync オブジェクトに対して ResourceGroup オブジェクトが作成され、信頼できる情報源から調整ツールによって適用されたオブジェクトのリストをインベントリできます。 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 これらのコンテナが作成されるタイミングの詳細については、調整ツール コンテナをご覧ください。

    主要コンポーネント

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

    ConfigManagement Operator およびオブジェクト

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

    オペレータの作動

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

    Reconciler Manager と調整ツール

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

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

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

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

    Reconciler Manager がルート Reconciler を制御する方法を示す図 Reconciler Manager が名前空間調整ツールを制御する方法を示す図

    Reconciler コンテナ

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

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

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

    ResourceGroup Controller と ResourceGroup オブジェクト

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

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

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

    アドミッション Webhook

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

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

    RootSync および RepoSync オブジェクト

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

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

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

    次のステップ