Config Sync のインストール

SSH 認証鍵ペア

SSH 認証鍵ペアは、公開鍵と秘密鍵の 2 つのファイルから構成されています。通常、公開鍵の拡張子は .pub です。

SSH 認証鍵ペアを使用するには、次の手順に従います。

1. SSH 認証鍵ペアを作成し、Config Sync が Git リポジトリに対して認証されるようにします。この手順は、リポジトリのクローンを作成するか、リポジトリの内容を読み取る際にリポジトリに対する認証が必要になる場合に必要になります。鍵ペアがセキュリティ管理者から提供される場合は、この手順を省略します。自社のセキュリティとコンプライアンスの要件に応じて、すべてのクラスタに対して単一の鍵ペアを使用するか、クラスタごとに 1 つの鍵ペアを使用するかを選びます。

   次のコマンドは 4,096 ビットの RSA 鍵を作成します。これよりビット数の少ない鍵はおすすめできません。

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

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

   • GIT_REPOSITORY_USERNAME: Config Sync がリポジトリに対する認証で使用するユーザー名。
   • /path/to/KEYPAIR_FILENAME: 鍵ペアへのパス。

   GitHub などのサードパーティ Git リポジトリ ホストを使用している場合や、Cloud Source Repositories でサービス アカウントを使用する場合は、別のアカウントを使用することをおすすめします。

2. 新しく作成した公開鍵を認識するようにリポジトリを構成します。ご使用の Git ホスティング プロバイダのドキュメントをご覧ください。よく使われる Git ホスティング プロバイダの手順へのリンクを以下に示します。

   • Cloud Source Repositories
   • Bitbucket
   • GitHub 単一の GitHub リポジトリへの読み取り専用アクセスを提供するために、個別のデプロイキーを作成することをおすすめします。
   • GitLab

3. 秘密鍵をクラスタ内の新しい Secret に追加します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   /path/to/KEYPAIR_PRIVATE_KEY_FILENAME は、秘密鍵の名前に置き換えます（.pub 拡張子は付けません）。

4. （推奨）SSH 認証を使用して既知のホストのチェックを構成するには、git_creds Secret の data.known_hosts フィールドに既知のホストキーを追加します。known_hosts のチェックを無効にするには、Secret から known_hosts フィールドを削除します。既知のホスト鍵を追加するには、次のコマンドを実行します。

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   次に、data の下に、既知のホストのエントリを追加します。

   known_hosts: KNOWN_HOSTS_KEY
   

5. ローカル ディスクから秘密鍵を削除するか、秘密鍵を保護します。

6. Config Sync を構成して Git リポジトリの URL を追加する場合は、SSH プロトコルを使用します。Cloud Source Repositories のリポジトリを使用している場合は、URL を入力する際に次の形式を使用する必要があります。

   ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
   

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

   • EMAIL: Google Cloud ユーザー名
   • PROJECT_ID: リポジトリが配置されている Google Cloud プロジェクトの ID
   • REPO_NAME: リポジトリの名前

Cookiefile

cookiefile を取得するプロセスは、リポジトリの構成によって異なります。サンプルについては、Cloud Source Repositories のドキュメントの静的認証情報を生成するをご覧ください。認証情報は通常、ユーザーのホーム ディレクトリにある .gitcookies ファイルに保存されますが、セキュリティ管理者から提供されることもあります。

cookiefile を作成するには、次の手順を行います。

1. cookiefile を作成して取得したら、クラスタの新しい Secret に追加します。

   HTTPS プロキシを使用しない場合は、次のコマンドを使用して Secret を作成します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   HTTPS プロキシを使用する必要がある場合は、次のコマンドを実行して、cookiefile と一緒に Secret に追加します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

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

   • /path/to/COOKIEFILE: 適切なパスとファイル名
   • HTTPS_PROXY_URL: Git リポジトリとの通信時に使用する HTTPS プロキシの URL

2. 引き続きローカルで必要な場合は、cookiefile の内容を保護します。必要でなければ削除します。

トークン

組織で SSH 認証鍵の使用が許可されていない場合は、トークンを使用することをおすすめします。Config Sync では、トークンとして GitHub の個人アクセス トークン（PAT）、GiLab の PAT、デプロイキー、Bitbucket のアプリ パスワードを使用できます。

トークンを使用して Secret を作成するには、次の手順を行います。

