複数の信頼できる情報源からの同期を構成する

このページでは、RootSync オブジェクトと RepoSync オブジェクトを作成して、複数のルートと Namespace スコープの信頼できる情報源を構成する方法について説明します。

信頼できる情報源のルートを構成することで、クラスタ スコープと Namespace スコープの構成ファイルを同期できます。信頼できる情報源のルートは、管理者レベルの認証情報を使用してアプリケーションの Namespace にポリシーを適用し、構成ファイルで宣言された状態から逸脱しているローカルの変更をオーバーライドできます。通常、信頼できる情報源のルートは中央の管理者が管理します。

Namespace スコープの信頼できる情報源はオプションです。これには、クラスタ間で特定の Namespace に同期される Namespace スコープの構成ファイルを含めることができます。Namespace スコープの信頼できる情報源の設定と管理を管理者以外のユーザーに委任することもできます。Config Sync は、信頼できる情報源からの変更を自動的に検出しますが、Namespace スコープの信頼できる情報源にアドミッション Webhook を追加することで、ドリフト検出のレイヤを追加できます。詳しい方法については、構成ファイルのドリフトを防止するをご覧ください。

始める前に

• Config Sync が同期する構成ファイルを含む信頼できる情報源を非構造化形式で作成するか、この情報源にアクセスできることを確認します。Config Sync は、Git リポジトリ、Helm チャート、OCI イメージを信頼できる情報源としてサポートしています。Namespace スコープの信頼できる情報源には非構造化形式を使用する必要があります。
• Google Kubernetes Engine（GKE）Enterprise エディションのサポート対象プラットフォームとバージョン上にあり、Config Sync の要件を満たすクラスタを作成するか、このクラスタにアクセスできることを確認します。

制限事項

• NamespaceSelectors（Selectors を指すアノテーションを含む）は、信頼できる情報源のルートでのみ機能します。
• Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールした場合、Config Sync は root-sync という名前の RootSync オブジェクトを自動的に作成します。そのため、RootSync オブジェクトの名前を root-sync することはできません。

目的の構成方法を選択する

情報源を構成するには、次の 2 つの方法のいずれかを選択します。

• 信頼できる情報源のルートで情報源を制御する。この方法では、信頼できる情報源のすべての構成が別の信頼できる情報源に一元化され、中央管理者が設定を完全に管理できます。

• Kubernetes API で情報源を管理する。この方法は、信頼できる情報源の制御を別のオーナーに委任する場合に使用します。

信頼できる情報源のルートで情報源を制御する

信頼できる情報源のルートでルート情報源を制御する

Config Sync では、複数の信頼できる情報源からの同期がサポートされています。中央管理者は、ルート情報源を使用して、他のすべての情報源を管理できます。Config Sync は RootSync オブジェクトを管理するため、この方法により、クラスタ内の RootSync 構成がローカルに変更されるのを防ぐことができます。

この方法を使用するには、次の操作を行います。

1. 次のいずれかのマニフェストを root-sync.yaml として保存します。構成ファイルのソースタイプに対応するマニフェスト バージョンを使用します。

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_REPOSITORY: ルート リポジトリとして使用する Git リポジトリの URL を記述します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • ROOT_REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）を追加します。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、revision フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。
   • ROOT_BRANCH: 同期元となるリポジトリのブランチを追加します。このフィールドは省略可能で、デフォルト値は master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、revision フィールドを使用してブランチ名を指定することをおすすめします。revision フィールドと branch フィールドの両方が指定されている場合、revision が branch よりも優先されます。
   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへの Git リポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories にアクセス
     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。

     この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合は、Secret の公開鍵を Git プロバイダに追加する必要があります。このフィールドは省略可能です。

   • ROOT_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Git プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、Git をソースとして使用する RootSync オブジェクトを作成します。

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_IMAGE: ルート リポジトリとして使用する OCI イメージの URL（例: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME）。デフォルトでは、イメージは latest タグから取得されますが、TAG または DIGEST を使用してイメージを pull することもできます。PACKAGE_NAME で TAG または DIGEST を指定します。
     • TAG で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • DIGEST で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   注意: Config Sync では、OCI レイヤを tar または tar+gzip で圧縮する必要があります。他の形式（tar+bz2 など）は Config Sync で認識されません。有効な REPO からサポートされていない形式の OCI イメージに切り替えると、マネージド リソースがエラーなしでプルーニングされます。

   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへのリポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を OCI プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

   CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、OCI イメージをソースとして使用する RootSync オブジェクトを作成します。

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_HELM_REPOSITORY: ルート リポジトリとして使用する Helm リポジトリの URL。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • HELM_CHART_NAME: Helm チャートの名前を追加します。このフィールドは必須です。
   • HELM_CHART_VERSION: チャートのバージョン。このフィールドは省略可能です。値が指定されていない場合は、最新バージョンが使用されます。
   • HELM_RELEASE_NAME: Helm リリースの名前。このフィールドは省略可能です。
   • HELM_RELEASE_NAMESPACE: リリースのターゲット Namespace。テンプレートに namespace: {{ .Release.Namespace }} を含むリソースの Namespace のみが設定されます。このフィールドは省略可能です。値が指定されていない場合は、デフォルトの Namespace config-management-system が使用されます。
   • HELM_INCLUDE_CRDS: Helm テンプレートでも CustomResourceDefinition を生成する場合は、true に設定します。このフィールドは省略可能です。値が指定されていない場合、デフォルトは false であり、CRD は生成されません。
   • VALUE: Helm チャートのデフォルト値の代わりに使用する値。このフィールドを Helm チャートの values.yaml ファイルと同じ方法でフォーマットします。このフィールドは省略可能です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • token: 非公開 Helm リポジトリへのアクセスにユーザー名とパスワードを使用します。
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com。

   • ROOT_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、Secret の名前を追加します。このフィールドは省略可能です。

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Helm プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

   CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、Helm を情報源として使用する RootSync オブジェクトを作成します。

