Config Sync をインストールする

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

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

始める前に

Config Sync をインストールする前に、環境、クラスタ、ロールを準備して Anthos Config Management を有効にします。

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

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

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

クラスタ要件

次の要件を満たすクラスタを作成するか、このクラスタにアクセスできることを確認します。

クラスタの準備

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

  1. Anthos Config Management を初めて使用する場合は、Anthos Config Management を有効にします。

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

  3. 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 認証鍵ペア
  • cookiefile
  • トークン
  • Google サービス アカウント（Cloud Source Repositories のリポジトリのみ）

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

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. ローカル ディスクから秘密鍵を削除するか、秘密鍵を保護します。

  5. 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 にある場合は、Google サービス アカウントを使用して、マネージド クラスタと同じプロジェクト内のリポジトリに対するアクセス権を Config Sync に付与できます。

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

  1. 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 Console を使用して Config Sync を構成する場合は、URL を [URL] フィールドに追加します。Google Cloud CLI を使用して Config Sync を構成する場合は、構成ファイルの syncRepo フィールドに URL を追加します。

  2. Config Sync を構成するときに、適切な認証タイプを選択します。選択する認証タイプは、所有しているクラスタの種類と Workload Identity が有効かどうかによって異なります。

    • Workload Identity が有効な場合: GKE Workload Identity を有効にしている場合、またはフリートの Workload Identity を使用している場合は、この方法を使用します。フリートの Workload Identity を使用している場合は、GKE クラスタと非 GKE クラスタの両方でこの認証方法を使用できます。

      クラスタがフリートに登録されている場合、Config Sync はデフォルトでフリートの Workload Identity を使用します。登録したクラスタでフリートの Workload Identity が有効になっていることを確認します。詳細については、クラスタを登録するをご覧ください。クラスタがフリート ホスト プロジェクトと異なるプロジェクトにある場合は、フリート ホスト プロジェクトの Kubernetes サービス アカウントに Google サービス アカウントをバインドする必要があります。

    • Workload Identity が有効になっていない場合: この方法は、GKE クラスタにのみ使用できます。

    Workload Identity が有効になっている

    1. 必要に応じて、サービス アカウントを作成します。サービス アカウントに source.reader ロールを付与して、Cloud Source Repositories に対する読み取りアクセス権があることを確認します。

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

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

    3. 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 \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

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

      • PROJECT_ID: GKE Workload Identity を使用している場合は、組織のプロジェクト ID を追加します。

        フリートの Workload Identity を使用している場合は、2 つの異なるプロジェクト ID を使用できます。serviceAccount:PROJECT_ID で、クラスタが登録されているフリートのプロジェクト ID を追加します。GSA_NAME@PROJECT_ID に、Cloud Source Repositories のリポジトリに対する読み取りアクセス権を持つプロジェクトのプロジェクト ID を追加します。

      • KSA_NAME: Reconciler の Kubernetes サービス アカウント。ルート リポジトリでは、RootSync の名前が root-sync の場合、KSA_NAME は root-reconciler です。それ以外の場合は root-reconciler-ROOT_SYNC_NAME です。

        名前空間リポジトリでは、RepoSync の名前が repo-sync の場合、KSA_NAME は ns-reconciler-NAMESPACE です。それ以外の場合は ns-reconciler-NAMESPACE-REPO_SYNC_NAME です。

      • GSA_NAME: Cloud Source Repositories への接続に使用するカスタム Google サービス アカウント。選択した Google サービス アカウントに source.reader ロールがあることを確認します。

    Workload Identity が有効になっていない

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

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

    Google Cloud Repository または gcenode を選択すると、Compute Engine のデフォルトのサービス アカウントを使用できます。デフォルトでは、Compute Engine のデフォルトのサービス アカウント PROJECT_ID-compute@developer.gserviceaccount.com には、同じプロジェクトのリポジトリに対する source.reader アクセス権が付与されています。ただし、Cloud Source Repositories がクラスタのプロジェクトと異なるプロジェクトに存在する場合、クラスタのプロジェクトからデフォルトの Compute Engine サービス アカウントに Cloud Source Repositories のプロジェクトの source.reader を付与する必要があります。

    次のコマンドで source.reader ロールを追加できます。

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

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

    • PROJECT_ID: 組織のプロジェクト ID
    • PROJECT_NUMBER: 組織のプロジェクト番号

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

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

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

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

