Config Sync のインストール

Config Sync では、信頼できる情報源に保存された構成ファイルを使用して、Kubernetes リソースを管理できます。Config Sync は、信頼できる情報源として Git リポジトリ、OCI イメージ、Helm チャートをサポートしています。このページでは、Config Sync を有効にして、ルート リポジトリから同期するように構成する方法について説明します。Config Sync は、Google Kubernetes Engine（GKE）Enterprise エディションで利用できます。

Google Cloud コンソールまたは Google Cloud CLI で Config Sync をインストールすると、デフォルトで RootSync API と RepoSync API が有効になります。これにより、複数のリポジトリからの同期や、Kustomize と Helm の構成の同期などの追加機能を実行できます。

始める前に

Config Sync をインストールする前に、環境を準備し、クラスタの要件を満たしていることを確認して、適切なユーザーロールを付与します。

ローカルの環境を準備する

次のタスクを行ってローカル環境を準備します。

  1. 信頼できる情報源を作成するか、信頼できる情報源にアクセスできることを確認します。ここに、Config Sync が同期する構成ファイルを追加します。構成ファイルと信頼できる情報源の設定方法については、次のいずれかのガイドをご覧ください。
  2. Google Cloud CLI をインストールして初期化します。これにより、gcloud コマンドと nomos コマンドが提供されます。Cloud Shell を使用する場合、Google Cloud CLI がプリインストールされています。すでに Google Cloud CLI をインストールしている場合は、gcloud components update を実行して最新バージョンを取得します。

  3. GKE Enterprise API を有効にします。

    GKE Enterprise API を有効にする

クラスタ要件

Config Sync を使用するには、クラスタが次の要件を満たしている必要があります。

  • Google Kubernetes Engine（GKE）Enterprise エディションのサポート対象プラットフォームとバージョンである必要があります。

  • （省略可）GKE クラスタを使用する場合は、Workload Identity が有効になっていることを確認します。Autopilot クラスタでは、Workload Identity がデフォルトで有効になっています。

  • Config Sync が Cloud Monitoring に指標を送信できるように、指標の正しい書き込み権限が付与されている必要があります。

  • Config Sync バージョンを自動アップグレードする場合は、GKE クラスタがリリース チャンネルに登録されていることを確認してください。Config Sync では、GKE リリース チャンネルを使用していないクラスタは Stable リリース チャンネルを使用していると見なされます。

  • 限定公開 GKE クラスタを使用する場合は、プライベート GKE ノードからの下り（外向き）トラフィックが許可されるように Cloud NAT を構成します。詳細については、GKE の設定例をご覧ください。限定公開の Google アクセスを有効にして、Google API とサービスで使用する一連の外部 IP アドレスに接続することもできます。

  • Config Sync に信頼できる情報源へのアクセス権を付与する際に IAM サービス アカウントを使用する場合は、Cloud Source Repositories のクラスタ内にあるノードのアクセス スコープに、読み取り専用スコープを含める必要があります。

    読み取り専用スコープは、クラスタ作成時に指定された --scopes リストに cloud-source-repos-ro を組み込むか、クラスタの作成時に cloud-platform スコープを使用することで追加できます。例:

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

    アクセス スコープは、ノードプールの作成後は変更できません。ただし、同じクラスタを使用しながら、適切なアクセス スコープを持つ新しいノードプールを作成できます。デフォルトの gke-default スコープに cloud-source-repos-ro は含まれません。

  • 不要なトラフィックをブロックする厳密な VPC ファイアウォール要件がある場合は、ファイアウォール ルールを作成して、一般公開 GKE クラスタで次のトラフィックを許可する必要があります。

    • TCP: ポート 53 と 443 で上り（内向き）と下り（外向き）を許可する

    • UDP: ポート 53 で下り（外向き）を許可する

    これらのルールを含めない場合、Config Sync が正しく同期されず、nomos status が次のエラーを報告します。

    Error: KNV2004: unable to sync repo Error in the git-sync container

    限定公開 GKE クラスタを使用している場合は、この手順をスキップできます。

  • Config Sync は amd64 ノードプールで実行する必要があります。Config Sync バックエンド コンポーネントのコンテナ イメージは、amd64 マシン アーキテクチャに対してのみ構築、配布、テストされます。Config Sync コンポーネントが Arm ノードでスケジュールされると、exec format エラーが発生してクラッシュします。

    クラスタに Arm ノードがある場合は、1 つ以上の amd64 ノードをクラスタに追加します。GKE クラスタを使用していない場合は、特定の toleration のない arm64 ノードに Pod をスケジュールしないよう、arm64 ノードに taint を追加します。GKE Arm ノードにはすでにデフォルトの taint が存在するため、追加する必要はありません。