1. GitHub または Bitbucket を使用してトークンを作成します。

   • GitHub: PAT を作成します。トークンに repo スコープを付与し、非公開リポジトリから読み取れるようにします。PAT を GitHub アカウントにバインドするため、マシンユーザーを作成し、PAT をそのマシンユーザーにバインドすることをおすすめします。
   • GitLab: PAT を作成するか、デプロイ トークンを作成します。
   • Bitbucket: アプリ パスワードを作成します。

2. トークンを作成して取得したら、それをクラスタの新しい Secret に追加します。

   HTTPS プロキシを使用しない場合は、次のコマンドを使用して Secret を作成します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

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

   • USERNAME: 使用するユーザー名。
   • TOKEN: 前のステップで作成したトークン。

   HTTPS プロキシを使用する必要がある場合は、次のコマンドを実行して、username および token と一緒に Secret に追加します。

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

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

   • USERNAME: 使用するユーザー名。
   • TOKEN: 前のステップで作成したトークン。
   • HTTPS_PROXY_URL: Git リポジトリとの通信時に使用する HTTPS プロキシの URL。

3. ローカルでのトークンが必要な場合は、トークンを保護します。必要でなければ削除します。

Google サービス アカウント

リポジトリが Cloud Source Repositories にあり、クラスタが GKE Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用している場合は、Google サービス アカウントを使用して、マネージド クラスタと同じプロジェクト内のリポジトリに対するアクセス権を Config Sync に付与できます。

1. サービス アカウントがない場合は、サービス アカウントを作成します。

2. Google サービス アカウントに Cloud Source Repositories 読み取り（roles/source.reader）IAM ロールを付与します。Cloud Source Repositories のロールと権限の詳細については、リポジトリの表示権限を付与するをご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

3. Google Cloud コンソールを使用して Config Sync を構成する場合は、[認証タイプ] で [Workload Identity Federation for GKE] を選択し、サービス アカウントのメールアドレスを追加します。

   Google Cloud CLI を使用して Config Sync を構成する場合は、gcpserviceaccount を secretType として追加し、サービス アカウントのメールアドレスを gcpServiceAccountEmail に追加します。

4. Config Sync の構成が完了したら、Kubernetes サービス アカウントと Google サービス アカウントの間に IAM ポリシー バインディングを作成します。Config Sync を初めて構成するまで、Kubernetes サービス アカウントは作成されません。

   フリートに登録されたクラスタを使用している場合は、フリートごとに 1 回だけポリシー バインディングを作成する必要があります。フリートに登録されたすべてのクラスタは、同じ Workload Identity Federation for GKE プールを共有します。フリートのコンセプトである同一性により、1 つのクラスタの Kubernetes サービス アカウントに IAM ポリシーを追加すると、同じフリート内の他のクラスタでも同じ Namespace の Kubernetes サービス アカウントが同じ IAM ポリシーを取得します。

   このバインディングにより、Config Sync Kubernetes サービス アカウントが Google サービス アカウントとして機能できるようになります。

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

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

• PROJECT_ID: 組織のプロジェクト ID。
• FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
• GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
• KSA_NAME: Reconciler の Kubernetes サービス アカウント。
  • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールする場合、root-sync という名前の RootSync オブジェクトが自動的に作成されます。
• REPOSITORY: リポジトリの名前。
• POLICY_FILE は、Identity and Access Management ポリシーを含む JSON または YAML ファイルです。

Compute Engine のデフォルトのサービス アカウント

リポジトリが Cloud Source Repositories にあり、クラスタが Workload Identity Federation for GKE が無効になっている GKE である場合は、認証タイプとして gcenode を使用できます。

Google Cloud コンソールを使用して Config Sync を構成する場合は、[認証タイプ] に [Google Cloud Repository] を選択します。

Google Cloud CLI を使用して Config Sync を構成する場合は、gcenode を secretType として追加します。

Google Cloud Repository または gcenode を選択すると、Compute Engine のデフォルトのサービス アカウントを使用できます。Compute Engine のデフォルト サービス アカウントに Cloud Source Repositories 読み取り（roles/source.reader）IAM ロールを付与する必要があります。Cloud Source Repositories のロールと権限の詳細については、リポジトリの表示権限を付与するをご覧ください。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

PROJECT_ID は組織のプロジェクト ID に置き換え、PROJECT_NUMBER は組織のプロジェクト番号に置き換えます。

