Config Sync のアーキテクチャ

このページでは、Config Sync のアーキテクチャについて説明します。これには、 Google Cloud で実行されるホスト型コンポーネントと、Google Kubernetes Engine クラスタで実行されるオープンソース コンポーネントが含まれます。このアーキテクチャについて確認することで、Config Sync をより深く理解し、発生した問題のデバッグと解決に役立つ場合があります。

次のセクションでは、 Google Cloud と GKE クラスタの両方における、コンポーネントと依存関係を含む Config Sync のアーキテクチャについて説明します。

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

フリート サービスは、以前の ConfigManagement Operator や ConfigManagement オブジェクトを使用せずに、クラスタ上の Config Sync コンポーネントを直接管理します。必要に応じて Config Sync を手動でアップグレードする必要があります。

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 の Deployment、Pod、コンテナ

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

Deployment 名 Deployment の Namespace Deployment の説明 レプリカ数 Pod 名の正規表現 コンテナ数 コンテナ名
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 コンポーネントの Kubernetes リソースの要件を示します。詳細については、Kubernetes ドキュメントの Pod とコンテナのリソース管理をご覧ください。

    リソース リクエストは、サポートされているすべての Config Sync バージョンで同じです。

    Deployment 名 レプリカあたりの CPU リクエスト（m） レプリカあたりのメモリ リクエスト（Mi）
    config-management-operator 100 200
    resource-group-controller-manager 110 300
    admission-webhook1 10 100
    otel-collector 200 400
    reconciler-manager 20 150
    reconciler（RootSync と RepoSync ごとに 1 つ） 詳細については、Reconciler のリソース リクエストをご覧ください。

    1 アドミッション Webhook には 2 つのレプリカがあります。アドミッション Webhook を使用してリソース リクエストの合計を計算する必要がある場合は、値を 2 倍にします。アドミッション Webhook はデフォルトで無効になっています。

    主要コンポーネント

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

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

    Config Sync バージョン 1.20.0 以降では、Hub フリート サービスがクラスタ上の Config Sync コンポーネントを直接管理します。

    Config Sync 管理

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

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

    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 コンテナが作成されます。

    Reconciler のリソース リクエスト

    Config Sync は、RootSync オブジェクトと RepoSync オブジェクトごとに、同期を処理する独立した Reconciler Deployment を作成します。Reconciler Deployment は複数のコンテナで構成されます。これらのコンテナの詳細については、Reconciler コンテナをご覧ください。

    リソース リクエストは、サポートされているすべての Config Sync バージョンで同じです。

    次の表に、Standard クラスタのリソース リクエストを示します。

    コンテナ名 CPU リクエスト（m） メモリ リクエスト（Mi）
    reconciler 50 200
    otel-agent 10 100
    hydration-controller （省略可） 10 100
    git-sync 10 16
    gcenode-askpass-sidecar （省略可） 10 20
    helm-sync 75 128
    oci-sync 25 32

    次の表に、Autopilot クラスタのリソース リクエストを示します。

    コンテナ名 CPU リクエストと上限（m） メモリ リクエストと上限（Mi）
    reconciler 700 512
    otel-agent 10 64
    hydration-controller （省略可） 200 256
    git-sync 20 32
    gcenode-askpass-sidecar （省略可） 50 64
    helm-sync 250 384
    oci-sync 50 64

    デフォルトのリソース リクエストと上限をオーバーライドする方法については、リソース リクエストと上限のオーバーライドをご覧ください。

    バンドルされている Helm と Kustomize のバージョン

    Config Sync は、実行可能ファイル Helm と Kustomize を利用して、構成をレンダリングします。次の表に、レンダリング機能をサポートする Config Sync のバージョンと、バンドルされている Helm と Kustomize のバージョンを示します。

    Config Sync のバージョン Helm のバージョン Kustomize のバージョン
    1.22.0 v3.15.3 v5.3.0
    1.21.0 v3.15.3 v5.3.0
    1.20.0 v3.15.3 v5.3.0

    Kustomize で Helm をレンダリングする方法については、Kustomize で Kubernetes を構成するをご覧ください。Helm API の使用については、Artifact Registry から Helm チャートを同期するをご覧ください。

    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 またはその他の Kubernetes クライアントを使用して編集できます。

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

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

    次のステップ