ただし、ほとんどのユーザーは、制限付きイメージにアクセスするために、認証情報を作成する必要があります。制限付きの読み取りアクセスが許可されているイメージの場合、認証タイプとして gcenode または gcpserviceaccount を使用する Google サービス アカウントを使用できます。

gcenode

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

  1. 次のコマンドを実行して、プロジェクト番号を環境変数に保存します。

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID \
    --format=json | jq -r .projectNumber)

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

  2. Compute Engine サービス アカウントに、Artifact Registry または Container Registry に対する読み取り権限を付与します。

    Artifact Registry

    Artifact Registry に対するアクセス権を付与するには、次のコマンドを実行します。

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

    Container Registry

    Container Registry に対するアクセス権を付与するには、次のコマンドを実行します。

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

gcpserviceaccount

クラスタで GKE Workload Identity またはフリートの Workload Identity を使用している場合は、認証タイプとして gcpserviceaccount を使用できます。

  1. サービス アカウントがない場合は、サービス アカウントを作成して、Artifact Registry または Container Registry の権限を付与します。

    Artifact Registry

    サービス アカウントに Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールを付与します。

    Container Registry

    サービス アカウントに Container Registry サービス エージェント（roles/containerregistry.ServiceAgent）IAM ロールを付与します。

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

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

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

    • PROJECT_ID: GKE Workload Identity を使用している場合は、組織のプロジェクト ID。フリートの Workload Identity を使用している場合は、2 つの異なるプロジェクト ID を使用できます。serviceAccount:PROJECT_ID で、クラスタが登録されているフリートのプロジェクト ID を追加します。GSA_NAME@PROJECT_ID に、Cloud Source Repositories のリポジトリに対する読み取りアクセス権を持つプロジェクトのプロジェクト ID を追加します。
    • KSA_NAME: Reconciler の Kubernetes サービス アカウント。
      • ルート リポジトリで、RootSync 名が root-sync の場合は、root-reconciler を追加します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を追加します。
      • 名前空間リポジトリで、RepoSync 名が repo-sync の場合は ns-reconciler-NAMESPACE を追加します。それ以外の場合は、ns-reconciler-NAMESPACE-REPO_SYNC_NAME を追加します。
    • GSA_NAME: Artifact Registry または Container Registry への接続に使用するカスタム Google サービス アカウント。
      • Artifact Registry の場合、サービス アカウントに Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。
      • Container Registry の場合、サービス アカウントに Container Registry サービス エージェント（roles/containerregistry.ServiceAgent）の IAM ロールが必要です。

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

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

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

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

  • token
  • gcenode

  • gcpserviceaccount

token

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 リポジトリのパスワード。

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

gcenode

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

  1. プロジェクト番号を環境変数に保存します。

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')

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

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

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

gcpserviceaccount

Helm チャートを Artifact Registry に保存し、クラスタで GKE Workload Identity かフリート Workload Identity を使用する場合、gcpserviceaccount を認証タイプとして使用できます。

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

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

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

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

    • PROJECT_ID: GKE Workload Identity を使用している場合は、組織のプロジェクト ID。フリートの Workload Identity を使用している場合は、2 つの異なるプロジェクト ID を使用できます。serviceAccount:PROJECT_ID で、クラスタが登録されているフリートのプロジェクト ID を追加します。GSA_NAME@PROJECT_ID に、Cloud Source Repositories のリポジトリに対する読み取りアクセス権を持つプロジェクトのプロジェクト ID を追加します。
    • KSA_NAME: Reconciler の Kubernetes サービス アカウント。
      • ルート リポジトリで、RootSync 名が root-sync の場合は、root-reconciler を追加します。それ以外の場合は、root-reconciler-ROOT_SYNC_NAME を追加します。
      • 名前空間リポジトリで、RepoSync 名が repo-sync の場合は ns-reconciler-NAMESPACE を追加します。それ以外の場合は、ns-reconciler-NAMESPACE-REPO_SYNC_NAME を追加します。
    • GSA_NAME: Artifact Registry への接続に使用するカスタム Google サービス アカウント。このサービス アカウントには、Artifact Registry 読み取り（roles/artifactregistry.reader）IAM ロールが必要です。