GitHub アプリ

リポジトリが GitHub にある場合は、認証タイプとして githubapp を使用できます。

GitHub アプリを使用する手順は次のとおりです。

1. GitHub の手順に沿って GitHub アプリをプロビジョニングし、リポジトリからの読み取り権限を付与します。

2. GitHub アプリの構成をクラスタ内の新しい Secret に追加します。

   クライアント ID の使用

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • CLIENT_ID は、GitHub アプリのクライアント ID に置き換えます。
   • INSTALLATION_ID は、GitHub アプリのインストール ID に置き換えます。
   • /path/to/GITHUB_PRIVATE_KEY は、秘密鍵を含むファイルの名前に置き換えます。
   • BASE_URL は、GitHub API エンドポイントのベース URL に置き換えます。これは、リポジトリが www.github.com でホストされていない場合にのみ必要です。それ以外の場合は、引数を省略できます。デフォルトは https://api.github.com/ です。

   アプリケーション ID の使用

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • APPLICATION_ID は、GitHub アプリのアプリケーション ID に置き換えます。
   • INSTALLATION_ID は、GitHub アプリのインストール ID に置き換えます。
   • /path/to/GITHUB_PRIVATE_KEY は、秘密鍵を含むファイルの名前に置き換えます。
   • BASE_URL は、GitHub API エンドポイントのベース URL に置き換えます。これは、リポジトリが www.github.com でホストされていない場合にのみ必要です。それ以外の場合は、引数を省略できます。デフォルトは https://api.github.com/ です。

3. ローカル ディスクから秘密鍵を削除するか、秘密鍵を保護します。

4. Config Sync を構成して Git リポジトリの URL を追加する場合は、認証タイプに githubapp を使用します。

Kubernetes サービス アカウント

OCI イメージを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE または フリートの Workload Identity Federation for GKE を使用する場合は、バージョン 1.17.2 以降で認証タイプとして k8sserviceaccount を使用できます。このオプションは、構成プロセスが簡素化されているため、gcpserviceaccount よりも推奨されます。

1. Workload Identity Federation for GKE プールを使用して、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを Kubernetes サービス アカウントに付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

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

   • PROJECT_ID: 組織のプロジェクト ID。
   • FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
   • KSA_NAME: Reconciler の Kubernetes サービス アカウント。
     • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールする場合、root-sync という名前の RootSync オブジェクトが自動的に作成されます。
   • REPOSITORY: リポジトリの ID。
   • LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Google サービス アカウント

OCI イメージを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用する場合は、認証タイプとして gcpserviceaccount を使用できます。バージョン 1.17.2 以降では、代わりに k8sserviceaccount を使用することをおすすめします。このオプションを使用すると、Google サービス アカウントと関連する IAM ポリシー バインディングを作成する手順が不要になります。

1. サービス アカウントがない場合は、サービス アカウントを作成します。

2. Google サービス アカウントに Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID  \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. 次のコマンドを実行して、Kubernetes サービス アカウントと Google サービス アカウントの IAM ポリシー バインディングを作成します。

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

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

• PROJECT_ID: 組織のプロジェクト ID。
• FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
• GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
• KSA_NAME: Reconciler の Kubernetes サービス アカウント。
  • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールする場合、root-sync という名前の RootSync オブジェクトが自動的に作成されます。
• REPOSITORY: リポジトリの ID。
• LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Compute Engine のデフォルトのサービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタが Workload Identity Federation for GKE が無効になっている GKE である場合は、認証タイプとして gcenode を使用できます。Config Sync は Compute Engine のデフォルトのサービス アカウントを使用します。Compute Engine のデフォルト サービス アカウントには、Artifact Registry への読み取りアクセス権を付与する必要があります。

1. 次のコマンドを実行して、Compute Engine サービス アカウントに Artifact Registry への読み取り権限を付与します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/artifactregistry.reader
   

   PROJECT_ID は組織のプロジェクト ID に置き換え、PROJECT_NUMBER は組織のプロジェクト番号に置き換えます。

トークン

Helm リポジトリのユーザー名とパスワードを使用して Secret を作成します。

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

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

• SECRET_NAME: Secret に付ける名前。
• USERNAME: Helm リポジトリのユーザー名。
• PASSWORD: Helm リポジトリのパスワード。

