Config Sync のインストール

Config Sync により、クラスタ オペレータは Git リポジトリに保存されている構成ファイルというファイルを使用して Kubernetes リソースを管理できます。このページでは、Config Sync を有効にして構成する方法を説明します。

Config Sync は、Anthos と Google Kubernetes Engine(GKE)ユーザーが使用できます。

始める前に

Config Sync をインストールする前に、環境、クラスタ、ロールを準備して Anthos Config Management が有効になっていることを確認します。

ローカル環境の準備

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

  1. Config Sync の同期先となる構成ファイルを格納できる Git リポジトリを作成するか、対象リポジトリへのアクセス権を取得します。
  2. Cloud SDK をインストールして初期化します。これにより、gcloud コマンドと nomos コマンドが提供されます。Cloud Shell を使用する場合、Cloud SDK がプリインストールされています。

クラスタ要件

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

  • Anthos のサポート対象のプラットフォームとバージョンにある。
  • Kubernetes バージョン 1.14.x 以降を使用している。
  • Autopilot クラスタではない。
  • 4 つ以上の vCPU を備えたマシンタイプを使用するノードプールが 1 つ存在する。
  • Workload Identity が有効になっている。Google Kubernetes Engine(GKE)内で実行しているアプリケーションから Google Cloud サービスにアクセスするには、セキュリティの特性と管理性が優れていることから、Workload Identity を使用することをおすすめします。
  • 限定公開の GKE クラスタを使用する場合は、限定公開の GKE ノードから下り(外向き)を許可するために Cloud NAT が作成されます。また、限定公開の 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. フリートクラスタを登録します。プロジェクトのフリートには、クラスタとそのワークロード(Google Cloud の外部に存在するクラスタも含む)を Anthos の一部として表示、管理するための統合された方法が用意されています。Anthos の料金は、登録済みのクラスタにのみ適用されます。

権限の準備

クラスタを作成したら、Google Cloud Console で Config Sync に必要な GKE Hub 管理者ロールを自身に付与します。Hub 管理者のロールは、フリートに対する完全アクセス権を付与します。

Hub 管理者のロールを付与する手順は次のとおりです。

Console

  1. Cloud Console で [IAM] ページに移動します。

    IAM ページに移動

  2. [追加] をクリックします。

  3. [新しいメンバー] に、メールアドレスを入力します。個人、サービス アカウント、Google グループをメンバーとして追加できます。

  4. [ロールを選択] プルダウン リストで、[GKE Hub 管理者] を検索して選択します。

  5. [保存] をクリックします。

gcloud

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/gkehub.admin

以下を置き換えます。

  • MEMBER: メンバーの識別子。通常、member-type:id の形式(user:my-user@example.com など)で指定します。member に使用できる値の一覧については、ポリシー バインディングのリファレンスをご覧ください。

  • PROJECT_ID: プロジェクト ID

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 サービス アカウント(Google Cloud Source Repositories のリポジトリのみ)

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

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

cookiefile

cookiefile を取得するプロセスは、リポジトリの構成によって異なります。サンプルについては、Cloud Source Repositories のドキュメントの静的認証情報を生成するをご覧ください。認証情報は通常、ユーザーのホーム ディレクトリにある .gitcookies ファイルに保存されますが、セキュリティ管理者から提供されることもあります。

cookiefile を作成するには、次の手順を行います。

  1. 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
    

    /path/to/COOKIEFILE は、適切なパスとファイル名に置き換えます。

  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. リポジトリのリストを取得します。

    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
    
  3. 次のセクションで Config Sync を構成するときに、構成に URL を追加します。Google Cloud Console を使用して Config Sync を構成する場合は、コピーした値を [URL] フィールドに追加します。gcloud コマンドライン ツールを使用して Config Sync を構成する場合は、コピーした値を ConfigManagement オブジェクトの repo フィールドに追加します。

  4. Config Sync を構成するときに、適切な認証タイプを選択します。

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

    gcloud コマンドライン ツールを使用して Config Sync を構成する場合は、secretType として gcpServiceAccount または gcenode を選択します。

    • gcpServiceAccount: クラスタで Workload Identity が有効になっている場合、認証タイプとして gcpServiceAccount を追加します。

      必要であれば、Config Sync の構成に使用できるサービス アカウントを作成します。サービス アカウントに source.reader ロールを付与して、Cloud Source Repositories に対する読み取りアクセス権があることを確認します。

      認証方法に gcpServiceAccount を選択する場合は、Config Sync の構成時に gcpServiceAccountEmail も追加する必要があります。gcpServiceAccountEmail を追加するだけでなく、Config Sync の構成後にロール バインディングを作成する必要があります。これらの手順については、Workload Identity での Cloud Source Repositories の使用セクションをご覧ください。

    • gcenode: クラスタで Workload Identity が有効になっていない場合は、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 では、インストール プロセスを行いながら、さまざまな操作を自動化できます。Anthos と GKE のお客様は、コンソール コマンドが若干異なります。関連するタブをクリックして、適切な手順を表示します。gcloud コマンドライン ツールを使用してインストールを完了することもできます。

Console - Anthos

続行する前に、フリートクラスタを登録したことを確認します。