2. 変更を信頼できる情報源のルートに commit します。

    git add .
    git commit -m 'Setting up a new root source of truth.'
    git push
   

3. 複数の情報源のルートを構成する必要がある場合は、上述の手順を繰り返します。複数の RootSync オブジェクトの構成を、別の RootSync オブジェクトによって同期された信頼できる情報源のルートに保存し、複数の RootSync オブジェクトを GitOps 方式で一元管理することもできます。

信頼できる情報源のルートで Namespace スコープ オブジェクトを制御する

Namespace スコープの信頼できる情報源は、信頼できる情報源のルートで管理できます。Namespace スコープの情報源は Config Sync によって管理されるため、この方法では、Namespace スコープの情報源の定義をローカルで変更できなくなります。

この方法を使用するには、次の操作を行います。

1. 信頼できる情報源のルートで、namespace 構成を宣言します。

   # ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml
   apiVersion: v1
   kind: Namespace
   metadata:
     name: NAMESPACE
   

   NAMESPACE は、Namespace の名前に置き換えます。

2. 信頼できる情報源のルートで、同じ Namespace に次のいずれかの RepoSync オブジェクトを作成します。構成ファイルの情報源の種類に応じてマニフェストを使用します。

   Git

   #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: git
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。
   • NAMESPACE_REPOSITORY: Namespace リポジトリとして使用する Git リポジトリの URL を追加します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。このフィールドは必須です。
   • NAMESPACE_REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）を追加します。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、revision フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。
   • NAMESPACE_BRANCH: 同期元となるリポジトリのブランチを追加します。このフィールドは省略可能で、デフォルト値は master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、revision フィールドを使用してブランチ名を指定することをおすすめします。revision フィールドと branch フィールドの両方が指定されている場合、revision が branch よりも優先されます。

   • NAMESPACE_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。

     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。

       この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: NAMESPACE_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • NAMESPACE_SECRET_NAME: Secret に付ける名前を記述します。このフィールドは省略可能です。

   • NAMESPACE_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Git プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できるフィールドの一覧については、RepoSync フィールドをご覧ください。

   OCI

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: oci
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     oci:
       image: NAMESPACE_IMAGE
       dir: NAMESPACE_DIRECTORY
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。

   • NAMESPACE_IMAGE: Namespace ソースとして使用する OCI イメージの URL（例: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME）。デフォルトでは、イメージは latest タグから取得されますが、TAG または DIGEST を使用してイメージを pull することもできます。PACKAGE_NAME で TAG または DIGEST を指定します。

     • TAG で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • DIGEST で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     注意: Config Sync では、OCI レイヤを tar または tar+gzip で圧縮する必要があります。他の形式（tar+bz2 など）は Config Sync で認識されません。有効な REPO からサポートされていない形式の OCI イメージに切り替えると、マネージド リソースがエラーなしでプルーニングされます。

   • NAMESPACE_DIRECTORY: 同期先への構成を含むルート ディレクトリへの情報源のパスを記述します。このフィールドは省略可能です。デフォルトは、情報源のルート ディレクトリ（/）です。

   • NAMESPACE_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を OCI プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   Helm

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: helm
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     helm:
       repo: NAMESPACE_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: NAMESPACE_AUTH_TYPE
         gcpServiceAccountEmail: NAMESPACE_EMAIL
         secretRef:
           name: NAMESPACE_SECRET_NAME
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。
   • NAMESPACE_REPOSITORY: ルート リポジトリとして使用する Helm リポジトリの URL。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • HELM_CHART_NAME: Helm チャートの名前を追加します。このフィールドは必須です。
   • HELM_CHART_VERSION: チャートのバージョン。このフィールドは省略可能です。値が指定されていない場合は、最新バージョンが使用されます。
   • HELM_RELEASE_NAME: Helm リリースの名前。このフィールドは省略可能です。
   • HELM_RELEASE_NAMESPACE: リリースのターゲット Namespace。テンプレートに namespace: {{ .Release.Namespace }} を含むリソースの Namespace のみが設定されます。このフィールドは省略可能です。値が指定されていない場合は、デフォルトの Namespace config-management-system が使用されます。
   • HELM_INCLUDE_CRDS: Helm テンプレートでも CustomResourceDefinition を生成する場合は、true に設定します。このフィールドは省略可能です。値が指定されていない場合、デフォルトは false であり、CRD は生成されません。
   • VALUE: Helm チャートのデフォルト値の代わりに使用する値。このフィールドを Helm チャートの values.yaml ファイルと同じ方法でフォーマットします。このフィールドは省略可能です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • token: 非公開 Helm リポジトリへのアクセスにユーザー名とパスワードを使用します。
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com。

   • NAMESPACE_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、Secret の名前を追加します。このフィールドは省略可能です。

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Helm プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

