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] ページに移動します。
- [有効にする] をクリックします。
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
Anthos Config Management をインストールする Google Cloud ユーザーには、Hub API を使用してクラスタを管理するために GKE Hub 管理者(roles/gkehub.admin
)のロールが必要です。
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 の [機能] ページに移動します。
[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 でサービス アカウントを使用する場合は、別のアカウントを使用することをおすすめします。
新しく作成した公開鍵を認識するようにリポジトリを構成します。 ご使用の 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
: 組織のプロジェクト IDPROJECT_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] ページに移動します。
登録済みクラスタを選択して、[構成] をクリックします。
[ACM の Git リポジトリ認証] セクションで、次のいずれかのオプションを選択します。
- なし
- SSH
- cookiefile
- トークン
- Google Cloud Repository
まだ行っていない場合は、Anthos Config Management に Git への読み取り専用アクセス権を付与します。
[続行] をクリックします。
[クラスタ用の ACM 設定] セクションで、次の操作を行います。
- [バージョン] フィールドで、Anthos Config Management のバージョンを選択します。
- [Config Sync を有効にする] チェックボックスをオンにします。
- [URL] フィールドに、信頼できる参照元として使用する Git リポジトリの URL を追加します。この欄は必須です。
- [ブランチ] フィールドに、同期元のリポジトリのブランチを追加します。デフォルトは、メイン(マスター)ブランチです。この欄は必須です。
- [タグ / commit] で、Git のリビジョン(タグまたはハッシュ)を追加してチェックアウトします。デフォルトは
HEAD
です。 - [ポリシーのディレクトリ] フィールドで、同期するポリシー階層の最上部にリポジトリ内のパスを追加します。デフォルトは、リポジトリのルート ディレクトリです。
- [同期の待機時間] フィールドで、連続する同期の時間間隔を秒単位で追加します。デフォルト値は 15 秒です。
- [Git proxy] フィールドに、Git リポジトリとの通信時に使用する HTTPS プロキシの URL を入力します。これは省略可能なフィールドであり、空白のままにすると、プロキシは使用されません。
- [ソース形式] フィールドで、リポジトリに階層を持たせるか、非構造化かを選択します。
[完了] をクリックします。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
: リポジトリ内の、同期するポリシー階層の最上位へのパス。デフォルトは、リポジトリのルート ディレクトリです。
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] ページに移動します。
[ステータス] 列を確認します。インストールに成功すると、ステータスは
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] ページに移動します。
アップグレードするクラスタを選択します。
[設定] をクリックします。
[クラスタの 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 の [機能] ページに移動します。
[機能] の表の [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 をアンインストールできます。手順は次のとおりです。
前の手順で ConfigManagement オブジェクトを削除した後、
config-management-system
名前空間が空であることを確認します。kubectl -n config-management-system get all
コマンドによってNo resources found.
が返されるまで待ちます。config-management-system
名前空間を削除します。kubectl delete ns config-management-system
ConfigManagement CustomResourceDefinition を削除します。
kubectl delete crd configmanagements.configmanagement.gke.io
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 監査ログを有効にします。
Cloud Console で IAM [監査ログ] ページに移動します。
表中の [GKE Connect/Hub API] チェックボックスをオンにします。
次のチェックボックスをオンにします。
- 管理読み取り
- データ読み取り
- データ書き込み
[保存] をクリックします。
[ログ エクスプローラ]ページに移動
[クエリビルダー] テキスト ボックスに、次のフィルタを追加します。
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
コマンドを使用する。