Config Sync のインストール

Config Sync をインストールすると、クラスタ オペレータは Git リポジトリに保存された構成ファイルを使用して Kubernetes リソースを管理できます。

このページでは、Anthos Config Management で Config Sync を有効にして構成する方法を説明します。以下の手順で管理する各クラスタに Anthos Config Management をインストールして構成します。

始める前に

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

ローカル環境の準備

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

  1. プロジェクトで Anthos API を有効にします。

    Console

    Google Cloud Console で、Anthos API ページに移動します。

    Anthos API ページに移動

    • [有効にする] をクリックします。

    gcloud

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

    gcloud services enable anthos.googleapis.com
    
  2. この手順で使用する gcloudgsutilkubectlnomos コマンドを含む Cloud SDK をインストールして初期化します。Cloud Shell を使用する場合、Cloud SDK がプリインストールされています。

  3. デフォルトでは、Cloud SDK によって kubectl はインストールされません。kubectl をインストールするには、次のコマンドを使用します。

    gcloud components install kubectl
    
  4. Anthos Config Management のコンポーネントをダウンロードできるように、gcloud auth login コマンドを使用して Google Cloud に対する認証を行います。

クラスタの準備

次のタスクを行ってクラスタを準備します。

  1. クラスタが Anthos でサポートされるプラットフォームとバージョンにあることを確認します。

  2. Connect を使用して Anthos Environクラスタを登録します。プロジェクトの Environ は、Google Cloud 外のクラスタを含む Anthos の一部として、クラスタとそのワークロードを表示して管理するために統合された方法を提供します。Anthos の料金は、登録済みのクラスタにのみ適用されます。

権限の準備

使用するインストール方法に応じて、Config Sync をインストールする権限をユーザーに付与する必要があります。Identity and Access Management(IAM)のロールを付与する方法については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。

Console

Config Sync をインストールする Google Cloud ユーザーには、Hub API を使用してクラスタを管理するために GKE Hub 管理者roles/gkehub.admin)のロールが必要です。

gcloud

Config Sync をインストールする Google Cloud ユーザーには、Hub API を使用してクラスタを管理するために GKE Hub 管理者roles/gkehub.admin)のロールが必要です。

kubectl

GKE を使用している場合、Config Sync をインストールする Google Cloud ユーザーには、クラスタに新しいロールを作成するための IAM 権限が必要です。

例:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin --user USER_ACCOUNT

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

  • CLUSTER_NAME: クラスタ名
  • USER_ACCOUNT: Google Cloud アカウントのメールアドレス

ローカル システムでの gcloud コマンドライン ツールの構成方法によっては、--project フィールドと --zone フィールドを追加する必要があります。

Anthos Config Management の有効化

Anthos Config Management を初めて使用する場合は、次の手順で機能を有効にします。

Console

  1. Google Cloud Console で、Anthos の [機能] ページに移動します。

    Anthos の機能ページに移動

  2. [構成管理] の行で、[有効にする] をクリックします。

  3. 確認ウィンドウで、[構成管理の有効化] をクリックします。

gcloud

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

 gcloud alpha container hub config-management enable

Config Sync のインストール

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

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

Config Sync には、Git リポジトリに対する読み取り専用権限が必要です。この権限により、Config Sync はリポジトリに commit された構成ファイルを読み取り、クラスタに適用できるようになります。認証情報が必要な場合は、登録された各クラスタの git-creds Secret に保存されています。

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

ただし、ほとんどのユーザーは、リポジトリへの読み取りアクセスが制限されているため、認証情報を作成する必要があります。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)または 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 にある場合は、secretType: gcenode を使用して、マネージド クラスタと同じプロジェクト内のリポジトリに Config Sync へのアクセス権を付与できます。

前提条件

開始する前に、次の前提条件を満たしていることを確認してください。

  • クラスタ内のノードのアクセス スコープには cloud-source-repos-ro を含める必要があります。デフォルトでは、Compute Engine のデフォルトのサービス アカウント PROJECT_ID-compute@developer.gserviceaccount.com には、同じプロジェクトのリポジトリに対する 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: 組織のプロジェクト番号
  • クラスタ内のノードのアクセス スコープには cloud-source-repos-ro を含める必要があります。このスコープを追加するには、クラスタ作成時に指定された --scopes リストに cloud-source-repos-ro を組み込むか、クラスタの作成時に cloud-platform スコープを使用します。

    gcloud container clusters create example-cluster --scopes=cloud-platform
    