ConfigManagement Operator を構成する場合は、spec.helm.secretRef.name に選択した Secret 名を使用します。

Kubernetes サービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用する場合、バージョン 1.17.2 以降で k8sserviceaccount を認証タイプとして使用できます。このオプションは、構成プロセスが簡素化されているため、gcpserviceaccount よりも推奨されます。

1. Workload Identity Federation for GKE プールを使用して、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを Kubernetes サービス アカウントに付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

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

   • PROJECT_ID: 組織のプロジェクト ID。
   • FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
   • KSA_NAME: Reconciler の Kubernetes サービス アカウント。
     • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。
   • REPOSITORY: リポジトリの ID。
   • LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Google サービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタで GKE の Workload Identity Federation for GKE またはフリートの Workload Identity Federation for GKE を使用する場合は、認証タイプとして gcpserviceaccount を使用できます。バージョン 1.17.2 以降では、代わりに k8sserviceaccount を使用することをおすすめします。このオプションを使用すると、Google サービス アカウントと関連する IAM ポリシー バインディングを作成する手順が不要になります。

1. サービス アカウントがない場合は、サービス アカウントを作成します。

2. Google サービス アカウントに Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。Artifact Registry のロールと権限の詳細については、Artifact Registry のロールと権限の構成をご覧ください。

   • 同じ権限がプロジェクト内のすべてのリポジトリに適用される場合は、プロジェクト全体の権限を付与します。

     gcloud projects add-iam-policy-binding PROJECT_ID  \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • サービス アカウントに、プロジェクト内のリポジトリごとに異なるレベルのアクセス権を付与する場合は、リポジトリ固有の権限を付与します。

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. 次のコマンドを実行して、Kubernetes サービス アカウントと Google サービス アカウントの IAM ポリシー バインディングを作成します。

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
       --project=PROJECT_ID
   

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

• PROJECT_ID: 組織のプロジェクト ID。
• FLEET_HOST_PROJECT_ID: GKE の Workload Identity Federation for GKE を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity Federation for GKE を使用している場合は、クラスタが登録されているフリートのプロジェクト ID です。
• GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
• KSA_NAME: Reconciler の Kubernetes サービス アカウント。
  • ルート リポジトリで、RootSync の名前が root-sync の場合、root-reconciler を使用します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を使用します。
• REPOSITORY: リポジトリの ID。
• LOCATION: リポジトリのリージョンまたはマルチリージョン ロケーション。

Compute Engine のデフォルトのサービス アカウント

Helm チャートを Artifact Registry に保存し、クラスタが Workload Identity Federation for GKE が無効になっている GKE である場合は、認証タイプとして gcenode を使用できます。Config Sync は Compute Engine のデフォルトのサービス アカウントを使用します。Compute Engine のデフォルト サービス アカウントには、Artifact Registry への読み取りアクセス権を付与する必要があります。イメージを pull するための読み取り専用アクセス権を付与するには、storage-ro アクセス スコープを付与することが必要な場合があります。

1. Compute Engine サービス アカウントに Artifact Registry への読み取り権限を付与します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
       --role=roles/artifactregistry.reader
   

   PROJECT_ID は組織のプロジェクト ID に置き換え、PROJECT_NUMBER は組織のプロジェクト番号に置き換えます。

コンソール

Config Sync をインストールする

Config Sync をインストールするには、すべてのクラスタをフリートに登録する必要があります。Google Cloud コンソールで Config Sync をインストールするときに、個々のクラスタを選択すると、それらのクラスタがフリートに自動的に登録されます。

1. Google Cloud コンソールで、[機能] セクションの [構成] ページに移動します。

   [構成] に移動

2. [add Config Sync のインストール] をクリックします。
3. [自動アップグレード]（プレビュー）を選択して、Config Sync がバージョンを自動的にアップグレードできるようにするか、[手動アップグレード] を選択して Config Sync のバージョンを管理します。自動アップグレードの仕組みについて詳しくは、Config Sync をアップグレードするをご覧ください。
4. [インストール オプション] で、次のいずれかのオプションを選択します。
   • Install Config Sync on entire fleet（推奨）: フリート内のすべてのクラスタに Config Sync がインストールされます。
   • Install Config Sync on individual clusters: 選択したすべてのクラスタがフリートに自動的に登録されます。Config Sync はフリート内のすべてのクラスタにインストールされます。