Config Sync を構成する

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

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

コンソール

クラスタを登録する

構成管理を使用するには、まずクラスタを登録する必要があります。クラスタを登録すると、共通の構成とポリシーのセットを共有できます。

クラスタを登録するには、次の操作を行います。

  1. Google Cloud コンソールの場合:

    • Google Kubernetes Engine を使用している場合は、[構成とポリシー] セクションで、GKE の構成ページに移動します。

      [構成管理] に移動

    • Anthos を使用している場合は、[構成とポリシー] セクションで、Anthos の構成ページに移動します。

      [構成管理] に移動

  2. [ Config Sync のインストール] をクリックします。
  3. [構成管理の登録済みクラスタを選択する] ページで、[このプロジェクトの未登録のクラスタ] テーブルを探し、登録したいクラスタを見つけます。

  4. 登録するクラスタの横にある [登録] をクリックします。

    クラスタが正常に登録されると、[構成管理の登録済みクラスタを選択する] テーブルに表示されます。

Config Sync をインストールする

クラスタを登録したら、Config Sync のインストールと構成を続行できます。

Config Sync をインストールするには、次の手順を行います。

  1. [構成管理の登録済みクラスタを選択する] ページで、構成するクラスタを選択し、[次へ] をクリックします。

  2. Policy Controller をインストールする場合は、[Policy Controller を有効にする] チェックボックスをオンのままにして、[次へ] をクリックします。

  3. [リポジトリ] プルダウン リストで、[Use Google sample] または [カスタム] を選択します。

    Google のサンプル

    Google サンプル リポジトリを使用するには、[Use Google sample] を選択します。このリポジトリには、Policy Controller のバンドルが含まれています。

    このオプションを選択するには、Policy Controller をインストールして、Policy Controller の制約テンプレート ライブラリをインストールし、参照制約を有効にする必要があります。これらの Policy Controller オプションはデフォルトで有効になっています。

    カスタム

    [カスタム] を選択して独自の Git リポジトリを使用し、次のフィールドを構成します。

    1. [URL] フィールドに、信頼できる情報源として使用する Git リポジトリの URL を追加します。HTTPS または SSH プロトコルを使用して URL を入力します。例: https://github.com/GoogleCloudPlatform/anthos-config-management-samples認証の種類として SSH を使用する場合は、SSH プロトコルを使用して URL を入力します。

    2. [詳細設定を表示] をクリックします。

    3. [認証タイプ] プルダウン リストで、次のいずれかを選択します。

      • なし: 認証を使用しない
      • SSH: SSH 認証鍵ペアを使用
      • Cookiefile: cookiefile を使用
      • トークン: トークンを使用
      • Google Cloud Repository: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ選択してください。
      • Workload Identity: Google サービス アカウントを使用して、Cloud Source Repositories のリポジトリにアクセス。Workload Identity を選択できるのは、Workload Identity が有効になっている GKE クラスタを使用する場合のみです。他の Anthos クラスタの Fleet Workload Identity との統合はサポートされていません。[Workload Identity] を選択する場合は、Google サービス アカウントのメールアドレスを追加する必要がありますたとえば、acm@PROJECT_ID.iam.gserviceaccount.com を使用します。この認証タイプを選択した場合は、Config Sync の構成を完了した後に IAM ポリシー バインディングを作成する必要があります。詳しくは、Config Sync に Git の読み取り専用アクセス権を付与するセクションの 「Google サービス アカウント」タブをご覧ください。

    4. Google Cloud Console の手順に沿って、Config Sync に Git への読み取り専用アクセス権を付与し、[続行] をクリックします。

    5. 省略可: [ブランチ] フィールドに、同期元となるリポジトリのブランチを追加します。デフォルトはマスター ブランチです。

    6. 省略可: [タグ / commit] フィールドに、チェックアウトする Git リビジョン（タグまたはハッシュ）を追加します。デフォルトは HEAD です。

    7. （省略可）[Configuration directory] フィールドに、同期元のディレクトリのパスを Git リポジトリのルートからの相対パスで追加します。指定したディレクトリのすべてのサブディレクトリがクラスタと同期されます。デフォルト値は、リポジトリのルート ディレクトリです。

    8. 省略可: [同期の待機時間] フィールドに、連続する同期の間隔（秒）を追加します。デフォルト値は 15 秒です。

    9. 省略可: [Git プロキシ] フィールドに、Git リポジトリとの通信時に使用する HTTPS プロキシの URL を入力します。これは省略可能なフィールドです。空白のままにすると、プロキシは使用されません。プロキシは、cookiefile、none、または token の認証タイプを使用する場合にのみサポートされます。

      HTTPS プロキシの URL は、Config Sync が作成する RootSync リソースで書式なしテキストとして表示されます。URL にユーザー名やパスワードなどの機密情報が含まれていて、機密情報を非表示にする必要がある場合は、Git プロキシを空白のままにして、Git 認証情報に使用した Secret に HTTPS プロキシの URL を追加します。認証タイプが cookiefile または token の場合、プロキシを Secret に保存できます。

    10. 省略可: [ソース形式] プルダウン リストから、[unstructured] または [hierarchy] を選択します。デフォルトは unstructured です。この形式を使用すると、構成ファイルを最も都合の良い方法で整理できるため、unstructured を選択することをおすすめします。できます。

    11. 省略可: [構成管理のバージョン] プルダウン リストから、使用する Anthos Config Management のバージョンを選択します。デフォルトは現在のバージョンです。

  4. インストールを完了するには、[完了] をクリックします。[構成管理] ページに戻ります。