Cloud Source Repositories を SyncRepo として使用する

これらの前提条件が満たされたら、Config Sync の構成時に目的の Cloud Source Repositories のリポジトリの URL に spec.git.syncRepo を設定します。

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

  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. syncRepo として URL を追加します。例:

    spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
    

Workload Identity で Cloud Source Repositories を使用する

クラスタで Workload Identity が有効になっている場合、secretType: gcenode を使用するには追加の手順が必要です。上記の手順に加え、次のセクションの Config Sync の構成(次のセクションで行う場合)も完了したら、Kubernetes サービス アカウントと Google サービス アカウントの間の IAM ポリシー バインディングを作成します。Config Sync を初めて構成するまで、Kubernetes サービス アカウントは作成されません。

このバインディングにより、Config Sync Kubernetes サービス アカウントが Compute Engine のデフォルトのサービス アカウントとして機能できるようになります。

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

次のように置き換えます。 * PROJECT_ID: 組織のプロジェクト ID * PROJECT_NUMBER: 組織のプロジェクト番号

バインディングを作成したら、Compute Engine のデフォルト サービス アカウントのメールアドレスを使用して、annotation を Config Sync Kubernetes サービス アカウントに追加します。

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

PROJECT_NUMBER は、組織のプロジェクト番号に置き換えます。

Config Sync の構成

Google Cloud Console では、インストール プロセスを行いながら、さまざまな操作を自動化できます。インストールは、gcloud コマンドライン ツールまたは kubectl コマンドで完了することもできます。

GKE クラスタを使用している場合は、Cloud Console を使用して Config Sync を構成することをおすすめします。Cloud Console または gcloud ツールでは非公開のレジストリがサポートされていないため、Anthos clusters on VMware クラスタを使用している場合は、kubectl コマンドを使用して Config Sync をインストールする必要があります。

Config Sync を構成するには、次の手順を行います。

Console

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

    Anthos Config Management に移動

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

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

    • なし
    • SSH
    • Cookiefile
    • トークン
    • Google Cloud Repository

    まだ行っていない場合は、Config Sync に Git への読み取り専用アクセス権を付与します。

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

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

    1. [バージョン] フィールドで、Anthos Config Management のバージョンを選択します。
    2. [Config Sync を有効にする] チェックボックスをオンにします。
      1. [URL] フィールドに、信頼できる情報源として使用する Git リポジトリの URL を追加します。このフィールドは必須です。
      2. [ブランチ] フィールドに、同期元のリポジトリのブランチを追加します。デフォルトは、メイン(マスター)ブランチです。
      3. [タグ / commit] で、Git のリビジョン(タグまたはハッシュ)を追加してチェックアウトします。デフォルトは HEAD です。
      4. [ポリシーのディレクトリ] フィールドで、同期するポリシー階層の最上部にリポジトリ内のパスを追加します。デフォルトは、リポジトリのルート ディレクトリです。
      5. [同期の待機時間] フィールドで、連続する同期の時間間隔を秒単位で追加します。デフォルト値は 15 秒です。
      6. [Git プロキシ] フィールドに、Git リポジトリとの通信時に使用する HTTPS プロキシの URL を入力します。これは省略可能なフィールドです。空白のままにすると、プロキシは使用されません。
      7. [ソース形式] フィールドで、リポジトリに階層を持たせるか、非構造化かを選択します。
  6. [完了] をクリックします。Anthos Config Management メニューに戻ります。数分後、構成したクラスタの横の [ステータス] 列に Synced と表示されます。Error が表示された場合は、Error をクリックして詳細を確認します。

gcloud

  1. config-management.yaml という名ファイルを作成し、次の YAML ファイルをコピーします。

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

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

    • REPO: 真の同期ソースとして使用する Git リポジトリの URL。このフィールドは必須です。
    • BRANCH: 同期元となるリポジトリのブランチ。デフォルトは、メイン(マスター)ブランチです。
    • TYPE: 以下の SecretTypes のいずれかです。

      • none
      • ssh
      • cookiefile
      • token
      • gcenode
    • DIRECTORY: リポジトリ内で同期するポリシー階層の最上位のパス。デフォルトは、リポジトリのルート ディレクトリです。

      spec フィールドに追加できるフィールドの完全なリストについては、次の Git リポジトリの構成セクションをご覧ください。spec フィールド以外の構成の値を変更しないでください。

  2. config-management.yaml ファイルを適用します。

     gcloud alpha container hub config-management apply \
         --membership=CLUSTER_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

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

    • CLUSTER_NAME: この構成を適用する登録済みクラスタの名前
    • CONFIG_YAML_PATH: config-management.yaml ファイルのパス
    • PROJECT_ID: プロジェクト ID