クラスタが Autopilot クラスタの場合、Autopilot はコンテナ リソースの要件を次のルールに合わせて調整します。

これらのルールにより、Autopilot クラスタでは Config Sync によって次の処理が行われます。

クラスタを準備する

適切なクラスタを作成したら、次の操作を行います。

  1. クラスタを登録するユーザーに必要な IAM ロールを付与します。

  2. Google Cloud CLI を使用して Config Sync を構成する場合、または Google Cloud 外のクラスタを使用する場合は、GKE クラスタまたは Google Cloud 外のクラスタがフリートに登録されている必要があります。Google Cloud コンソールを使用する場合は、Config Sync の構成時に GKE クラスタを登録できます。

Config Sync をインストールする

以下のセクションでは、Config Sync に次のいずれかの信頼できる情報源へのアクセス権を付与します。

アクセス権を付与すると、Config Sync を構成できます。

Git へのアクセス権を付与する

Config Sync には、Git リポジトリに対する読み取り専用権限が必要です。この権限により、Config Sync はリポジトリに commit された構成ファイルを読み取り、クラスタに適用できるようになります。

読み取り専用アクセスに対してリポジトリによる認証が不要な場合は、引き続き Config Sync を構成し、認証タイプとして none を使用できます。たとえば、ログインせずにウェブ インターフェースでリポジトリを参照できる場合は認証の必要はありません。また、認証情報を指定することや、保存済みの認証情報を使用することなく、git clone を使用してリポジトリのクローンをローカルに作成できる場合も認証は不要です。この場合、Secret を作成する必要はありません。

ただし、ほとんどのユーザーは、リポジトリへの読み取りアクセスが制限されているため、認証情報を作成する必要があります。認証情報が必要な場合は、登録された各クラスタの git-creds Secret に認証情報が保存されています（Google サービス アカウントを使用している場合を除く）。Secret は固定値であるため、git-creds という名前にする必要があります。

Config Sync は、次の認証メカニズムをサポートしています。

  • SSH 認証鍵ペア（ssh）
  • Cookiefile（cookiefile）
  • トークン（token）
  • Google サービス アカウント（gcpserviceaccount）
  • Compute Engine のデフォルトのサービス アカウント（gcenode）

どちらの方法を選択するかは、リポジトリがサポートする対象によって異なります。通常は、SSH 認証鍵ペアを使用することをおすすめします。GitHub と Bitbucket はどちらも SSH 認証鍵ペアの使用をサポートしています。ただし、Cloud Source Repositories のリポジトリを使用している場合は、プロセスがよりシンプルであるため、Google サービス アカウントの使用をおすすめします。組織でリポジトリをホストしていて、どの認証方法がサポートされているかがわからない場合は、管理者にお問い合わせください。

Cloud Source Repositories のリポジトリを Config Sync リポジトリとして使用するには、次の手順で Cloud Source Repositories の URL を取得します。

  1. リポジトリのリストを取得します。

    gcloud source repos list

  2. 使用するリポジトリの URL を出力からコピーします。例:

    REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr

    この URL は、次のセクションで Config Sync を構成するときに必要になります。Google Cloud コンソールを使用して Config Sync を構成する場合は、URL を [URL] フィールドに追加します。Google Cloud CLI を使用して Config Sync を構成する場合は、構成ファイルの syncRepo フィールドに URL を追加します。

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 ホスティング プロバイダの手順へのリンクを以下に示します。

  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 シークレットの data.known_hosts フィールドに既知のホストキーを追加します。known_hosts のチェックを無効にするには、シークレットから 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 を使用してトークンを作成します。

  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 またはフリートの Workload Identity を使用している場合、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] を選択し、サービス アカウントのメールアドレスを追加します。

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

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

    フリートに登録されたクラスタを使用している場合は、フリートごとに 1 回だけポリシー バインディングを作成する必要があります。フリートに登録されたすべてのクラスタは、同じ Workload Identity プールを共有します。フリートのコンセプトである同一性により、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 を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity を使用している場合は、クラスタが登録されているフリートのプロジェクト 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 が無効になっている 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 は組織のプロジェクト番号に置き換えます。

Config Sync に OCI の読み取り専用アクセス権を付与する

イメージに含まれている構成ファイルを読み取り、クラスタに適用できるように、Artifact Registry に保存されている OCI イメージへの読み取り専用権限を Config Sync に付与する必要があります。

イメージに読み取り専用アクセスの認証が不要な場合は、引き続き Config Sync を構成し、認証タイプとして none を使用します。たとえば、イメージが公開されていて、インターネットで誰でもアクセスできる場合、認証は不要です。

ただし、ほとんどのユーザーは、制限付きイメージにアクセスするために、認証情報を作成する必要があります。Config Sync は、次の認証メカニズムをサポートしています。

  • Kubernetes サービス アカウント（k8sserviceaccount）
  • Google サービス アカウント（gcpserviceaccount）

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