5. 個々のクラスタに Config Sync をインストールする場合は、使用可能なクラスタ テーブルで、Config Sync をインストールするクラスタを選択します。
6. [Config Sync のインストール] をクリックします。数分後、[設定] タブで、フリート内のクラスタの [ステータス] 列が「有効」になっていることを確認します。

パッケージをデプロイする

クラスタをフリートに登録し、Config Sync をインストールしたら、信頼できる情報源からクラスタにパッケージをデプロイするように Config Sync を構成できます。同じパッケージを複数のクラスタにデプロイする、または異なるパッケージを異なるクラスタにデプロイできます。パッケージ名や同期タイプなどの設定を除き、パッケージはデプロイ後に編集できます。詳細については、パッケージを管理するをご覧ください。

パッケージをデプロイする手順は次のとおりです。

1. Google Cloud コンソールで Config Sync のダッシュボードに移動します。

   Config Sync のダッシュボードに移動

2. [パッケージをデプロイ] をクリックします。

3. [Select clusters for package deployment] テーブルで、パッケージをデプロイするクラスタを選択し、[続行] をクリックします。

4. ソースタイプとして [Package hosted on Git] または [Package hosted on OCI] を選択し、[続行] をクリックします。

5. [Package details] セクションで、パッケージ名を入力します。この名前は RootSync オブジェクトまたは RepoSync オブジェクトを表します。

6. [同期タイプ] フィールドで、同期タイプとして [クラスタ スコープの同期] または [Namespace スコープの同期] を選択します。

   クラスタ スコープの同期では RootSync オブジェクトが作成され、Namespace スコープの同期では RepoSync オブジェクトが作成されます。これらのオブジェクトの詳細については、Config Sync のアーキテクチャをご覧ください。

7. [ソース] セクションで、次の操作を行います。

   • Git リポジトリでホストされているソースの場合は、次のフィールドを入力します。

     1. [リポジトリの URL] に、信頼できる情報源として使用する Git リポジトリの URL を入力します。
     2. 省略可: [リビジョン] フィールドを更新して、デフォルトの HEAD を使用していないかどうかを確認します。
     3. 省略可: ルート リポジトリから同期しない場合は、[パス] フィールドを更新します。
     4. 省略可: デフォルトの main ブランチを使用していない場合は、[ブランチ] フィールドを更新します。

   • OCI イメージでホストされているソースの場合は、次のフィールドを入力します。

     1. [イメージ] に、信頼できる情報源として使用する OCI イメージの URL を入力します。
     2. [ディレクトリ] に、同期元となるディレクトリのパスをルート ディレクトリからの相対パスとして入力します。

8. （省略可）: [詳細設定] セクションを開いて、次の操作を行います。

   1. 認証タイプを選択します。Config Sync がソースの構成ファイルを読み取り、クラスタに適用するには、信頼できる情報源に対する読み取り専用アクセス権が必要です。ソースに公開リポジトリなどの認証が不要な場合を除き、Config Sync に、Git リポジトリ、OCI イメージ、または Helm チャート（gcloud CLI のみ）に対する読み取り専用アクセス権を付与してください。Config Sync のインストール時に構成したのと同じ認証タイプを選択します。

      • なし: 認証を使用しない
      • SSH: SSH 認証鍵ペアを使用して認証を行います。
      • Cookiefile: cookiefile を使用して認証します。
      • トークン: アクセス トークンまたはパスワードを使用して認証します。
      • Google Cloud Repository: Google サービス アカウントを使用して Cloud Source Repositories にアクセスします。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
      • Workload Identity: Google サービス アカウントを使用して、Cloud Source Repositories のリポジトリにアクセスします。

   2. 同期の待機時間を秒単位で入力します。これにより、Config Sync が信頼できる情報源から pull を試みてから再度試行するまでの待機時間が決定されます。

   3. 信頼できる情報源との通信時に使用する HTTPS プロキシの Git プロキシ URL を入力します。

   4. [階層] を選択して [ソース形式] を変更します。

      ほとんどの場合は、デフォルト値の「Unstructured」をおすすめします。これにより、信頼できる情報源を必要に応じて整理できます。

9. [パッケージをデプロイ] をクリックします。

   Config Sync の [パッケージ] ページにリダイレクトされます。数分後、構成したクラスタの [同期ステータス] 列に「同期済み」と表示されます。

gcloud

続行する前に、クラスタをフリートに登録していることを確認してください。