3. 認証タイプとして gcpserviceaccount を使用していて、Workload Identity Federation for GKE が有効になっていない場合は、それぞれの Namespace と Google サービス アカウントの Kubernetes サービス アカウントの間に IAM ポリシー バインディングを作成する必要があります。このバインディングの作成手順については、Git へのアクセスを許可するをご覧ください。

4. 情報源のルートで RoleBinding 構成を宣言し、Namespace 内のオブジェクトを管理するための権限を SERVICE_ACCOUNT_NAME サービス アカウントに付与します。SERVICE_ACCOUNT_NAME サービス アカウントは、RepoSync 構成ファイルがクラスタに同期される際、Config Sync により自動的に作成されます。

   RoleBinding は、同じ Namespace の Role を参照できます。または、RoleBinding が ClusterRole を参照し、その ClusterRole を RoleBinding の Namespace にバインドできます。ユーザー定義の Role にきめ細かい権限を付与することで、最小権限の原則に従う必要がありますが、ClusterRole を定義したりユーザー向けのロールを使用して、異なる Namespace にまたがる複数の RoleBindings で同じ ClusterRole を参照できます。

   注: ClusterRole を参照する RoleBinding では、RoleBinding の Namespace にのみアクセスできます。クラスタ全体にアクセスすることはできません。

   デフォルトの ClusterRole

   デフォルトの ClusterRole を参照する RoleBinding を宣言できます（admin や edit など）。詳細については、ユーザー向けのロールをご覧ください。

   # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: CLUSTERROLE_NAME
     apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • NAMESPACE: Namespace の名前を記述します。
   • SERVICE_ACCOUNT_NAME: Reconciler のサービス アカウントの名前を追加します。RepoSync の名前が repo-sync の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH です。たとえば、RepoSync の名前が prod の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE-prod-4 になります。prod には 4 文字が含まれるため、整数 4 が使用されます。
   • CLUSTERROLE_NAME: デフォルトの ClusterRole の名前を追加します。

   ユーザー定義のロール

   ClusterRole または Role を宣言するには、RepoSync オブジェクトによって管理される各リソースに権限のリストを付与します。これにより、きめ細かい権限を付与できます。詳しくは、リソースの参照をご覧ください。

   たとえば、次の ClusterRole または Role は、Deployment オブジェクトと ServiceAccount オブジェクトを管理するための権限を付与します。

   # ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ROLE_KIND
   metadata:
     namespace: NAMESPACE # only set this field for a 'Role'
     name: RECONCILER_ROLE
   rules:
   # Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
   - apiGroups: ["apps"]
     resources: ["deployments"]
     verbs: ["*"]
   - apiGroups: [""]
     resources: ["serviceaccounts"]
     verbs: ["*"]
   

   ClusterRole または Role を参照する RoleBinding を宣言するには、次のオブジェクトを作成します。RoleBinding は、Config Sync が特定の RepoSync の Namespace スコープのリソースを管理できるように、追加の権限を付与します。

   # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ROLE_KIND
     name: RECONCILER_ROLE
     apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • ROLE_KIND: ClusterRole または Role を設定します。
   • NAMESPACE: Namespace の名前を記述します。
   • SERVICE_ACCOUNT_NAME: Reconciler のサービス アカウントの名前を追加します。RepoSync の名前が repo-sync の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH です。たとえば、RepoSync の名前が prod の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE-prod-4 になります。prod には 4 文字が含まれるため、整数 4 が使用されます。
   • RECONCILER_ROLE: ClusterRole または Role の名前を追加します。

5. 変更を信頼できる情報源のルートに commit します。

    git add .
    git commit -m 'Setting up a new namespace-scoped source of truth.'
    git push
   

6. 必要に応じて、任意の認証方法に基づいて Secret を作成します。認証タイプに none を使用した場合は、このステップはスキップできます。

   Secret は、次の要件を満たす必要があります。

   • Secret は、RepoSync と同じ Namespace に作成します。
   • Secret の名前は、repo-sync.yaml で定義した spec.git.secretRef の名前と一致する必要があります。
   • Secret の公開鍵は、Git プロバイダに追加する必要があります。

7. 構成を確認するには、Namespace ソースのオブジェクトの 1 つに対して kubectl get を使用します。次に例を示します。

   kubectl get rolebindings -n NAMESPACE
   

8. Namespace スコープの情報源を複数構成する必要がある場合は、上記の手順を繰り返します。

Namespace スコープの情報源で Namespace スコープの情報源を制御する

