Anthos Config Management のインストール

Anthos Config Management は、クラスタオペレータが Git リポジトリに保存されたファイル（構成ファイルと呼ばれる）を使用して Kubernetes の Deployment を管理する機能です。

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

Anthos Config Management コンポーネントをインストールする方法の手順については、Config Connector のインストール、Hierarchy Controller のインストール、Policy Controller のインストールをご覧ください。

始める前に

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

ローカル環境の準備

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

プロジェクトで Anthos API を有効にします。
Console
Google Cloud Console で、[Anthos API] ページに移動します。

Anthos API ページに移動
- [有効にする] をクリックします。
gcloud
次のコマンドを実行します。
```
gcloud services enable anthos.googleapis.com
```
この手順で使用する gcloud、gsutil、kubectl、nomos コマンドを備えた Cloud SDK をインストールして初期化します。Cloud Shell を使用する場合、Cloud SDK がプリインストールされています。
kubectl は、デフォルトでは Cloud SDK によってインストールされません。kubectl をインストールするには、次のコマンドを使用します。
```
gcloud components install kubectl
```
Anthos Config Management のコンポーネントをダウンロードできるように、gcloud auth login コマンドを使用して Google Cloud に対する認証を行います。

クラスタを準備する

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

クラスタが Anthos のサポートされているプラットフォームとバージョンであることを確認します。
Connect を使用して Anthos 環境にクラスタを登録します。プロジェクトの Environ は、Google Cloud 外のクラスタを含む Anthos の一部として、クラスタとそのワークロードを表示して管理するために統合された方法を提供します。Anthos の料金は、登録済みのクラスタにのみ適用されます。

権限の準備

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

Console

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

gcloud

kubectl

GKE を使用している場合、Anthos Config Management をインストールする 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

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

Anthos の機能ページに移動
[Config Management] の行で、[有効にする] をクリックします。
確認ウィンドウで、[Config Managementの有効化] をクリックします。

gcloud

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

 gcloud alpha container hub config-management enable

Anthos Config Management のインストール

以下のセクションでは、Anthos Config Management にリポジトリへのアクセスを許可します。アクセスを許可したら、インストールを構成します。

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

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

リポジトリが読み取り専用権限に対する認証を必要としない場合は、Anthos Config Management の構成に進み、secretType を none に設定します。たとえば、ログインせずにウェブインターフェースを使用してリポジトリをブラウジングできる場合や、git clone を使用して認証情報を提供したり、保存されている認証情報を使用したりすることなく、リポジトリのクローンをローカルに作成することができる場合は認証は必要ありません。この場合、git-creds Secret を作成する必要はありません。

ほとんどのユーザーは、リポジトリへの読み取りアクセスが制限されているため、認証情報を作成する必要があります。Anthos Config Management は、次の認証メカニズムをサポートしています。

SSH 認証鍵ペア
cookiefile
トークン
Google サービスアカウント（Google Cloud Source Repositories のリポジトリのみ）

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

SSH 認証鍵ペア

SSH 認証鍵ペアは、公開鍵と秘密鍵の 2 つのファイルで構成されています。公開鍵の拡張子は通常 .pub です。

SSH 認証鍵ペアを使用するには、次の手順を行います。

Anthos Config Management が Git リポジトリに対する認証を行えるように、SSH 認証鍵ペアを作成します。この手順は、リポジトリをクローン化したり、またはリポジトリの内容を読み取るために、リポジトリに対して認証しなければならない場合に必要となります。セキュリティ管理者から鍵ペアが提供される場合、この手順は省略します。自社のセキュリティとコンプライアンスの要件に応じて、すべてのクラスタに対して単一の鍵ペアを使用するか、クラスタごとに 1 つの鍵ペアを使用するかを選びます。