1. ConfigManagement フリート機能を有効にします。

   gcloud beta container fleet config-management enable
   

2. 新しい apply-spec.yaml マニフェストを作成するか、既存のマニフェストを使用して、構成を準備します。既存のマニフェストを使用すると、別のクラスタで使用されているものと同じ設定でクラスタを構成できます。

   新しいマニフェストを作成する

   クラスタ用の新しい設定で Config Sync を構成するには、apply-spec.yaml という名前のファイルを作成して次の YAML ファイルをコピーします。

   マニフェストを作成するときに、必要な spec.configSync オプション フィールドをすべて設定して、後で kubectl コマンドを使用して構成を行うことができます。また、spec.configSync.enabled フィールドを true に設定して、オプション フィールドを省略することもできます。後で kubectl コマンドを使用して追加の RootSync オブジェクトを作成できます。また、後で kubectl コマンドで完全に管理できる RepoSync を作成することもできます。

   # apply-spec.yaml
   
   applySpecVersion: 1
   spec:
     # upgrades: UPGRADE_SETTING
     configSync:
       # Set to true to install and enable Config Sync
       enabled: true
       # If you don't have a source of truth yet, omit the
       # following fields. You can configure them later.
       sourceType: SOURCE_TYPE
       sourceFormat: FORMAT
       syncRepo: REPO
       syncRev: REVISION
       syncBranch: BRANCH
       secretType: SECRET_TYPE
       gcpServiceAccountEmail: EMAIL
       metricsGcpServiceAccountEmail: METRICS_EMAIL
       policyDir: DIRECTORY
       preventDrift: PREVENT_DRIFT
   

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

   • （プレビュー）UPGRADE_SETTING: Config Sync が自動的にアップグレードされるように構成するには、フィールドのコメントを解除して auto に設定します。Config Sync を手動でアップグレードするには、manual に設定します。デフォルト値は manual です。このフラグは、GKE on Google Cloud クラスタでのみサポートされています。このフィールドを使用するには、gcloud components update を実行して gcloud CLI の更新が必要になる場合があります。

   • SOURCE_TYPE: Git リポジトリから同期する場合は git、OCI イメージから同期する場合は oci、Helm チャートから同期する場合は helm を追加します。値を指定しない場合、デフォルトの git が使用されます。

   • FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では、自分が一番使いやすい方法で構成ファイルを整理できます。

   • REPO: 信頼できる情報源の URL を追加します。Git リポジトリと Helm リポジトリの URL は、HTTPS または SSH プロトコルを使用します。例: https://github.com/GoogleCloudPlatform/anthos-config-management-samplessecretType として SSH を使用する場合は、SSH プロトコルを使用して URL を入力します。このフィールドは必須です。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。

     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

   • REVISION: 同期元となる Git リビジョン（タグまたはハッシュ）。このフィールドは省略可能で、デフォルト値は HEAD です。Config Sync バージョン 1.17.0 以降では、syncRev フィールドにブランチ名を指定することもできます。バージョン 1.17.0 以降のハッシュを使用する場合、省略形ではなく、完全なハッシュにする必要があります。

   • BRANCH: 同期元となるリポジトリのブランチ。このフィールドは省略可能です。デフォルトは master です。Config Sync バージョン 1.17.0 以降では、わかりやすくするため、syncRev フィールドを使用してブランチ名を指定することをおすすめします。syncRev フィールドと syncBranch フィールドの両方が指定されている場合、syncRev が syncBranch よりも優先されます。

   • SECRET_TYPE: 以下の secretTypes のいずれかです。

     git

     • none: 認証なし。
     • ssh: SSH 認証鍵ペアを使用。
     • cookiefile: cookiefile を使用。
     • token: トークンを使用。
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。この認証タイプを選択した場合は、Config Sync の構成を完了した後に IAM ポリシー バインディングを作成する必要があります。詳しくは、Config Sync に Git の読み取り専用アクセス権を付与するセクションの 「Google サービス アカウント」タブをご覧ください。
     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。
     • githubapp: GitHub アプリを使用して GitHub リポジトリの認証を行う。

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

     oci

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

     helm

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

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

   • METRICS_EMAIL: Config Sync の指標を Cloud Monitoring にエクスポートする際に使用される Google Cloud サービス アカウント（GSA）のメールアドレス。GSA には、モニタリング指標の書き込み（roles/monitoring.metricWriter）IAM ロールが必要です。Namespace config-management-monitoring の Kubernetes ServiceAccount default は、GSA にバインドされている必要があります。

   • DIRECTORY: 同期元となるディレクトリのパスであり、Git リポジトリのルートからの相対パス。指定したディレクトリのすべてのサブディレクトリがクラスタと同期されます。デフォルト値は、リポジトリのルート ディレクトリです。

   • PREVENT_DRIFT: true に設定されている場合、Config Sync アドミッション Webhook を有効にして、競合変更がライブクラスタに push されないように拒否することにより、ブレを防止します。デフォルトの設定は false です。Config Sync は、このフィールドの値に関係なく、常にブレを修正します。

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

   既存のマニフェストを使用する

   別のクラスタで使用されている同じ設定でクラスタを構成するには、登録済みクラスタから設定を取得します。

   gcloud alpha container fleet config-management fetch-for-apply \
       --membership=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       > CONFIG_YAML_PATH
   

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

   • MEMBERSHIP_NAME: 使用する Config Sync 設定になっている登録済みクラスタのメンバーシップ名
   • PROJECT_ID: プロジェクト ID
   • CONFIG_YAML_PATH: クラスタから取得した設定を含む apply-spec.yaml ファイルのパス