Anthos を使用する場合は、次の手順で Config Sync を構成します。

  1. Cloud Console で Anthos Config Management のページに移動します。

    Anthos Config Management に移動

  2. 登録済みクラスタを選択して、[構成] をクリックします。

  3. [ACM の Git リポジトリ認証] セクションで、次のいずれかのオプションを選択します。

    • なし: 認証を使用しない
    • SSH: SSH 認証鍵ペアを使用
    • Cookiefile: cookiefile を使用
    • トークン: トークンを使用
    • Google Cloud Repository: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ、選択してください。
  4. まだ行っていない場合は、Google Cloud Console の手順に沿って、Config Sync に Git への読み取り専用アクセス権を付与します。

  5. [続行] をクリックします。

  6. [クラスタ用の ACM 設定] セクションで、次の操作を行います。

    1. Anthos Config Management の [バージョン] で、バージョン 1.7.0 以降を選択します。これにより、デフォルトで複数のリポジトリからの同期が有効になります。
    2. [Config Sync を有効にする] チェックボックスをオンにします。
      1. [URL] フィールドに、信頼できる情報源として使用する Git リポジトリの URL を追加します。HTTPS または SSH プロトコルを使用して URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。プロトコルを入力しない場合は URL が HTTPS URL として扱われます。この欄は必須です。
      2. (省略可)[ブランチ] フィールドに、同期元となるリポジトリのブランチを追加します。デフォルトは、メイン(マスター)ブランチです。
      3. 省略可: [タグ / commit] フィールドに、チェックアウトする Git リビジョン(タグまたはハッシュ)を追加します。デフォルトは HEAD です。
      4. (省略可)[ポリシーのディレクトリ] フィールドに、リポジトリ内の、同期するポリシー階層の最上位へのパスを追加します。デフォルトは、リポジトリのルート ディレクトリです。
      5. (省略可)[同期の待機時間] フィールドに、連続する同期の間隔(秒)を追加します。デフォルト値は 15 秒です。
      6. (省略可)[Git プロキシ] フィールドに、Git リポジトリとの通信時に使用する HTTPS プロキシの URL を入力します。これは省略可能なフィールドです。空白のままにすると、プロキシは使用されません。
      7. ソース形式フィールドで、階層(デフォルト)または非構造化(推奨)のいずれかを選択します。非構造化を選択することをおすすめします。この形式では、自分が一番使いやすい方法で構成ファイルを整理できます。
  7. [完了] をクリックします。[Anthos Config Management] ページに戻ります。数分後、構成したクラスタの横の [ステータス] 列に Synced と表示されます。Error が表示された場合は、Error をクリックして詳細を確認します。

Console - GKE

GKE を使用している場合は、次の手順で Config Sync を構成します。

クラスタの登録

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

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

  1. Cloud Console で [構成管理] ページに移動します。

    [構成管理] に移動

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

  2. 登録プロセスを開始するには、[CONFIG MANAGEMENT を設定] をクリックします。

  3. Config Management API を有効にするには、[次へ] をクリックします。

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

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

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

Config Sync のインストール

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

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

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

    • なし: 認証を使用しない
    • SSH: SSH 認証鍵ペアを使用
    • Cookiefile: cookiefile を使用
    • トークン: トークンを使用
    • Google Cloud Repository: Google サービス アカウントを使用して Cloud Source Repositories にアクセス。このオプションは、Workload Identity がクラスタで有効になっていない場合にのみ、選択してください。
  6. Google Cloud Console の手順に沿って、Config Sync に Git への読み取り専用アクセス権を付与し、[続行] をクリックします。

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

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

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

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

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

  12. ソース形式フィールドで、階層(デフォルト)または非構造化(推奨)のいずれかを選択します。非構造化を選択することをおすすめします。この形式では、自分が一番使いやすい方法で構成ファイルを整理できます。

  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
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY

以下を置き換えます。

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

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

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

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

  • DIRECTORY: 同期先の構成を含むルート ディレクトリへの Git リポジトリのパス。デフォルトは、リポジトリのルート ディレクトリです。

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

Workload Identity で Cloud Source Repositories を使用する

クラスタで Workload Identity が有効になっており、Google サービス アカウントを認証タイプとして使用している場合は、追加の手順を行う必要があります。

前述の手順を完了したら、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 ロールがあることを確認します。

インストールの確認

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

Console - Anthos

次の手順を行います。

  1. Cloud Console で Anthos Config Management のページに移動します。

    Anthos Config Management に移動

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

クラスタのステータスの詳細を表示するには:

  • 目的のクラスタを選択します。クラスタの詳細ページが表示されます。このページでは、クラスタの詳細と Config Sync のインストールの詳細を確認できます。

Console - GKE

次の手順を行います。

  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 のリソース リクエストの合計量を記載します。

機能 CPU メモリ
デフォルト(マルチリポ)モード 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 100 20 複数
otel-collector 200 400 複数
reconciler-manager 200 120 複数
reconciler(RootSync と RepoSync ごとに 1 つ) 250 + デフォルト 200 + デフォルト 複数
hnc-controller-manager 100 + デフォルト 150 + デフォルト Hierarchy Controller
gke-hc-controller-manager 100 + デフォルト 50 + デフォルト Hierarchy Controller

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

2 アドミッション Webhook には 2 つのレプリカがあるため、リソース リクエスト合計を計算する際に、値を倍にする必要があります。

次のステップ