kubectl

kubectl で Config Sync をインストールする場合は、構成する前に Operator をデプロイする必要があります。Operator は、Kubernetes クラスタで Config Sync を管理するコントローラです。

Operator のデプロイ

すべての前提条件を満たしていることを確認したら、YAML マニフェストをダウンロードして適用し、Operator をデプロイします。

  1. 次のコマンドを使用して、Operator CustomResourceDefinition(CRD)の最新バージョンをダウンロードします。特定のバージョンをダウンロードするには、ダウンロードをご覧ください。

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
    
  2. CRD を適用します。

    kubectl apply -f config-management-operator.yaml

このコマンドが失敗した場合は、トラブルシューティングをご覧ください。

Anthos Config Management の構成

Anthos Config Management の動作を構成するには、ConfigManagement CustomResource の構成ファイルを作成し、kubectl apply コマンドを使用して適用します。

  1. config-management.yaml を作成して、次の YAML をコピーします。

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # clusterName is required and must be unique among all managed clusters
      clusterName: CLUSTER_NAME
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

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

    • CLUSTER_NAME: この構成を適用する登録済みクラスタの名前
    • REPO: 真の同期ソースとして使用する Git リポジトリの URL。このフィールドは必須です。
    • BRANCH: 同期元となるリポジトリのブランチ。デフォルトは、メイン(マスター)ブランチです。
    • TYPE: 以下の SecretTypes のいずれかです。

      • none
      • ssh
      • cookiefile
      • token
      • gcenode
    • DIRECTORY: リポジトリ内で同期するポリシー階層の最上位のパス。デフォルトは、リポジトリのルート ディレクトリです。

    spec フィールドに追加できるフィールドの完全なリストについては、次の Git リポジトリの構成セクションをご覧ください。spec フィールド以外の構成の値を変更しないでください。

  2. kubectl apply コマンドを使用して構成を適用します。

    kubectl apply -f config-management.yaml
    

    クラスタごと、またはクラスタのタイプごとに別々の構成ファイルを作成しなければならない場合があります。適用するクラスタを指定するには、--context オプションを使用します。

    kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
    

    CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

インストールの確認

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

Console

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

    Anthos Config Management に移動

  2. [ステータス] 列を確認します。インストールに成功すると、ステータスは Synced になります。

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

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

gcloud

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

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

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

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

gcloud alpha container hub config-management apply

kubectl

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

正常にデプロイされた Config Sync は、kube-system 名前空間内で名前が config-management-operator で始まる Pod で実行されます。Pod が初期化されるまで少し時間がかかることがあります。

Pod が実行されていることを確認するには、次のコマンドを使用します。

kubectl -n kube-system get pods | grep config-management

Pod が実行されている場合、コマンドのレスポンスは次の例のようになります。

config-management-operator-6f988f5fdd-4r7tr 1/1 Running 0 26s

また、config-management-system 名前空間が存在することを確認することもできます。

kubectl get ns | grep 'config-management-system'

このコマンドの出力は、次の例のようになります。

config-management-system Active 1m

前の例のような出力が返されない場合は、ログを表示して原因を確認します。

kubectl -n kube-system logs -l k8s-app=config-management-operator

kubectl get events を使用して、Config Sync がなんらかのイベントを作成したかどうかを確認することもできます。

kubectl get events -n kube-system

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

Config Sync のバージョンのアップグレード

Anthos Config Management をアップグレードすると、Config Sync がアップグレードされます。

Anthos Config Management をアップグレードするには、Google Cloud Console または kubectl を使用します。アップグレードを行う前に、リリースノートで具体的な手順をご確認ください。

Console

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

    Anthos Config Management に移動

  2. アップグレードするクラスタを選択します。

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

  4. [クラスタの ACM 設定] をクリックします。

  5. [バージョン] プルダウンから、アップグレードするバージョンを選択します。

  6. [完了] をクリックします。

kubectl