Config Sync では、Namespace ごとに複数の Namespace スコープからの同期がサポートされています。Namespace スコープの信頼できる情報源は、同じ Namespace の Namespace スコープの信頼できる情報源で管理できます。

この方法を使用するには、次の操作を行います。

1. Namespace スコープの信頼できる情報源で、同じ Namespace に次のいずれかの RepoSync オブジェクトを作成します。構成ファイルの情報源の種類に応じてマニフェストを使用します。

   Git

   #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: git
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。
   • NAMESPACE_REPOSITORY: Namespace リポジトリとして使用する Git リポジトリの URL を追加します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。このフィールドは必須です。
   • NAMESPACE_REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）を追加します。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、revision フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。
   • NAMESPACE_BRANCH: 同期元となるリポジトリのブランチを追加します。このフィールドは省略可能で、デフォルト値は master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、revision フィールドを使用してブランチ名を指定することをおすすめします。revision フィールドと branch フィールドの両方が指定されている場合、revision が branch よりも優先されます。

   • NAMESPACE_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。

     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。

       この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: NAMESPACE_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • NAMESPACE_SECRET_NAME: Secret に付ける名前を記述します。このフィールドは省略可能です。

   • NAMESPACE_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Git プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できるフィールドの一覧については、RepoSync フィールドをご覧ください。

   OCI

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: oci
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     oci:
       image: NAMESPACE_IMAGE
       dir: NAMESPACE_DIRECTORY
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。

   • NAMESPACE_IMAGE: Namespace ソースとして使用する OCI イメージの URL（例: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME）。デフォルトでは、イメージは latest タグから取得されますが、TAG または DIGEST を使用してイメージを pull することもできます。PACKAGE_NAME で TAG または DIGEST を指定します。

     • TAG で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • DIGEST で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     注意: Config Sync では、OCI レイヤを tar または tar+gzip で圧縮する必要があります。他の形式（tar+bz2 など）は Config Sync で認識されません。有効な REPO からサポートされていない形式の OCI イメージに切り替えると、マネージド リソースがエラーなしでプルーニングされます。

   • NAMESPACE_DIRECTORY: 同期先への構成を含むルート ディレクトリへの情報源のパスを記述します。このフィールドは省略可能です。デフォルトは、情報源のルート ディレクトリ（/）です。

   • NAMESPACE_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を OCI プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   Helm

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: helm
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     helm:
       repo: NAMESPACE_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: NAMESPACE_AUTH_TYPE
         gcpServiceAccountEmail: NAMESPACE_EMAIL
         secretRef:
           name: NAMESPACE_SECRET_NAME
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。
   • NAMESPACE_REPOSITORY: ルート リポジトリとして使用する Helm リポジトリの URL。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • HELM_CHART_NAME: Helm チャートの名前を追加します。このフィールドは必須です。
   • HELM_CHART_VERSION: チャートのバージョン。このフィールドは省略可能です。値が指定されていない場合は、最新バージョンが使用されます。
   • HELM_RELEASE_NAME: Helm リリースの名前。このフィールドは省略可能です。
   • HELM_RELEASE_NAMESPACE: リリースのターゲット Namespace。テンプレートに namespace: {{ .Release.Namespace }} を含むリソースの Namespace のみが設定されます。このフィールドは省略可能です。値が指定されていない場合は、デフォルトの Namespace config-management-system が使用されます。
   • HELM_INCLUDE_CRDS: Helm テンプレートでも CustomResourceDefinition を生成する場合は、true に設定します。このフィールドは省略可能です。値が指定されていない場合、デフォルトは false であり、CRD は生成されません。
   • VALUE: Helm チャートのデフォルト値の代わりに使用する値。このフィールドを Helm チャートの values.yaml ファイルと同じ方法でフォーマットします。このフィールドは省略可能です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • token: 非公開 Helm リポジトリへのアクセスにユーザー名とパスワードを使用します。
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com。

   • NAMESPACE_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、Secret の名前を追加します。このフィールドは省略可能です。

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Helm プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

2. 認証タイプとして gcpserviceaccount を使用していて、Workload Identity Federation for GKE が有効になっていない場合は、それぞれの Namespace と Google サービス アカウントの Kubernetes サービス アカウントの間に IAM ポリシー バインディングを作成する必要があります。このバインディングの作成手順については、Git へのアクセスを許可するをご覧ください。