Kubernetes サービス アカウント

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

  1. Workload Identity プールを使用して、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 を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity を使用している場合は、クラスタが登録されているフリートのプロジェクト 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 ワークロード ID またはフリートの Workload Identity を使用する場合、認証タイプとして 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 を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity を使用している場合は、クラスタが登録されているフリートのプロジェクト 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 が無効になっている 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 は組織のプロジェクト番号に置き換えます。

Config Sync に Helm の読み取り専用アクセス権を付与する

Config Sync には、Helm リポジトリに対する読み取り専用権限が必要です。この権限により、Config Sync はリポジトリ内の Helm チャートを読み取り、クラスタ内にインストールできるようになります。

読み取り専用アクセスに対してリポジトリによる認証が不要な場合は、引き続き Config Sync を構成し、認証タイプとして none を使用できます。たとえば、Helm リポジトリが一般公開されていて、インターネットで誰でもアクセスできる場合は、認証する必要はありません。

ただし、ほとんどのユーザーは公開 Helm リボジトリにアクセスするために、認証情報を作成する必要があります。Config Sync は、次の認証メカニズムをサポートしています。

  • トークン（token）
  • Kubernetes サービス アカウント（k8sserviceaccount）
  • Google サービス アカウント（gcpserviceaccount）
  • Compute Engine のデフォルトのサービス アカウント（gcenode）

トークン

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 ワークロード ID またはフリートの Workload Identity を使用する場合、バージョン 1.17.2 以降では k8sserviceaccount を認証タイプとして使用できます。このオプションは、構成プロセスが簡素化されているため、gcpserviceaccount よりも推奨されます。

  1. Workload Identity プールを使用して、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 を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity を使用している場合は、クラスタが登録されているフリートのプロジェクト 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 またはフリートの Workload Identity を使用する場合、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 を使用している場合は、PROJECT_ID と同じです。フリートの Workload Identity を使用している場合は、クラスタが登録されているフリートのプロジェクト 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 が無効になっている 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 を構成する

このセクションでは、ルート リポジトリの構成を行います。Git リポジトリと同期している場合は、Google Cloud コンソールを使用してインストール プロセスを行い、一部の手順を自動化できます。

Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールすると、root-sync という RootSync オブジェクトが自動的に作成されます。kubectl コマンドを使用して root-sync を変更し、Config Sync の構成を追加できます。詳細については、kubectl コマンドを使用して Config Sync を構成するをご覧ください。

コンソール

Config Sync をインストールする

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

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

    [構成] に移動

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

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

      oci

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

      helm

      • token: トークンを使用します。
      • gcenode: Compute Engine のデフォルト サービス アカウントを使用して、Artifact Registry のイメージにアクセスします。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ選択してください。
      • 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 リソース ブロックを適用します。