次のコマンドは 4,096 ビットの RSA 鍵を作成します。これよりビット数の少ない鍵はおすすめできません。
```
ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME
```
以下を置き換えます。
- GIT_REPOSITORY_USERNAME: Anthos Config Management がリポジトリに対する認証に使用するユーザー名。
- /path/to/KEYPAIR_FILENAME: 鍵ペアへのパスを追加します。
GitHub などのサードパーティ Git リポジトリホストを使用している場合や、Cloud Source Repositories でサービスアカウントを使用する場合は、別のアカウントを使用することをおすすめします。

注: パスフレーズなしで SSH 認証鍵を作成する必要があります。 Anthos Config Management は SSH 認証鍵のパスフレーズをサポートしていません。
新しく作成した公開鍵を認識するようにリポジトリを構成します。ご使用の Git ホスティングプロバイダのドキュメントをご覧ください。よく使われる Git ホスティングプロバイダの手順へのリンクを以下に示します。
- Cloud Source Repositories
- Bitbucket
- GitHub。単一の GitHub リポジトリへの読み取り専用アクセスを提供するために、個別のデプロイキーを作成することをおすすめします。
- GitLab

秘密鍵をクラスタ内の新しい 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 拡張子は付けない）に置き換えます。

ローカルディスクから秘密鍵を削除するか、秘密鍵を保護します。

cookiefile

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

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

cookiefileを作成して取得したら、それをクラスタの新しいシークレットに追加します。
```
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 は、適切なパスとファイル名に置き換えます。
コンテンツが引き続きローカルで必要な場合は、cookiefileのコンテンツを保護します。必要でなければ、トークンを削除します。

トークン

組織で SSH 認証鍵の使用が許可されていない場合は、トークンを使用することをおすすめします。Anthos Config Management では、GitHub の個人のアクセストークン（PAT）または Bitbucket のアプリパスワードをトークンとして使用できます。

トークンを使用して Secret を作成するには、次の手順に従います。

GitHub または Bitbucket を使用してトークンを作成します。
- GitHub:PAT を作成します。トークンに repo スコープを付与し、非公開リポジトリから読み取れるようにします。PAT を GitHub アカウントにバインドするため、マシンユーザーを作成し、PAT をそのマシンユーザーにバインドすることをおすすめします。
- Bitbucket:アプリパスワードを作成します。
トークンを作成して取得したら、それをクラスタの新しいシークレットに追加します。
```
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: 前の手順で作成したトークン
ローカルでのトークンが必要な場合は、トークンを保護します。必要でなければ、トークンを削除します。

Google サービスアカウント

リポジトリが Cloud Source Repositories にある場合、secretType: gcenode を使用して、管理しているクラスタと同じプロジェクト内のリポジトリに Anthos Config Management へのアクセス権を付与できます。

要件

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

クラスタ内のノードのアクセススコープには、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 Management Operator を構成するときに、Cloud Source Repositories で目的のリポジトリの URL に spec.git.syncRepo を設定します。

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

すべてのリポジトリを一覧表示します。
```
gcloud source repos list
```

出力から、使用するリポジトリから URL をコピーします。

REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr

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 を使用するには追加の手順が必要です。上記の手順を完了した後、Anthos Config Management の構成（次のセクションで行う）は、Kubernetes サービスアカウントと Google サービスアカウントの間のIAM ポリシーバインディングを作成します。Anthos Config Management を初めて構成するまで、Kubernetes サービスアカウントは作成されません。

このバインディングにより、Anthos Config Management 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_ID-compute@developer.gserviceaccount.com

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

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

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

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

Anthos Config Management の構成

Google Cloud Console では、インストールプロセスをガイドし、さまざまな手順を自動化します。gcloud コマンドラインツールまたは kubectl コマンドを使用してインストールを完了することもできます。

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

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

Console

Cloud Console で、[Anthos Config Management] ページに移動します。