3. 情報源のルートで RoleBinding 構成を宣言し、Namespace 内のオブジェクトを管理するための権限を SERVICE_ACCOUNT_NAME サービス アカウントに付与します。SERVICE_ACCOUNT_NAME サービス アカウントは、RepoSync 構成ファイルがクラスタに同期される際、Config Sync により自動的に作成されます。

   RoleBinding は、同じ Namespace の Role を参照できます。または、RoleBinding が ClusterRole を参照し、その ClusterRole を RoleBinding の Namespace にバインドできます。ユーザー定義の Role にきめ細かい権限を付与することで、最小権限の原則に従う必要がありますが、ClusterRole を定義したりユーザー向けのロールを使用して、異なる Namespace にまたがる複数の RoleBindings で同じ ClusterRole を参照できます。

   注: ClusterRole を参照する RoleBinding では、RoleBinding の Namespace にのみアクセスできます。クラスタ全体にアクセスすることはできません。

   デフォルトの ClusterRole

   デフォルトの ClusterRole を参照する RoleBinding を宣言できます（admin や edit など）。詳細については、ユーザー向けのロールをご覧ください。

   # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: CLUSTERROLE_NAME
     apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • NAMESPACE: Namespace の名前を記述します。
   • SERVICE_ACCOUNT_NAME: Reconciler のサービス アカウントの名前を追加します。RepoSync の名前が repo-sync の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH です。たとえば、RepoSync の名前が prod の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE-prod-4 になります。prod には 4 文字が含まれるため、整数 4 が使用されます。
   • CLUSTERROLE_NAME: デフォルトの ClusterRole の名前を追加します。

   ユーザー定義のロール

   ClusterRole または Role を宣言するには、RepoSync オブジェクトによって管理される各リソースに権限のリストを付与します。これにより、きめ細かい権限を付与できます。詳しくは、リソースの参照をご覧ください。

   たとえば、次の ClusterRole または Role は、Deployment オブジェクトと ServiceAccount オブジェクトを管理するための権限を付与します。

   # ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ROLE_KIND
   metadata:
     namespace: NAMESPACE # only set this field for a 'Role'
     name: RECONCILER_ROLE
   rules:
   # Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
   - apiGroups: ["apps"]
     resources: ["deployments"]
     verbs: ["*"]
   - apiGroups: [""]
     resources: ["serviceaccounts"]
     verbs: ["*"]
   

   ClusterRole または Role を参照する RoleBinding を宣言するには、次のオブジェクトを作成します。RoleBinding は、Config Sync が特定の RepoSync の Namespace スコープのリソースを管理できるように、追加の権限を付与します。

   # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ROLE_KIND
     name: RECONCILER_ROLE
     apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • ROLE_KIND: ClusterRole または Role を設定します。
   • NAMESPACE: Namespace の名前を記述します。
   • SERVICE_ACCOUNT_NAME: Reconciler のサービス アカウントの名前を追加します。RepoSync の名前が repo-sync の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH です。たとえば、RepoSync の名前が prod の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE-prod-4 になります。prod には 4 文字が含まれるため、整数 4 が使用されます。
   • RECONCILER_ROLE: ClusterRole または Role の名前を追加します。

4. 変更を信頼できる情報源のルートに commit します。

    git add .
    git commit -m 'Setting up a new namespace-scoped source of truth.'
    git push
   

5. 必要に応じて、任意の認証方法に基づいて Secret を作成します。認証タイプに none を使用した場合は、このステップはスキップできます。

   Secret は、次の要件を満たす必要があります。

   • Secret は、RepoSync と同じ Namespace に作成します。
   • Secret の名前は、repo-sync.yaml で定義した spec.git.secretRef の名前と一致する必要があります。
   • Secret の公開鍵は、Git プロバイダに追加する必要があります。

6. 構成を確認するには、Namespace スコープの信頼できる情報源のオブジェクトの 1 つに対して kubectl get を使用します。次に例を示します。

   kubectl get rolebindings -n NAMESPACE
   

7. Namespace スコープの情報源を複数構成する必要がある場合は、上記の手順を繰り返します。

Kubernetes API で信頼できる情報源を管理する

この方法では、中央管理者が他の RootSync オブジェクトの宣言を他の管理者に委任します。RepoSync オブジェクトの場合、中央管理者は信頼できる情報源のルート内で Namespace の宣言のみを行い、RepoSync オブジェクトの宣言をアプリケーション オペレータに委任します。

信頼できる情報源の複数のルートを制御する

他の管理者は、次のタスクを実行して、信頼できる情報源のルートを制御できます。

