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

このページでは、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 の要件を満たすクラスタを作成するか、このクラスタにアクセスできることを確認します。

制限事項

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

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

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

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

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 がクラスタで有効になっていない場合にのみ、選択してください。

      この認証の種類の詳細については、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 オブジェクトの構成方法については、認証局の Operator の構成をご覧ください。

    フィールドの説明と 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

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

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

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

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

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

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

    フィールドの説明と 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

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

    • 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 がクラスタで有効になっていない場合にのみ選択してください。
      • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

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

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

    • ROOT_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、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 がクラスタで有効になっていない場合にのみ、選択してください。

        この認証の種類の詳細については、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 オブジェクトの構成方法については、認証局の Operator の構成をご覧ください。

    フィールドの説明と 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

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

    • 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

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

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

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

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

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

    フィールドの説明と 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

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

    • 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 がクラスタで有効になっていない場合にのみ選択してください。
      • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

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

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

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

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

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

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

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

    デフォルトの ClusterRole

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

    # 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 がクラスタで有効になっていない場合にのみ、選択してください。

        この認証の種類の詳細については、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 オブジェクトの構成方法については、認証局の Operator の構成をご覧ください。

    フィールドの説明と 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

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

    • 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

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

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

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

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

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

    フィールドの説明と 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

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

    • 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 がクラスタで有効になっていない場合にのみ選択してください。
      • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

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

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

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

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

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

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

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

    デフォルトの ClusterRole

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

    # 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 がクラスタで有効になっていない場合にのみ、選択してください。

      この認証の種類の詳細については、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 オブジェクトの構成方法については、認証局の Operator の構成をご覧ください。

    フィールドの説明と 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

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

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

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

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

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

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

    フィールドの説明と 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

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

    • 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 がクラスタで有効になっていない場合にのみ選択してください。
      • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

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

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

    • ROOT_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、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 がクラスタで有効になっていない場合にのみ、選択してください。

        この認証の種類の詳細については、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 オブジェクトの構成方法については、認証局の Operator の構成をご覧ください。

    フィールドの説明と 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

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

    • 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

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

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

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

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

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

    フィールドの説明と 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

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

    • 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 がクラスタで有効になっていない場合にのみ選択してください。
      • gcpserviceaccount: Google サービス アカウントを使用してイメージにアクセスします。

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

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

    • NAMESPACE_SECRET_NAME: token が ROOT_AUTH_TYPE の場合は、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>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com: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

次のステップ