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 を有効にする

クラスタ要件

次の要件を満たすクラスタを作成するか、クラスタにアクセスします。

  • クラスタは、Google Kubernetes Engine（GKE）Enterprise エディションのサポート対象プラットフォームとバージョン上にあります。

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

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

  • （省略可）GKE クラスタを使用する場合、クラスタで Workload Identity が有効になっている。セキュリティ プロパティと管理性が向上しているため、Workload Identity を使用して、GKE 内で実行しているアプリケーションから Google Cloud サービスにアクセスすることをおすすめします。Autopilot クラスタでは、デフォルトで Workload Identity が有効になっています。

  • Config Sync が Cloud Monitoring に指標を送信できるように、正しい指標書き込み権限を付与します。これは、自動アップグレードを使用する場合に必要です。

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

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

  • Config Sync に信頼できる情報源へのアクセス権を付与する際に Google サービス アカウントを使用する場合、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 クラスタを使用していない場合は、特定の容認機能のない arm64 ノードに Pod をスケジュールしないように arm64 ノードに taint を追加します。GKE Arm ノードにはすでにデフォルトの taint が存在するため、追加する必要はありません。

クラスタの準備

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

  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 にあり、クラスタが Google Cloud 上の GKE で Workload Identity が無効になっている場合、gcenode を認証タイプとして使用できます。

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

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

Google Cloud Repository または gcenode を選択すると、Compute Engine のデフォルトのサービス アカウントを使用できます。Cloud Source Repositories 読み取り（roles/source.reader）IAM ロールを Compute Engine のデフォルト サービス アカウントに付与する必要があります。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を使用する場合、次のコマンドを使用できます。k8sserviceaccountバージョン 1.17.2 以降では認証タイプとして指定する必要があります。構成プロセスが簡素化されるため、gcpserviceaccount よりもこのオプションをおすすめします。

  1. Workload Identity プールを持つ Kubernetes サービス アカウントに、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。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 に保存し、クラスタが Google Cloud 上の GKE で Workload Identity が無効になっている場合、認証タイプとして 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 プールを持つ Kubernetes サービス アカウントに、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。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 に保存し、クラスタが Google Cloud 上の GKE で Workload Identity が無効になっている場合、認証タイプとして 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. [インストール オプション] で、次のいずれかのオプションを選択します。
    • フリート全体に Config Sync をインストールする（推奨）: Config Sync はフリート内のすべてのクラスタにインストールされます。
    • 個々のクラスタに Config Sync をインストールする: 選択したすべてのクラスタが自動的にフリートに登録されます。Config Sync はフリート内のすべてのクラスタにインストールされます。
  5. 個々のクラスタに Config Sync をインストールする場合は、使用可能なクラスタ テーブルで、Config Sync をインストールするクラスタを選択します。
  6. [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. [ソース] セクションで、次の操作を行います。

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

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

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

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

  7. [Sync type] フィールドで、同期タイプとして [RootSync] または [RepoSync] を選択します。

    RootSync オブジェクトはクラスタ スコープで、RepoSync オブジェクトは Namespace スコープです。これらのオブジェクトの詳細については、RootSync フィールドと RepoSync フィールドをご覧ください。

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

    1. 認証タイプを選択します。

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

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

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

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

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

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

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

  10. パッケージを更新するには、[パッケージ] タブで編集するパッケージ名を開き、[ 編集] をクリックします。

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 です。このフラグは、Google Cloud 上の GKE クラスタでのみサポートされています。

    • 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。

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

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

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

Config Sync のフリートレベルのデフォルトを構成するには、次の手順を行います。

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

    機能マネージャーに移動

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

  3. フリートレベルの設定を確認します。フリートに登録した新しいクラスタすべてに、これらの設定が継承されます。

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

    1. Config Sync のバージョンを自動的にアップグレードするには、[自動アップグレード]（プレビュー）を選択します。または、Config Sync のバージョンを管理するには、[手動アップグレード] を選択します。自動アップグレードの仕組みの詳細については、Config Sync をアップグレードするをご覧ください。
    2. [手動アップグレード] を選択した場合は、[バージョン] リストで、使用する Config Sync のバージョンを選択します。
    3. [保存] をクリックします。

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

  6. 確認のダイアログで [確認] をクリックします。以前に Config Sync を有効にしていない場合は、[確認] をクリックすると anthosconfigmanagement.googleapis.com API も有効になります。

  7. 省略可: 既存のクラスタをデフォルト設定と同期します。

    1. [フリート内のクラスタ] リストで、同期するクラスタを選択します。
    2. [フリートの設定に同期] をクリックし、表示された確認ダイアログで [確認] をクリックします。このオペレーションが完了するまでには数分かかる場合があります。

インストールを確認する

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）と権限

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

コンポーネント 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-management-operator は、Config Sync が有効になっているときにインストールされます。
  • reconciler-manager は、Config Sync が有効になっているときにインストールされます。
  • admission-webhook は、ドリフト防止が有効になっている場合にインストールされます。
  • reconciler は RootSync と RepoSync ごとにインストールされます。

  • otel-collector は、Config Sync が有効になっているときにインストールされます。

1.17

Deployment 名 レプリカあたりの CPU リクエスト（m） レプリカあたりのメモリ リクエスト（Mi）
config-management-operator 100 100
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 100
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.15

Deployment 名 レプリカあたりの CPU リクエスト（m） レプリカあたりのメモリ リクエスト（Mi）
config-management-operator 100 100
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 のデプロイ

RootSync オブジェクトと RepoSync オブジェクトごとに、Config Sync は同期を処理するための独立した Reconciler デプロイを作成します。Reconciler デプロイは複数のコンテナで構成されます。

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

Standard クラスタ

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

1.15

コンテナ名 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.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 で同じです。

1.15

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

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

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

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

Config Sync のバージョン Helm のバージョン Kustomize のバージョン
1.16.0 以降 v3.11.3 v5.1.1
1.15.0～1.15.3 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 チャートを同期するをご覧ください。

次のステップ