Config Sync のインストール

Config Sync では、1 つ以上の Git リポジトリに格納された構成ファイルを使用して、Kubernetes リソースを管理できます。このページでは、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. Git リポジトリを作成するか、Git リポジトリにアクセスできることを確認します。ここに、Config Sync が同期する構成ファイルを追加します。構成ファイルとリポジトリを設定する方法については、Git リポジトリに構成ファイルを追加するをご覧ください。選択したリポジトリがルート リポジトリになります。
  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 を構成する場合は、GKE クラスタまたは Google Cloud 外のクラスタフリートに登録します。Google Cloud コンソールを使用する場合は、Config Sync の構成時にクラスタを登録します。

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 クラスタの両方でこの認証方法を使用できます。

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

    Workload Identity が有効になっている

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

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

      Google Cloud CLI を使用して Config Sync を構成する場合は、gcpserviceaccountsecretType として追加し、サービス アカウントのメールアドレスを 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_NAMEroot-reconciler です。それ以外の場合は root-reconciler-ROOT_SYNC_NAME です。

        名前空間リポジトリでは、RepoSync の名前が repo-sync の場合、KSA_NAMEns-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 を構成する場合は、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 では、インストール プロセスを行いながら、さまざまな操作を自動化できます。Google Cloud CLI を使用してインストールを完了することもできます。

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

コンソール

クラスタを登録する

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

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

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

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

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

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

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

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

Config Sync のインストール

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

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

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

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

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

    Google のサンプル

    Google サンプル リポジトリを使用するには、[Use Google sample] を選択します。このリポジトリには、CIS 制約が事前に設定されています。これらの制約はクラスタに同期され、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 を入力します。これは省略可能なフィールドです。空白のままにすると、プロキシは使用されません。プロキシは、cookiefilenone、または 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

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

Anthos または GKE を使用している場合は、次の手順を行い、Google Cloud CLI で 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-samples を使用します。secretType として 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。

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

インストールを確認する

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

コンソール

次の手順を行います。

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

  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 のバージョンごとにリソース リクエストの合計量を示します。これは、使用している機能に応じて異なります。

1.11

機能 CPU(m) メモリ(Mi)
Config Sync 220 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 600 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
アドミッション Webhook を有効にした Config Sync 240 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 700 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
Hierarchy Controller 220 m 220 Mi

1.10

機能 CPU(m) メモリ(Mi)
Config Sync 220 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 600 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
アドミッション Webhook を有効にした Config Sync 240 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 620 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
Hierarchy Controller 220 m 220 Mi

1.9

機能 CPU(m) メモリ(Mi)
デフォルト モード(RootSync API と RepoSync API を使用) 240 m + 80 m *(RootSync オブジェクトおよび RepoSync オブジェクトの数) 620 Mi + 210 Mi *(RootSync オブジェクトと RepoSync オブジェクトの数)
Hierarchy Controller 220 m 220 Mi
デフォルト以外のモード 460 m 310 Mi

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

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

1.11

Deployment 名 レプリカあたりの CPU リクエスト(m) レプリカあたりのメモリ リクエスト(Mi) 単一または複数のリポジトリ
git-importer 450 300 単一
monitor デフォルト1 デフォルト 単一
resource-group-controller-manager 100 + デフォルト 50 + デフォルト 複数
admission-webhook2 20 100 複数
otel-collector 200 400 複数
reconciler-manager 50 200 複数
reconciler(RootSync と RepoSync ごとに 1 つ) 80 + デフォルト 200 + デフォルト 複数
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 つのレプリカがあるため、リソース リクエスト合計を計算する際に、値を倍にする必要があります。Anthos Config Management バージョン 1.10.0 より前のバージョンでは、アドミッション Webhook がデフォルトで有効になっています。Anthos Config Management バージョン 1.10.0 以降では、アドミッション Webhook がデフォルトで無効になっています。

1.10

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

1.9

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 つのレプリカがあるため、リソース リクエスト合計を計算する際に、値を倍にする必要があります。

次のステップ