1. 次のいずれかのマニフェストを root-sync.yaml として保存します。構成ファイルのソースタイプに対応するマニフェスト バージョンを使用します。

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_REPOSITORY: ルート リポジトリとして使用する Git リポジトリの URL を記述します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • ROOT_REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）を追加します。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、revision フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。
   • ROOT_BRANCH: 同期元となるリポジトリのブランチを追加します。このフィールドは省略可能で、デフォルト値は master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、revision フィールドを使用してブランチ名を指定することをおすすめします。revision フィールドと branch フィールドの両方が指定されている場合、revision が branch よりも優先されます。
   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへの Git リポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories にアクセス
     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。

     この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合は、Secret の公開鍵を Git プロバイダに追加する必要があります。このフィールドは省略可能です。

   • ROOT_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Git プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、Git をソースとして使用する RootSync オブジェクトを作成します。

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_IMAGE: ルート リポジトリとして使用する OCI イメージの URL（例: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME）。デフォルトでは、イメージは latest タグから取得されますが、TAG または DIGEST を使用してイメージを pull することもできます。PACKAGE_NAME で TAG または DIGEST を指定します。
     • TAG で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • DIGEST で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   注意: Config Sync では、OCI レイヤを tar または tar+gzip で圧縮する必要があります。他の形式（tar+bz2 など）は Config Sync で認識されません。有効な REPO からサポートされていない形式の OCI イメージに切り替えると、マネージド リソースがエラーなしでプルーニングされます。

   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへのリポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を OCI プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

   CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、OCI イメージをソースとして使用する RootSync オブジェクトを作成します。

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • ROOT_SYNC_NAME: RootSync オブジェクトの名前を追加します。
   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_HELM_REPOSITORY: ルート リポジトリとして使用する Helm リポジトリの URL。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • HELM_CHART_NAME: Helm チャートの名前を追加します。このフィールドは必須です。
   • HELM_CHART_VERSION: チャートのバージョン。このフィールドは省略可能です。値が指定されていない場合は、最新バージョンが使用されます。
   • HELM_RELEASE_NAME: Helm リリースの名前。このフィールドは省略可能です。
   • HELM_RELEASE_NAMESPACE: リリースのターゲット Namespace。テンプレートに namespace: {{ .Release.Namespace }} を含むリソースの Namespace のみが設定されます。このフィールドは省略可能です。値が指定されていない場合は、デフォルトの Namespace config-management-system が使用されます。
   • HELM_INCLUDE_CRDS: Helm テンプレートでも CustomResourceDefinition を生成する場合は、true に設定します。このフィールドは省略可能です。値が指定されていない場合、デフォルトは false であり、CRD は生成されません。
   • VALUE: Helm チャートのデフォルト値の代わりに使用する値。このフィールドを Helm チャートの values.yaml ファイルと同じ方法でフォーマットします。このフィールドは省略可能です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • token: 非公開 Helm リポジトリへのアクセスにユーザー名とパスワードを使用します。
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com。

   • ROOT_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、Secret の名前を追加します。このフィールドは省略可能です。

   • ROOT_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Helm プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

   CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   このマニフェストは、Helm を情報源として使用する RootSync オブジェクトを作成します。

2. 変更を適用します。

   kubectl apply -f root-sync.yaml
   

3. 信頼できる情報源の複数のルートを構成する必要がある場合は、上記の手順を繰り返します。

Namespace スコープの信頼できる情報源を制御する

中央管理者の作業

中央管理者は、次の作業を行います。

1. 信頼できる情報源のルートで、Namespace スコープの情報源の namespace 構成を宣言します。

   # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
    apiVersion: v1
    kind: Namespace
    metadata:
      name: NAMESPACE
   

   NAMESPACE は、Namespace の名前に置き換えます。

2. 信頼できる情報源のルートで RoleBinding を宣言し、アプリケーション オペレータに権限を付与します。RBAC エスカレーション防止を使用して、アプリケーション オペレータが、このロール バインディングで付与されない権限を含むロール バインディングを適用できないようにします。

   RoleBinding を宣言するには、次のマニフェストを作成します。

   # ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
    kind: RoleBinding
    # Add RBAC escalation prevention
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: operator
      namespace: NAMESPACE
    subjects:
    - kind: User
      name: USERNAME
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: OPERATOR_ROLE
      apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • NAMESPACE: 信頼できる情報源のルートで作成した Namespace を追加します。
   • USERNAME: アプリケーション オペレータのユーザー名を記述します。

   • OPERATOR_ROLE: 中央管理者として OPERATOR_ROLE を設定することで、Namespace スコープの情報源から同期できる構成の種類を指定できます。ロールは、次のいずれかを選択できます。

     • デフォルトの ClusterRole。

       • admin
       • edit

       詳細については、ユーザー向けのロールをご覧ください。

     • 信頼できる情報源のルートで宣言されているユーザー定義の ClusterRole または Role。このロールを使用すると、きめ細かい権限を付与できます。

3. 変更を信頼できる情報源のルートに commit します。

    git add .
    git commit -m 'Setting up new namespace-scoped source of truth.'
    git push
   

アプリケーション オペレータの作業

アプリケーション オペレータは、次の操作を行うことで、Namespace スコープの情報源を制御できます。

1. RoleBinding 構成を宣言し、Namespace 内のオブジェクトを管理するための権限を SERVICE_ACCOUNT_NAME サービス アカウントに付与します。SERVICE_ACCOUNT_NAME サービス アカウントは、RepoSync 構成ファイルがクラスタに同期される際、Config Sync により自動的に作成されます。

   RoleBinding を宣言するには、次のマニフェストを作成します。

   # sync-rolebinding.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: RECONCILER_ROLE
     apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • NAMESPACE: 信頼できる情報源のルートで作成した Namespace を追加します。
   • SERVICE_ACCOUNT_NAME: Reconciler のサービス アカウントの名前を追加します。RepoSync の名前が repo-sync の場合、SERVICE_ACCOUNT_NAME は ns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME です。
   • RECONCILER_ROLE: アプリケーション オペレータとして、RECONCILER_ROLE を設定することで、Namespace リポジトリから同期できる構成の種類を指定できます。中央管理者によって付与された一連の権限のセットがさらに制限される可能性があります。そのため、このロールでは、前のセクションで中央管理者が宣言した OPERATOR_ROLE 以上の権限を与えることはできません。

