Config Sync のインストール

Config Sync では、1 つ以上の Git リポジトリに保存されている構成ファイルと呼ばれるファイルを使用して、Kubernetes リソースを管理できます。このページでは、Config Sync を有効にしてルート リポジトリから同期するように構成する方法について説明します。Config Sync は、Anthos または Google Kubernetes Engine(GKE)を使用している場合に利用できます。

バージョン 1.7.0 以降の Config Sync をインストールする場合は、Google Cloud Console または gcloud コマンドライン ツールを使用して、最新の Config Management Operator がデフォルトでインストールされます。このオペレータは、複数のリポジトリからの同期や Kustomize と Helm 構成の同期など、追加の機能を提供します。

始める前に

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

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

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

  1. Config Sync が同期する構成ファイルを含む Git リポジトリを作成するか、このリポジトリにアクセスできることを確認します。選択したリポジトリがルート リポジトリになります。コンフィグとリポジトリの設定方法の詳細については、Git リポジトリでコンフィグを使用するをご覧ください。
  2. gcloud コマンドと nomos コマンドを備える Cloud SDK をインストールして初期化します。Cloud Shell を使用する場合、Cloud SDK がプリインストールされています。

クラスタ要件

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

  • Anthos のサポート対象のプラットフォームとバージョンにある。
  • Autopilot クラスタではない。
  • GKE クラスタを使用している場合は、Workload Identity が有効になっている。Google Kubernetes Engine(GKE)内で実行しているアプリケーションから Google Cloud サービスにアクセスするには、セキュリティの特性と管理性が優れていることから、Workload Identity を使用することをおすすめします。
  • 限定公開 GKE クラスタを使用する場合は、Cloud NAT を構成して、限定公開 GKE ノードからの下り(外向き)トラフィックを許可します。詳細については、GKE の設定例をご覧ください。また、限定公開の Google アクセスを有効にして、Google API とサービスで使用される外部 IP アドレスのセットに接続することもできます。

  • Git リポジトリへのアクセス権を Config Sync に付与する際に Google サービス アカウントを使用する場合は、クラスタ内のノードのアクセス スコープに Cloud Source Repositories の読み取り専用のスコープが含まれている必要があります。

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

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

クラスタの準備

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

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

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

  3. gcloud コマンドライン ツールを使用して Config Sync を構成する場合は、今すぐクラスタをフリート登録します。Google Cloud Console を使用する場合は、次をする際にクラスタを登録します。

Config Sync のインストール

以下のセクションで、Config Sync にリポジトリへのアクセス権を付与します。アクセス権を付与したら、ルート リポジトリのインストールを構成します。

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

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

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

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

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 に追加します。

    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: 前のステップで作成したトークン。
  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] フィールドに追加します。gcloud コマンドライン ツールを使用して Config Sync を構成する場合は、構成ファイルの syncRepo フィールドに URL を追加します。

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

    Workload Identity が有効になっている

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

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

      gcloud コマンドライン ツールを使用して Config Sync を構成する場合は、gcpserviceaccountsecretType として追加し、サービス アカウントのメールアドレスを gcpServiceAccountEmail に追加します。

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

      このバインディングにより、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/root-reconciler]" \
         GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      

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

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

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

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

    gcloud コマンドライン ツールを使用して Config Sync を構成する場合は、gcenodesecretType として追加します。

    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 を構成する

このセクションでは、ルート リポジトリの設定を構成します。Google Cloud Console では、インストール プロセスを行いながら、さまざまな操作を自動化できます。gcloud コマンドライン ツールを使用してインストールを完了することもできます。

Google Cloud Console または gcloud コマンドライン ツールで Config Sync をインストールした場合、あとで kubectl コマンドを使用して構成を変更することはできません。

Console

クラスタを登録する

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

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

  1. Cloud Console を使用する

    このページには現在、登録および構成が行われているクラスタが表示されます。新しいクラスタの登録も開始できます。

  2. [新しい設定] をクリックします。

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

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

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

Config Sync のインストール