3. apply-spec.yaml ファイルを適用します。既存のマニフェストを使用している場合は、前のコマンドで取得した設定を使用して、構成するクラスタにファイルを適用する必要があります。

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=CONFIG_YAML_PATH \
       --project=PROJECT_ID
   

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

   • MEMBERSHIP_NAME: クラスタの登録時に選択したフリート メンバーシップ名。名前は gcloud container fleet memberships list で確認できます。
   • CONFIG_YAML_PATH: apply-spec.yaml ファイルのパス。
   • PROJECT_ID: プロジェクト ID。

Terraform

Config Sync を構成するクラスタごとに、configmanagement ブロックと config_sync ブロックを含む google_gkehub_feature_membership リソース ブロックを適用します。

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

同期するクラスタごとに、この手順を繰り返します。

gcloud

機能の enable コマンドを実行し、個々のクラスタで Config Sync を構成したときに作成した apply-spec.yaml 構成ファイルを渡します。

gcloud beta container fleet config-management enable \
    --fleet-default-member-config=apply-spec.yaml

このコマンドを使用すると、フリートのデフォルト設定をいつでも更新できます。フリートのデフォルト設定を更新する場合は、既存のクラスタをデフォルト設定に再同期する必要があります。

コンソール

1. Google Cloud コンソールで、[機能マネージャー] ページに移動します。

   機能マネージャーに移動

2. [Config Sync] ペインで、[構成] をクリックします。

3. フリートレベルの設定を確認します。フリートで作成した新しいクラスタは、これらの設定を継承します。

4. 省略可: デフォルトの設定を変更するには、[フリートの設定をカスタマイズ] をクリックします。表示されるダイアログで、次の操作を行います。

5. Config Sync のバージョンを自動的にアップグレードするには、[自動アップグレード]（プレビュー）を選択します。または、Config Sync のバージョンを管理するには、[手動アップグレード] を選択します。自動アップグレードの仕組みについて詳しくは、Config Sync をアップグレードするをご覧ください。

6. [手動アップグレード] を選択した場合は、[バージョン] リストで、使用する Config Sync のバージョンを選択します。

7. [保存] をクリックします。

8. [構成] をクリックします。

9. [フリートの設定を構成] 確認ダイアログで、[確認] をクリックします。以前に Config Sync を有効にしていない場合は、[確認] をクリックして anthosconfigmanagement.googleapis.com API を有効にします。

Terraform