2. RoleBinding 構成を適用します。

   kubectl apply -f sync-rolebinding.yaml
   

3. 必要に応じて、任意の認証方法に基づいて Secret を作成します。認証タイプに none を使用した場合は、このステップはスキップできます。

   Secret は、次の要件を満たす必要があります。

   • Secret は、RepoSync と同じ Namespace に作成します。
   • Secret の名前は、root-sync.yaml で定義した spec.git.secretRef の名前と一致する必要があります。
   • Secret の公開鍵は、Git プロバイダに追加する必要があります。

4. RepoSync 構成を宣言します。

   Git

   #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: git
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。
   • NAMESPACE_REPOSITORY: Namespace リポジトリとして使用する Git リポジトリの URL を追加します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。このフィールドは必須です。
   • NAMESPACE_REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）を追加します。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、revision フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。
   • NAMESPACE_BRANCH: 同期元となるリポジトリのブランチを追加します。このフィールドは省略可能で、デフォルト値は master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、revision フィールドを使用してブランチ名を指定することをおすすめします。revision フィールドと branch フィールドの両方が指定されている場合、revision が branch よりも優先されます。

   • NAMESPACE_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。

     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。

       この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: NAMESPACE_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • NAMESPACE_SECRET_NAME: Secret に付ける名前を記述します。このフィールドは省略可能です。

   • NAMESPACE_NO_SSL_VERIFY: SSL 証明書の検証を無効にするには、このフィールドを true に設定します。デフォルト値は false です。

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Git プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できるフィールドの一覧については、RepoSync フィールドをご覧ください。

   OCI

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: oci
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     oci:
       image: NAMESPACE_IMAGE
       dir: NAMESPACE_DIRECTORY
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。

   • NAMESPACE_IMAGE: Namespace ソースとして使用する OCI イメージの URL（例: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME）。デフォルトでは、イメージは latest タグから取得されますが、TAG または DIGEST を使用してイメージを pull することもできます。PACKAGE_NAME で TAG または DIGEST を指定します。

     • TAG で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • DIGEST で pull するには: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     注意: Config Sync では、OCI レイヤを tar または tar+gzip で圧縮する必要があります。他の形式（tar+bz2 など）は Config Sync で認識されません。有効な REPO からサポートされていない形式の OCI イメージに切り替えると、マネージド リソースがエラーなしでプルーニングされます。

   • NAMESPACE_DIRECTORY: 同期先への構成を含むルート ディレクトリへの情報源のパスを記述します。このフィールドは省略可能です。デフォルトは、情報源のルート ディレクトリ（/）です。

   • NAMESPACE_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を OCI プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

   Helm

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: helm
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     helm:
       repo: NAMESPACE_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: NAMESPACE_AUTH_TYPE
         gcpServiceAccountEmail: NAMESPACE_EMAIL
         secretRef:
           name: NAMESPACE_SECRET_NAME
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   次のように置き換えます。

   • REPO_SYNC_NAME: RepoSync オブジェクトの名前を追加します。名前は Namespace 全体で一意である必要があります。
   • NAMESPACE: Namespace の名前を記述します。
   • NAMESPACE_REPOSITORY: ルート リポジトリとして使用する Helm リポジトリの URL。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。このフィールドは必須です。
   • HELM_CHART_NAME: Helm チャートの名前を追加します。このフィールドは必須です。
   • HELM_CHART_VERSION: チャートのバージョン。このフィールドは省略可能です。値が指定されていない場合は、最新バージョンが使用されます。
   • HELM_RELEASE_NAME: Helm リリースの名前。このフィールドは省略可能です。
   • HELM_RELEASE_NAMESPACE: リリースのターゲット Namespace。テンプレートに namespace: {{ .Release.Namespace }} を含むリソースの Namespace のみが設定されます。このフィールドは省略可能です。値が指定されていない場合は、デフォルトの Namespace config-management-system が使用されます。
   • HELM_INCLUDE_CRDS: Helm テンプレートでも CustomResourceDefinition を生成する場合は、true に設定します。このフィールドは省略可能です。値が指定されていない場合、デフォルトは false であり、CRD は生成されません。
   • VALUE: Helm チャートのデフォルト値の代わりに使用する値。このフィールドを Helm チャートの values.yaml ファイルと同じ方法でフォーマットします。このフィールドは省略可能です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • token: 非公開 Helm リポジトリへのアクセスにユーザー名とパスワードを使用します。
     • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

     このフィールドは必須です。

   • NAMESPACE_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com。

   • NAMESPACE_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、Secret の名前を追加します。このフィールドは省略可能です。

   • NAMESPACE_CA_CERT_SECRET_NAME: Secret の名前を追加します。このフィールドが設定されている場合、この認証局（CA）によって発行された証明書を Helm プロバイダで使用する必要があります。cert という名前の鍵の CA 証明書を Secret に含める必要があります。このフィールドは省略可能です。

     CA 証明書の Secret オブジェクトの構成方法については、認証局を構成するをご覧ください。

   フィールドの説明と spec フィールドに追加できる項目の全一覧については、RootSync フィールドをご覧ください。