登録されているクラスタごとに、以下のコマンドを実行します。

  1. 新しいバージョンの Anthos Config Management マニフェストと nomos コマンドをダウンロードします。

  2. Anthos Config Management マニフェストを適用します。

    kubectl apply -f config-management-operator.yaml
    

    このコマンドにより、Anthos Config Management イメージが更新されます。Kubernetes によって新しいバージョンが取得され、新しいバージョンを使用して Anthos Config Management Pod が再起動されます。Anthos Config Management が起動すると、新しいイメージにバンドルされたマニフェストのセットを適用する調整ループが実行されます。これにより、各コンポーネントの Pod が更新され、再起動されます。

  3. すべてのクライアントの nomos または nomos.exe コマンドを新しいバージョンに置き換えます。この変更により、nomos コマンドを実行して、登録済みのすべてのクラスタのステータスを確実に取得し、構成ファイルを検証できるようになります。

クラスタから Config Sync をアンインストールする

クラスタから Config Sync をアンインストールするには、次の手順を行います。これらの手順は、Config Sync で管理する必要がなくなったクラスタごとに行う必要があります。

Console

Anthos Config Management を無効にするには、次の手順を行います。

  1. Google Cloud Console で、Anthos の [機能] ページに移動します。

    Anthos の [機能] ページに移動

  2. [機能] の表の [構成管理] 行で、[詳細] をクリックします。[ステータス サマリー] ページが表示されます。

  3. [構成管理の無効化] をクリックします。確認ページが表示されます。

  4. 確認ページで [構成管理の無効化] をクリックします。

gcloud

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

gcloud alpha container hub config-management delete \
    --project=PROJECT_ID \
    --membership=CLUSTER_NAME

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

  • CLUSTER_NAME: この構成を削除する登録済みクラスタの名前
  • PROJECT_ID: プロジェクト ID

Config Sync のすべての構成とステータスを削除するには、次のコマンドを実行します。

gcloud alpha container hub config-management disable \
    --project=PROJECT_ID

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

kubectl

  1. クラスタから ConfigManagement オブジェクトを削除します。

    kubectl delete configmanagement --all
    

    このコマンドを実行すると、次の処理が行われます。

    • Config Sync によってクラスタに作成された ClusterRole と ClusterRoleBinding がクラスタからすべて削除されます。
    • Config Sync によってインストールされたアドミッション コントローラの構成がすべて削除されます。
    • config-management-system 名前空間の内容は、git-creds Secret を除いてすべて削除されます。Config Sync は、config-management-system 名前空間なしでは機能しません。Config Sync によって作成または変更された CustomResourceDefinition(CRD)は、それらが作成または変更されたクラスタからすべて削除されます。Config Sync の実行に必要な CRD は、Kubernetes の観点からは Config Sync をインストールしたユーザーが追加したものとみなされるため、削除されずに残ります。これらを削除する方法については、次のステップで説明します。
  2. この時点で、Operator はまだクラスタに存在しますが、単に存在するだけで何も行いません。Anthos clusters on VMware を使用している場合、手動では Operator を削除できません。

    GKE を使用していて、今後 Config Sync を使用しない場合は、次の手順で Config Sync をアンインストールします。

    1. 前の手順で ConfigManagement オブジェクトを削除した後、config-management-system 名前空間が空であることを確認します。kubectl -n config-management-system get all コマンドによって No resources found. が返されるまで待ちます。

    2. config-management-system 名前空間を削除します。

      kubectl delete ns config-management-system
      
    3. ConfigManagement CustomResourceDefinition を削除します。

      kubectl delete crd configmanagements.configmanagement.gke.io
      
    4. すべての Config Sync オブジェクトを kube-system 名前空間から削除します。

      kubectl -n kube-system delete all -l k8s-app=config-management-operator
      

トラブルシューティング

以下のセクションでは、Config Sync のインストールに関するトラブルシューティングについて説明します。

監査ログの使用

監査ログは有用なデバッグツールです。

Cloud Console または gcloud コマンドライン ツールを使用して Config Sync をインストールした場合は、次の手順で監査ログを使用して、Config Sync の調査を行います。

Console

  1. GKE Connect / Hub API 監査ログを有効にします。

    1. Cloud Console で IAM の [監査ログ] ページに移動します。

      [監査ログ] ページに移動

    2. 表で [GKE Connect / Hub API] チェックボックスをオンにします。

    3. 次のチェックボックスをオンにします。

      • 管理読み取り
      • データ読み取り
      • データ書き込み
    4. [保存] をクリックします。

  2. [ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] ページに移動

  3. [クエリビルダー] テキスト ボックスに次のフィルタを追加します。

    resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
    
  4. [実行] をクリックします。

  5. [クエリ結果] セクションで、エントリを選択してイベントの詳細を確認します。