gcloud

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

  1. 新しい 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:
  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
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

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

  • 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

  • BRANCH: 同期元となるリポジトリのブランチ。このフィールドは省略可能です。デフォルト値は master です。

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

    helm

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

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

  • 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 ファイルのパス

2. 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 つのリポジトリに保存する場合に役立ちます。

インストールを確認する

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

コンソール

次の手順を完了します。

  1. Google Cloud コンソールの場合:

    • Google Kubernetes Engine を使用している場合は、[構成とポリシー] セクションで、GKE の構成ページに移動します。

      [構成管理] に移動

    • Anthos を使用している場合は、[構成とポリシー] セクションで、Anthos の構成ページに移動します。

      [構成管理] に移動

  2. クラスタのテーブルで、[Config Sync のステータス] 列を確認します。正常にインストールされていれば、ステータスは [同期済み] になります。

gcloud

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

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

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

インストールに成功すると、ステータスは SYNCED になります。上のコマンドを実行した後にエラーが表示された場合は、git-creds Secret が作成されていることを確認してください。Secret が作成されている場合は、次のコマンドをもう一度実行してみてください。

gcloud beta container fleet config-management apply

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

Config Sync をアップグレードする

Anthos Config Management をアップグレードすると、Config Sync がアップグレードされます。詳細については、Anthos Config Management のアップグレードをご覧ください。

リソース リクエスト

リソース リクエスト合計の概要

次の表に、サポートされている Config Sync のバージョンごとにリソース リクエストの合計量を示します。これは、使用している機能に応じて異なります。

1.15

機能 CPU（m） メモリ（Mi）
Config Sync 330 m + 80 m *（RootSync オブジェクトおよび RepoSync オブジェクトの数）1 850 Mi + 600 Mi *（RootSync オブジェクトと RepoSync オブジェクトの数）
アドミッション Webhook を有効にした Config Sync 350 m + 80 m *（RootSync オブジェクトおよび RepoSync オブジェクトの数）1 1,050 Mi + 600 Mi *（RootSync オブジェクトと RepoSync オブジェクトの数）
Hierarchy Controller 200 m 200 Mi