クラスタを登録したら、Config Sync のインストールと構成に進むことができます。

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

  1. [構成管理の登録済みクラスタを選択する] ページで、構成するクラスタを選択し、[次へ] を選択します。
  2. 表示される [Config Sync] ページで、[バージョン] プルダウン リストから、使用する Anthos Config Management のバージョンを選択します。デフォルトは現在のバージョンです。
  3. 構成セクションで、[Config Sync を有効にする] チェックボックスをオンのままにします。
  4. [URL] フィールドに、信頼できる情報源として使用する Git リポジトリの URL を追加します。HTTPS プロトコルまたは SSH プロトコルを使用して URL を入力します。例: https://github.com/GoogleCloudPlatform/anthos-config-management-samples認証タイプとして SSH を使用する場合は、SSH プロトコルを使用して URL を入力します。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。
  5. [認証タイプ] プルダウン リストで、次のいずれかを選択します。

    • なし: 認証を使用しない
    • 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 サービス アカウント] タブをご覧ください。
  6. Google Cloud Console の手順に沿って、Config Sync に Git への読み取り専用アクセス権を付与し、[続行] をクリックします。

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

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

  9. 省略可: [ポリシーのディレクトリ] フィールドに、リポジトリ内の、同期するポリシー階層の最上位へのパスを追加します。デフォルトは、リポジトリのルート ディレクトリです。

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

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

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

  12. 省略可: [ソース形式] フィールドで、unstructured または hierarchy のいずれかを選択しますデフォルトは 非構造化 です。この形式を使用すると、構成ファイルを最も都合の良い方法で整理できるため、非構造化 を選択することをおすすめします。

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

  14. [Complete] をクリックして Config Sync のインストールを完了します。

gcloud

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

Anthos または GKE を使用する場合は、次の手順を行って gcloud コマンドライン ツールで Config Sync を構成します。

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

新しいマニフェストの作成

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

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a Git repository, omit the following fields. You
    # can configure them later.
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    # the `preventDrift` field is supported in Anthos Config Management version 1.10.0 and later.
    preventDrift: PREVENT_DRIFT

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

  • FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を記述することをおすすめします。この形式では、自分が一番使いやすい方法で構成ファイルを整理できます。
  • REPO: 真の同期ソースとして使用する Git リポジトリの URL を追加します。HTTPS プロトコルまたは SSH プロトコルを使用して URL を入力します。例: https://github.com/GoogleCloudPlatform/anthos-config-management-samplessecretType として SSH を使用する場合は、SSH プロトコルを使用して URL を入力します。このフィールドは必須です。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。
  • BRANCH: 同期元となるリポジトリのブランチ。このフィールドは省略可能で、デフォルト値は master です。
  • TYPE: 以下の secretTypes のいずれかです。

    • 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 の読み取り専用アクセス権を付与するをご覧ください。

  • 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 hub 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 hub config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

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

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

ルート リポジトリの構成が終了したら、必要に応じて名前空間リポジトリからの同期を構成するを選択できます。これらのリポジトリは、クラスタ全体で特定の Namespace に同期される名前空間スコープの構成ファイルを 1 つのリポジトリに保存する場合に役立ちます。

インストールの検証

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

Console

次の手順を行います。

  1. Cloud Console を使用する

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

gcloud

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

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

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

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

gcloud beta container hub config-management apply

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

git-creds Secret が欠落しているか、無効であるなど、すぐに検出されない無効な構成が存在する可能性があります。トラブルシューティングの手順については、トラブルシューティング ページの有効であるが正しくない ConfigManagement オブジェクトをご覧ください。

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

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

リソース リクエスト

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

次の表に、使用する機能に応じた Config Sync のリソース リクエストの合計量を記載します。

機能 CPU メモリ
(v1.10 以降)Config Sync アドミッション Webhook を使用するデフォルト(マルチ リポジトリ)モード 240 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 620 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
(v1.10 以降)デフォルト(マルチ リポジトリ)モード 220 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 600 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
(v1.9)デフォルト(マルチ リポジトリ)モード 240 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 620 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
(v1.7 ~ v1.8)デフォルト(マルチ リポジトリ)モード 710 m + 260 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 620 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
Hierarchy Controller 220 m 220 Mi
シングル リポジトリ モード 460 m 310 Mi

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

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

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

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

2 アドミッション Webhook には 2 つのレプリカがあるため、リソース リクエスト合計を計算する際に、値を倍にする必要があります。バージョン 1.10.0 より前の Anthos Config Management では、アドミッション Webhook はデフォルトで有効になっています。Anthos Config Management バージョン 1.10.0 以降では、アドミッション Webhook はデフォルトで無効になっています。

次のステップ