git

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 {
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

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

  • EXISTING_CLUSTER_NAME: 既存のクラスタの名前。
  • EXISTING_CLUSTER_LOCATION: 既存のクラスタのロケーション。
  • MEMBERSHIP_ID: メンバーシップ バインディング ID。
  • VERSION: （省略可）Config Sync のバージョン番号。バージョン 1.17.0 以降に設定する必要があります。空白のままにすると、デフォルトで最新バージョンが使用されます。
  • REPO: 構成ファイルを含むリポジトリの URL。
  • BRANCH: リポジトリ ブランチ。例: main
  • DIRECTORY: 同期するリポジトリの最上位レベルを表す Git リポジトリ内のパス。
  • SECRET: Secret 認証タイプ。

oci

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 {
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

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

  • EXISTING_CLUSTER_NAME: 既存のクラスタの名前。
  • EXISTING_CLUSTER_LOCATION: 既存のクラスタのロケーション。
  • MEMBERSHIP_ID: メンバーシップ バインディング ID。
  • VERSION: （省略可）Config Sync のバージョン番号。空白のままにすると、デフォルトで最新バージョンが使用されます。
  • REPO: 構成ファイルを含む OCI イメージ リポジトリの URL。
  • DIRECTORY: 同期するリソースを含むディレクトリの絶対パス。ルート ディレクトリを使用する場合は空白のままにします。
  • SECRET: Secret 認証タイプ。

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

ルート リポジトリの構成が完了したら、必要に応じて、他のルート リポジトリや Namespace リポジトリなど、複数のリポジトリからの同期を構成することもできます。Namespace リポジトリは、クラスタ全体で特定の Namespace に同期される Namespace スコープの構成ファイルを 1 つのリポジトリに保存する場合に役立ちます。

フリートレベルのデフォルトを構成する

Google Kubernetes Engine（GKE）Enterprise エディションを有効にしている場合は、Config Sync を有効にして、クラスタのフリートレベルのデフォルトとして構成できます。つまり、フリートで作成された Google Cloud クラスタ上の新しい GKE では、指定した設定のクラスタで Config Sync が有効になります。フリートのデフォルト構成の詳細については、フリートレベルの機能を管理するをご覧ください。

Google Cloud コンソールのみを使用する場合は、クラスタで Config Sync をデフォルトで有効にし、フリートの Config Sync バージョンを設定できます。Terraform を使用する場合は、クラスタで Config Sync をデフォルトで有効にし、フリートの Config Sync バージョンを設定して、Git リポジトリまたは OCI イメージ リポジトリへの接続を設定できます。

Config Sync のフリートレベルのデフォルトを構成する手順は次のとおりです。

コンソール

  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

既存のクラスタを更新してデフォルトの Config Sync 設定を使用する場合は、Google Cloud コンソールを使用して、選択したフリート クラスタをフリートのデフォルトに同期します。または、Config Sync の構成の手順に沿って、Terraform または gcloud CLI を使用して同じ設定で各クラスタを手動で構成することもできます。以前に Terraform を使用してフリートのデフォルトを指定した場合は、デフォルトの設定に使用したものと同じ configmanagement と config_sync ブロックを使用して、選択したクラスタを構成します。

Config Sync のデフォルト設定をフリート全体で同期する手順は次のとおりです。

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

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

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

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

選択したクラスタには、Config Sync のデフォルト設定が適用されます。Google Cloud コンソールに表示される設定は、Config Sync バージョンのように設定のサブセットのみですが、すべてのフリートレベルの設定がクラスタに同期されます。たとえば、Terraform を使用して Git リポジトリに同期するように Config Sync を構成した場合、その設定はクラスタに同期されますが、Google Cloud コンソールには表示されません。

インストールを確認する

Config Sync をインストールして構成したら、インストールが正常に完了したことを確認します。

コンソール

次の操作を行います。

  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

nomos status コマンドを使用して、Config Sync が正常にインストールされたかどうかを確認することもできます。問題のない有効なインストールのステータスは PENDING または SYNCED です。無効なインストール、または不完全なインストールのステータスは NOT INSTALLED または NOT CONFIGURED です。出力には、報告済みのエラーも含まれます。

ロールベース アクセス制御（RBAC）と権限

Config Sync には高い権限のワークロードが含まれています。次の表に、これらのワークロードの権限を示します。

コンポーネント Namespace サービス アカウント 権限 説明
ConfigManagement Operator config-management-system config-management-operator cluster-admin ConfigManagement Operator は、この表にある他のコンポーネントをインストールします。これらのコンポーネントの一部には cluster-admin 権限が必要なため、ConfigManagement Operator にもこれらの権限が必要です。
Config Sync config-management-system 必要な権限については、Config Sync の権限をご覧ください。

リソース リクエスト

次のセクションでは、Config Sync のリソース リクエストについて説明します。

次の表に、Config Sync コンポーネントの Kubernetes リソースの要件を示します。詳細については、Kubernetes ドキュメントのコンテナのリソース管理をご覧ください。

リストにあるコンポーネントがすべて作成されるわけではありません。次の条件により、各コンポーネントがスケジュール設定されます。

  • Config Sync を有効にすると、config-management-operator がインストールされます。
  • Config Sync を有効にすると、reconciler-manager がインストールされます。
  • ドリフト防止が有効になっている場合 admission-webhook がインストールされます。
  • RootSync と RepoSync ごとに reconciler がインストールされます。
  • Config Sync を有効にすると、otel-collector がインストールされます。

これらのコンポーネントの詳細については、Config Sync のアーキテクチャをご覧ください。

1.18

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

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

1.17

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

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

1.16

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

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

Reconciler Deployment

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

Config Sync バージョン 1.17.0 以降では、Reconciler のデフォルトのリソース リクエストが Standard クラスタと Autopilot クラスタで異なります。他のすべてのクラスタタイプは Standard のデフォルトを使用します。

Standard クラスタ

1.18

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

1.17

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

1.16

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

Autopilot クラスタ

1.18

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

1.17

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

1.16

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

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

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

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

Config Sync のバージョン Helm のバージョン Kustomize のバージョン
1.18.0 v3.14.3 v5.3.0
1.17.1、1.17.3 v3.13.3 v5.3.0
1.16.3、1.17.0 v3.13.1 v5.1.1
1.16.1、1.16.2 v3.12.3 v5.1.1
1.16.0 v3.12.2 v5.1.1
1.15.3 v3.12.2 v5.1.0
1.15.1～1.15.2 v3.11.3 v5.0.3
1.15.0 v3.11.3 v5.0.1
1.11.0～1.14.3 v3.6.3 v4.5.2

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

次のステップ