5. RepoSync 構成を適用します。

   kubectl apply -f repo-sync.yaml
   

6. 構成を確認するには、Namespace スコープの情報源のオブジェクトの 1 つに kubectl get を使用します。次に例を示します。

   kubectl get rolebindings -n NAMESPACE
   

7. Namespace スコープの信頼できる情報源を複数構成する必要がある場合は、上の手順を繰り返します。

信頼できる情報源の同期ステータスを確認する

nomos status コマンドを使用して、信頼できる情報源の同期ステータスを検査できます。

nomos status

出力は次の例のようになります。

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  [e-mail]:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

この出力例では、Namespace スコープの情報源（この場合は Git リポジトリ）が bookstore という名前の Namespace に構成されています。

RootSync のインストールを確認する

RootSync オブジェクトを作成すると、Config Sync によって接頭辞が root-reconciler の Reconciler が作成されます。Reconciler は、Deployment としてデプロイされる Pod です。信頼できる情報源からクラスタにマニフェストを同期します。

RootSync オブジェクトが正しく機能していることは、root-reconciler Deployment のステータスをチェックして確認できます。

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

ROOT_SYNC_NAME は、RootSync の名前に置き換えます。

出力は次の例のようになります。

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

RootSync オブジェクトのステータスを確認する別の方法については、RootSync オブジェクトと RepoSync オブジェクトのモニタリングをご覧ください。

RepoSync のインストールを確認する

RepoSync オブジェクトを作成すると、Config Sync によって接頭辞が ns-reconciler-NAMESPACE の Reconciler が作成されます。ここで、NAMESPACE は RepoSync オブジェクトを作成した Namespace です。

RepoSync オブジェクトが正しく機能していることは、Namespace Reconciler の Deployment のステータスをチェックして確認します。

kubectl get -n config-management-system deployment \
  -l configsync.gke.io/sync-name=REPO_SYNC_NAME \
  -l configsync.gke.io/sync-namespace=NAMESPACE

REPO_SYNC_NAME を RepoSync の名前に置き換えます。NAMESPACE は、Namespace スコープの信頼できる情報源を作成した Namespace に置き換えます。

RepoSync オブジェクトのステータスを確認する別の方法については、RootSync オブジェクトと RepoSync オブジェクトの確認をご覧ください。

信頼できる情報源を削除する

[Central Control method] タブまたは [Kubernetes API method] タブを選択して、関連する手順を表示します。

中央管理方式

信頼できる情報源のルートで信頼できる情報源を管理する方法を使用した場合、中央管理者は次の 2 つの手順で信頼できる情報源を削除できます。

1. RootSync オブジェクトと RepoSync オブジェクトによって管理されているリソースを削除するか、保持するかを決定します。

   • RootSync オブジェクトまたは RepoSync オブジェクトが管理しているすべてのリソースを削除するには、RootSync オブジェクトまたは RepoSync オブジェクトを空のソースに同期します。たとえば、構成のない GitHub リポジトリなどです。RootSync オブジェクトまたは RepoSync オブジェクトに別の RootSync オブジェクトまたは RepoSync オブジェクトが含まれている場合、内部の RootSync または RepoSync は最初に空の Git リポジトリに同期する必要があります。

   • Webhook を有効にしてリソースを保持する場合は、放棄されたリソースのドリフト防止を無効にします。Webhook を有効にしていない場合は、リソースを保持するために追加操作を行う必要はありません。

2. RootSync オブジェクトまたは RepoSync オブジェクトを信頼できる情報源から削除します。

Kubernetes API 方式

Kubernetes API で Namespace スコープの信頼できる情報源を制御する方法を使用した場合、アプリケーション オペレータは次の手順で Namespace スコープの信頼できる情報源を削除できます。

1. RootSync オブジェクトと RepoSync オブジェクトによって管理されているリソースを削除するか、保持するかを決定します。

   • RootSync オブジェクトまたは RepoSync オブジェクトが管理しているすべてのリソースを削除するには、RootSync オブジェクトまたは RepoSync オブジェクトを空のソースに同期します。たとえば、構成のない GitHub リポジトリなどです。RootSync オブジェクトまたは RepoSync オブジェクトに別の RootSync オブジェクトまたは RepoSync オブジェクトが含まれている場合、内部の RootSync または RepoSync は最初に空の Git リポジトリに同期する必要があります。

   • Webhook を有効にしてリソースを保持する場合は、放棄されたリソースのドリフト防止を無効にします。Webhook を有効にしていない場合は、リソースを保持するために追加操作を行う必要はありません。

2. 次のコマンドを実行して、RootSync オブジェクトまたは RepoSync オブジェクトを削除します。

   kubectl delete -f FILE_NAME
   

   FILE_NAME は、RootSync または RepoSync 構成ファイルの名前に置き換えます。例: root-sync.yaml

次のステップ

• Namespace スコープの信頼できる情報源で構成ファイルのドリフトを防止する方法を学習する。
• RootSync オブジェクトと RepoSync オブジェクトをモニタリングする方法を確認する。
• 信頼できる情報源を複数の信頼できる情報源に分割する方法を確認する。