1. フリートのデフォルト構成の Terraform ファイル用にディレクトリを作成します。このディレクトリに、Config Sync の設定を行う次のリソースを含む main.tf ファイルを追加します。

   git

   terraform {
     required_providers {
       google = {
         source = "hashicorp/google"
         version = ">=5.16.0"
         }
       }
     }
   
   provider "google" {
     project = "PROJECT_ID"
   }
   
   resource "google_gke_hub_feature" "feature" {
     name = "configmanagement"
     location = "global"
     provider = google
     fleet_default_member_config {
       configmanagement {
       version = "VERSION"
       config_sync {
       source_format = "unstructured"
         git {
           sync_repo = "REPO"
           sync_branch = "BRANCH"
           policy_dir = "DIRECTORY"
           secret_type = "SECRET"
         }
       }
       }
     }
   }
   

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

   • PROJECT_ID: フリート ホスト プロジェクト ID。
   • VERSION: （省略可）Config Sync のバージョン番号。空白のままにすると、デフォルトで最新バージョンが使用されます。
   • REPO: 構成ファイルを含むリポジトリの URL。
   • BRANCH: リポジトリ ブランチ。例: main
   • DIRECTORY: 同期するリポジトリの最上位レベルを表す Git リポジトリ内のパス。
   • SECRET: Secret 認証タイプ。

   Config Sync の git ブロックでサポートされている設定の一覧については、GKE Hub 機能の Terraform リファレンス ドキュメントをご覧ください。

   OCI

   terraform {
     required_providers {
       google = {
         source = "hashicorp/google"
         version = ">=5.16.0"
         }
       }
     }
   
   provider "google" {
     project = "PROJECT_ID"
   }
   
   resource "google_gke_hub_feature" "feature" {
     name = "configmanagement"
     location = "global"
     provider = google
     fleet_default_member_config {
       configmanagement {
       version = "VERSION"
       config_sync {
       source_format = "unstructured"
         oci {
           sync_repo = "REPO"
           policy_dir = "DIRECTORY"
           secret_type = "SECRET"
         }
       }
       }
     }
   }
   

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

   • PROJECT_ID: フリート ホスト プロジェクト ID。
   • VERSION: Config Sync のバージョン番号。バージョン 1.17.0 以降に設定する必要があります。空白のままにすると、デフォルトで最新バージョンが使用されます。
   • REPO: 構成ファイルを含む OCI イメージ リポジトリの URL。
   • DIRECTORY: 同期するリソースを含むディレクトリの絶対パス。ルート ディレクトリを使用する場合は空白のままにします。
   • SECRET: Secret 認証タイプ。

   Config Sync の oci ブロックでサポートされている設定の一覧については、GKE Hub 機能の Terraform リファレンス ドキュメントをご覧ください。

2. 作成したディレクトリで Terraform を初期化します。

   terraform init
   

3. Terraform で示した変更が、想定されているプランと一致していることを確認します。

   terraform plan
   

4. フリート メンバーのデフォルト構成を作成します。

   terraform apply
   

gcloud

1. 既存のメンバーシップをフリートのデフォルト構成に同期します。

   gcloud beta container fleet config-management apply \
       --origin=FLEET \
       --membership=MEMBERSHIP_NAME
   

   MEMBERSHIP_NAME は、フリートのデフォルト構成と同期するクラスタのメンバーシップ名に置き換えます。

2. メンバーシップの構成がフリートのデフォルトと同期されていることを確認します。

   gcloud beta container fleet config-management status
   

   このコマンドの出力には、同期したメンバーシップの Synced_to_Fleet_Default ステータスが Yes と表示されます。

コンソール

1. 機能マネージャーに移動します。

   [機能マネージャー: Config Sync] に移動

2. クラスタの表で、フリートの設定に同期するクラスタを選択します。

3. [フリートの設定に同期] をクリックします。

コンソール

次の操作を行います。

1. Google Cloud コンソールで、[機能] セクションの [構成] ページに移動します。

   [構成] に移動

2. [パッケージ] タブで、クラスタ テーブルの [同期ステータス] 列を確認します。Config Sync が正常にインストールされると、ステータスは「インストール済み」になります。正常に構成されている信頼できる情報源のステータスは「同期済み」になります。

gcloud

次のコマンドを実行します。

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

PROJECT_ID はプロジェクトの ID に置き換えます。

インストールに成功すると、ステータスは SYNCED になります。Config Sync のバージョン 1.18.0 以降では、インストールされている Config Sync のバージョンと Config Sync のアップグレード設定も出力に表示されます。

上のコマンドを実行した後にエラーが表示された場合は、git-creds Secret が作成されていることを確認してください。Secret が作成されている場合は、次のコマンドをもう一度実行してみてください。

gcloud beta container fleet config-management apply

1.18

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

1.17

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

1.16

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

1.18

1.17

1.16

1.18

1.17

1.16

1.17.0 より前のバージョンの Config Sync では、Standard と Autopilot のリソース リクエストは同じです。