CPU の不足

kubectl get events の出力に、タイプが FailedScheduling のイベントが含まれる場合があります。このイベントは次のようになります。

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

このエラーを修正するには、次のいずれかのオプションを選択します。

  • 既存の GKE ノードプールにノードを追加する。
  • より大きなノードでノードプールを作成する。

エラー: 追加の権限を付与しようとしている

config-management-operator.yaml ファイルを適用する際に次のエラーが発生した場合は、インストールに必要な権限が不足している可能性があります。

Error from server (Forbidden): error when creating "config-management-operator.yaml": clusterroles.rbac.authorization.k8s.io "config-management-operator" is forbidden: attempt to grant extra privileges: [...] ruleResolutionErrors=[]

必要な権限があることを確認するには、権限の準備をご覧ください。

有効であるが正しくない ConfigManagement オブジェクト

YAML または JSON 構文エラーに起因しない ConfigManagement オブジェクトの問題によってインストールが失敗した場合、ConfigManagement オブジェクトはクラスタでインスタンス化されますが、正しく動作しない可能性があります。この場合、nomos status コマンドを使用して ConfigManagement オブジェクトのエラーを確認できます。

問題のない有効なインストールのステータスは、PENDING または SYNCED になります。

無効なインストールのステータスは NOT CONFIGURED であり、次のいずれかのエラーが表示されます。

  • missing git-creds Secret
  • missing required syncRepo field
  • git-creds Secret is missing the key specified by secretType

問題を解決するには、構成エラーを修正してください。エラーのタイプに応じて、ConfigManagement マニフェストをクラスタに再適用する必要があります。

ユーザーが git-creds Secret を作成するのを忘れたために問題が発生した場合、Secret を作成すると Config Sync で即時にそれが検出されるため、構成を再適用する必要はありません。

config-management.yaml のフィールド

以降のセクションでは、config-management.yaml ファイルで設定可能なフィールドについて説明します。

Git リポジトリの構成

キー 説明
spec.git.syncRepo 真の情報源として使用する Git リポジトリの URL。必須。
spec.git.syncBranch 同期元となるリポジトリのブランチ。デフォルト: master
spec.git.policyDir 同期するリポジトリの最上位レベルを表す Git リポジトリ内のパス。デフォルトはリポジトリのルート ディレクトリです。
spec.git.syncWait 連続する同期の時間間隔(秒)。デフォルトは 15 です。
spec.git.syncRev チェックアウトする Git リビジョン(タグまたはハッシュ)。デフォルトは HEAD です。
spec.git.secretType Git リポジトリへのアクセスのために構成された Secret のタイプ。sshcookiefiletokengcenodenone のいずれか。必須。
spec.sourceFormat unstructured に設定すると、非階層リポジトリが構成されます。デフォルト: hierarchy

Git リポジトリのプロキシ構成

組織のセキュリティ ポリシーでトラフィックを HTTP(S) プロキシ経由でルーティングする必要がある場合は、プロキシの URI を使用して Git ホストと通信するように Config Sync を構成できます。

キー 説明
spec.git.proxy.httpProxy Git リポジトリへのアクセスに使用される HTTP_PROXY 環境変数を定義します。
spec.git.proxy.httpsProxy Git リポジトリへのアクセスに使用される HTTPS_PROXY 環境変数を定義します。

httpProxyhttpsProxy の両方のフィールドが指定されている場合、httpProxy は無視されます。

ConfigManagement オブジェクトの動作に関する構成

キー 説明
spec.clusterName クラスタをグループ化するために ClusterSelector によって使用されるクラスタのユーザー定義名。これは Config Sync インストール内で一意です。Cloud Console でこのフィールドを構成することはできません。

統合の構成

これらのフィールドにより、Config Connector および Policy Controller との統合が可能になります。

キー 説明
spec.configConnector.enabled true の場合、Config Connector をインストールします。デフォルトは false です。
spec.policyController.enabled true の場合、Policy Controller を有効にします。デフォルトは false です。
spec.policyController.templateLibraryInstalled true の場合、制約テンプレート ライブラリをインストールします。デフォルトは true です。

次のステップ