Anthos Config Management ページに移動
登録済みクラスタを選択して、[構成] をクリックします。
[ACM の Git リポジトリ認証] セクションで、次のいずれかのオプションを選択します。
- なし
- SSH
- cookiefile
- トークン
- Google Cloud Repository
まだ行っていない場合は、Anthos Config Management に Git への読み取り専用アクセス権を付与します。
[続行] をクリックします。
[クラスタ用の ACM 設定] セクションで、次の操作を行います。
1. [バージョン] フィールドで、Anthos Config Management のバージョンを選択します。
2. [Config Sync を有効にする] チェックボックスをオンにします。
  1. [URL] フィールドに、信頼できる参照元として使用する Git リポジトリの URL を追加します。この欄は必須です。
  2. [ブランチ] フィールドに、同期元のリポジトリのブランチを追加します。デフォルトは、メイン（マスター）ブランチです。この欄は必須です。
  3. [タグ / commit] で、Git のリビジョン（タグまたはハッシュ）を追加してチェックアウトします。デフォルトは HEAD です。
  4. [ポリシーのディレクトリ] フィールドで、同期するポリシー階層の最上部にリポジトリ内のパスを追加します。デフォルトは、リポジトリのルートディレクトリです。
  5. [同期の待機時間] フィールドで、連続する同期の時間間隔を秒単位で追加します。デフォルト値は 15 秒です。
  6. [Git proxy] フィールドに、Git リポジトリとの通信時に使用する HTTPS プロキシの URL を入力します。これは省略可能なフィールドであり、空白のままにすると、プロキシは使用されません。
  7. [ソース形式] フィールドで、リポジトリに階層を持たせるか、非構造化かを選択します。
[完了] をクリックします。Anthos Config Management ページに戻ります。数分後、構成したクラスタの横のステータス列に Synced と表示されます。Error が表示された場合は、Error をクリックして詳細を表示します。

gcloud

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 フィールド以外の構成の値を変更しないでください。
次の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 を使用して Anthos Config Management をインストールする場合、Operator を構成する前にデプロイする必要があります。Operator は、Kubernetes クラスタで Anthos Config Management を管理するコントローラです。

Operator のデプロイ

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

次のコマンドを使用して、Operator CustomResourceDefinition（CRD）の最新バージョンをダウンロードします。特定のバージョンをダウンロードするには、ダウンロードをご覧ください。
```
gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
```

CRD を適用します。

kubectl apply -f config-management-operator.yaml

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

Anthos Config Management の構成

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

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: リポジトリ内の、同期するポリシー階層の最上位へのパス。デフォルトは、リポジトリのルートディレクトリです。
注: config-management.yaml を Git リポジトリに保存する場合は、policyDir をサブディレクトリに設定し、そのサブディレクトリ内にすべての構成ファイルを配置する必要があります。config-management.yaml ファイルは policyDir サブディレクトリに配置しないでください。

spec フィールドに追加できるフィールドの完全なリストについては、次の Git リポジトリの構成セクションをご覧ください。spec フィールド以外の構成の値を変更しないでください。
kubectl apply コマンドを使用して構成を適用します。
```
kubectl apply -f config-management.yaml
```
クラスタごと、またはクラスタのタイプごとに別々の構成ファイルを作成しなければならない場合があります。適用するクラスタを指定するには、--context オプションを使用します。
```
kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
```
CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

インストールの確認

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

Console

Cloud Console で、[Anthos Config Management] ページに移動します。

Anthos Config Management ページに移動
[ステータス] 列を確認します。インストールに成功すると、ステータスは Synced になります。

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

探索するクラスタを選択します。[クラスタの詳細] ページが表示されます。このページでは、クラスタの詳細と Anthos Config Management のインストールの詳細を確認できます。

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

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

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

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

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

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

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 を使用して、Anthos Config Management によってイベントが作成されているかどうかを確認することもできます。

kubectl get events -n kube-system

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

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

このセクションでは、新しいバージョンにアップグレードする一般的な手順を説明します。アップグレードを行う前に、リリースノートで具体的な手順をご確認ください。

Console

Cloud Console で、[Anthos Config Management] ページに移動します。

Anthos Config Management ページに移動
アップグレードするクラスタを選択します。
[設定] をクリックします。
[クラスタの ACM の設定] をクリックします。
[バージョン] プルダウンから、アップグレードするバージョンを選択します。
[完了] をクリックします。

