Config Sync のアーキテクチャ

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

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

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

この図では、ユーザーが信頼できる情報源を作成し、Feature Manager を使用して 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 Controller。
    • otel-collector という名前の Deployment の OpenTelemetry Collector。
    • 省略可: admission-webhook という名前の Deployment の Config Sync Admission Webhook。

    これらのリソースとオブジェクトのほとんどは、Config Sync のインストール時に自動的に作成され、変更する必要はありません。

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

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

Config Sync の Deployment、Pod、コンテナ

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

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

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

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

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

    調整ツール コンテナ

    調整ツール Pod にデプロイされる特定のコンテナは、構成の選択によって異なります。次の表に、これらの調整ツールの各コンテナの機能と、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 ファイルが含まれている場合に有効になります。

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

    ResourceGroup Controller と ResourceGroup オブジェクト

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

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

    Config Sync のオペレーションに影響を及ぼす可能性があるため、ResourceGroup オブジェクトを作成または変更しないでください。

    アドミッション Webhook

    ドリフト防止を有効にすると、Config Sync Admission Webhook が作成されます。ドリフト防止は、変更リクエストを積極的に遮断し、変更を許可する前に信頼できる情報源との整合性を確保します。

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

    RootSync オブジェクトと RepoSync オブジェクト

    RootSync オブジェクトは、指定した信頼できる情報源を監視し、そのソースからオブジェクトをクラスタに適用するルート調整ツールを作成するように 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 またはその他の Kubernetes クライアントを使用して編集できます。root-sync YAML をエクスポートし、ローカルで編集して再適用する方法を示す例については、RootSync 構成ファイルの作成と編集をご覧ください。

    手動インストールの場合は、kubectl コマンドライン ツールまたはその他の Kubernetes クライアントで Config Sync を管理します。

    追加の RootSync オブジェクトと RepoSync オブジェクト

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

    次のステップ