1 RootSync と RepoSync のソースタイプが helm に設定されている場合、CPU リクエストは 120m *（RootSync オブジェクトと RepoSync オブジェクトの数）です。

1.14

機能 CPU（m） メモリ（Mi）
Config Sync 330 m + 80 m *（RootSync オブジェクトおよび RepoSync オブジェクトの数）1 850 Mi + 600 Mi *（RootSync オブジェクトと RepoSync オブジェクトの数）
アドミッション Webhook を有効にした Config Sync 350 m + 80 m *（RootSync オブジェクトおよび RepoSync オブジェクトの数）1 1,050 Mi + 600 Mi *（RootSync オブジェクトと RepoSync オブジェクトの数）
Hierarchy Controller 200 m 200 Mi

1 RootSync と RepoSync のソースタイプが helm に設定されている場合、CPU リクエストは 120m *（RootSync オブジェクトと RepoSync オブジェクトの数）です。

1.13

機能 CPU（m） メモリ（Mi）
Config Sync 330 m + 80 m *（RootSync オブジェクトおよび RepoSync オブジェクトの数） 850 Mi + 600 Mi *（RootSync オブジェクトと RepoSync オブジェクトの数）
アドミッション Webhook を有効にした Config Sync 350 m + 80 m *（RootSync オブジェクトおよび RepoSync オブジェクトの数） 1,050 Mi + 600 Mi *（RootSync オブジェクトと RepoSync オブジェクトの数）
Hierarchy Controller 200 m 200 Mi

詳細なリソース リクエスト

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

1.15

Deployment 名 レプリカあたりの CPU リクエスト（m） レプリカあたりのメモリ リクエスト（Mi） 単一または複数のリポジトリ
git-importer 450 400 単一
monitor デフォルト1 デフォルト 単一
resource-group-controller-manager 110 300 複数
admission-webhook2 10 100 複数
otel-collector 200 400 複数
reconciler-manager 20 150 複数
reconciler（RootSync と RepoSync ごとに 1 つ） 80 + デフォルト3 600 + デフォルト 複数
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 デフォルトのリソース リクエストでは 10 milliCPU（mCPU）の CPU リクエストと 10 Mi のメモリ リクエストが使用されています。

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

3 RootSync と RepoSync のソースタイプが helm に設定されている場合、CPU リクエストは 120m *（RootSync オブジェクトと RepoSync オブジェクトの数）です。

1.14

Deployment 名 レプリカあたりの CPU リクエスト（m） レプリカあたりのメモリ リクエスト（Mi） 単一または複数のリポジトリ
git-importer 450 400 単一
monitor デフォルト1 デフォルト 単一
resource-group-controller-manager 110 300 複数
admission-webhook2 10 100 複数
otel-collector 200 400 複数
reconciler-manager 20 150 複数
reconciler（RootSync と RepoSync ごとに 1 つ） 80 + デフォルト3 600 + デフォルト 複数
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 デフォルトのリソース リクエストでは 10 milliCPU（mCPU）の CPU リクエストと 10 Mi のメモリ リクエストが使用されています。

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

3 RootSync と RepoSync のソースタイプが helm に設定されている場合、CPU リクエストは 120m *（RootSync オブジェクトと RepoSync オブジェクトの数）です。

1.13

Deployment 名 レプリカあたりの CPU リクエスト（m） レプリカあたりのメモリ リクエスト（Mi） 単一または複数のリポジトリ
git-importer 450 400 単一
monitor デフォルト1 デフォルト 単一
resource-group-controller-manager 110 300 複数
admission-webhook2 10 100 複数
otel-collector 200 400 複数
reconciler-manager 20 150 複数
reconciler（RootSync と RepoSync ごとに 1 つ） 80 + デフォルト 600 + デフォルト 複数
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 デフォルトのリソース リクエストでは 10 milliCPU（mCPU）の CPU リクエストと 10 Mi のメモリ リクエストが使用されています。

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

次のステップ