kubectl

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

新しいバージョンの Anthos Config Management マニフェストと nomos コマンドをダウンロードします。
Anthos Config Management マニフェストを適用します。
```
kubectl apply -f config-management-operator.yaml
```
このコマンドにより、Anthos Config Management イメージが更新されます。Kubernetes によって新しいバージョンが取得され、新しいバージョンを使用して Anthos Config Management Pod が再起動されます。Anthos Config Management が起動すると、新しいイメージにバンドルされているマニフェストのセットを適用する調整ループが実行されます。これにより、各コンポーネントの Pod が更新され、再起動されます。
すべてのクライアントの nomos または nomos.exe コマンドを新しいバージョンに置き換えます。この変更により、nomos コマンドによって、登録されたすべてのクラスタのステータスを確実に取得し、それらの構成を検証できるようになります。

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

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

Console

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

Anthos の機能ページに移動
[機能] の表の [Config Management] 行で、[詳細] をクリックします。[ステータスサマリー] ページが表示されます。
[config managementを無効にする] をクリックします。確認ページが表示されます。
確認ページで [config managementを無効にする] をクリックします。

gcloud

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

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

以下を置き換えます。

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

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

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

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

kubectl

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

GKE を使用していて、Anthos Config Management を今後使用しないことに決めた場合は、Anthos Config Management をアンインストールできます。手順は次のとおりです。
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. kube-system 名前空間からすべての Anthos Config Management オブジェクトを削除します。
```
kubectl -n kube-system delete all -l k8s-app=config-management-operator
```

トラブルシューティング

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

監査ログの使用

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

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

コンソール

GKE Connect/Hub API 監査ログを有効にします。
1. Cloud Console で IAM [監査ログ] ページに移動します。
  
  [監査ログ] ページに移動
2. 表中の [GKE Connect/Hub API] チェックボックスをオンにします。
3. 次のチェックボックスをオンにします。
  - 管理読み取り
  - データ読み取り
  - データ書き込み
4. [保存] をクリックします。
[ログエクスプローラ]ページに移動

ログエクスプローラページに移動
[クエリビルダー] テキストボックスに、次のフィルタを追加します。
```
resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
```
[実行] をクリックします。
[クエリ結果] セクションで、エントリを選択してイベントの詳細を確認します。

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 を構成すると、Anthos Config Management によって Secret が検出され、構成を再適用する必要はありません。

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 リポジトリへのアクセスのために構成されたシークレットのタイプ。`ssh`、`cookiefile`、`token`、`gcenode`、`none` のいずれか。必須。
`spec.sourceFormat`	`unstructured` に設定すると、非階層リポジトリが構成されます。デフォルト: `hierarchy`

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

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

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

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

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

キー	説明
`spec.clusterName`	クラスタをグループ化するために ClusterSelector によって使用される、クラスタのユーザー定義名。Anthos Config Management のインストール内で一意にする必要があります。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` です。

次のステップ

Anthos Config Management を構成するための gcloud コマンドの詳細をご覧ください。
クイックスタートを試す。
構成ファイルを作成する方法を確認する。
nomos コマンドを使用する。

Anthos Config Management のインストール

始める前に

ローカル環境の準備

Console

gcloud

クラスタを準備する

権限の準備

Console

gcloud

kubectl

Anthos Config Management の有効化

Console

gcloud

Anthos Config Management のインストール

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

SSH 認証鍵ペア

cookiefile

トークン

Google サービス アカウント

要件

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

Workload Identity での Cloud Source Repositories の使用

Anthos Config Management の構成

Console

gcloud

kubectl

Operator のデプロイ

Anthos Config Management の構成

インストールの確認

Console

gcloud

kubectl

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

Console

kubectl

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

Console

gcloud

kubectl

トラブルシューティング

監査ログの使用

コンソール

CPU の不足

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

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

config-management.yaml のフィールド

Git リポジトリの構成

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

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

統合の構成

次のステップ

Google サービスアカウント