Config Connector のトラブルシューティング

このページでは、Config Connector のトラブルシューティングに使用できる解決方法と、プロダクトの使用時に発生する可能性のある一般的な問題ついて説明します。

Config Connector のステータスと条件を確認する

Config Connector のバージョンを確認する

インストールされている Config Connector のバージョンを取得するには、次のコマンドを実行します。使用したい機能やリソースが実行中のバージョンでサポートされていることを確認するには、リリースノートを照らし合わせます。

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

リソースのステータスとイベントを確認する

通常、Config Connector リソースの問題は、Kubernetes でのリソースの状態の調査によって特定できます。リソースのステータスとイベントの確認は、Config Connector がリソースの調整に失敗した場合に、調整の失敗理由を特定するのに特に役立ちます。

Config Connector が動作していることを確認する

Config Connector が動作していることを確認するには、すべての Pod が READY であることを確認します。

kubectl get pod -n cnrm-system

出力例:

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

Config Connector を namespaced モードにインストールすると、対象の名前空間内の Config Connector リソースの管理を担当する名前空間ごとに 1 つのコントローラ（cnrm-controller-manager）Pod が作成されます。

次のコマンドを実行して、特定の名前空間を担当するコントローラ Pod のステータスを確認できます。

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

NAMESPACE は Namespace の名前に置き換えます。

コントローラのログを確認する

コントローラ Pod は、Config Connector リソースの調整に関する情報とエラーをログに記録します。

コントローラ Pod のログを確認するには、次のコマンドを実行します。

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

Config Connector が namespaced-mode にインストールされている場合に、先ほどのコマンドによって、すべてのコントローラ Pod のログが表示されます。次のコマンドを実行すると、特定の名前空間のコントローラ Pod のログを確認できます。

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

NAMESPACE は Namespace の名前に置き換えます。

Config Connector のログを検査してクエリを実行する方法を確認する。

リソースを放棄して取得します。

場合によっては、リソースの変更不可フィールドを更新する必要があります。変更不可のフィールドは編集できないため、リソースを破棄してから取得する必要があります。

1. Config Connector リソースの YAML 構成を更新して、cnrm.cloud.google.com/deletion-policy アノテーションを abandon に設定します。
2. 更新された YAML 構成を適用して Config Connector リソースの削除ポリシーを更新します。
3. Config Connector リソースを放棄します。
4. YAML 構成で変更する必要がある不変フィールドを更新します。
5. 更新された YAML 構成を適用して、放棄されたリソースを取得します。

問題の種類に応じてトラブルシューティングを行う

次の表を使用して、症状の種類に基づいて問題をトラブルシューティングします。

問題の種類	一般的な問題
調整	リソースが 5 ～ 15 分ごとに更新される リソースにステータスがない KNV2005: syncer がリソースを過剰に更新する Config Connector によってリソースが削除される コントローラ Pod の OOMKilled
削除	Namespace の削除が Terminating のままになる プロジェクトが削除された後に DeleteFailed と表示されたまま停止しているリソースの削除
権限	Compute Engine メタデータが定義されていない エラー 403: リクエストに十分な認証スコープがありません 403 Forbidden: 呼び出し元に権限がありません エラー 403: 呼び出し元に IAM 権限がありません IAMPolicy、IAMPartialPolicy、IAMPolicyMember による更新エラー
インストールとアップグレード	バージョンが Config Connector アドオンのインストールでサポートされていない failed calling webhook PodSecurityPolicy が原因でアップグレードできない
構成	変更不可のフィールドは変更できません 「Foo」という種類に一致する結果が見つからない ラベルが Google Cloud リソースに伝播されない リソース名で特殊文字を使用したことによるエラー リソース仕様からフィールドを削除できない

調整

次のセクションでは、Config Connector によるリソースの調整に関連する一般的な問題について説明します。

リソースが 5～15 分ごとに更新される

症状

Config Connector リソースが 5 ～ 10 分ごとに UpToDate ステータスから Updating ステータスに切り替わります。

原因

Config Connector がリソースの望ましい状態と実際の状態の間に意図しない差分を検出し、Config Connector がリソースを常に更新している可能性があります。

解決策

まず、Config Connector または Google Cloud リソースを常時変更している外部システムがないことを確認します（CI/CD パイプライン、カスタム コントローラ、cron ジョブなど）。

動作が外部システムによるものでない場合は、 Google Cloud が Config Connector リソース内で指定された値を変更しているかどうかを確認します。たとえば、 Google Cloud がフィールド値の形式（大文字の使用など）を変更し、これにより、リソースの目的の状態と実際の状態の差異が生じる場合があります。

REST API（ContainerCluster 向けなど）または Google Cloud CLI を使用して、 Google Cloud リソースの状態を取得します。次に、その状態を Config Connector リソースと比較します。値が一致しないフィールドを探して、一致するように Config Connector リソースを更新します。具体的には、 Google Cloudによって再フォーマットされた値を探します。たとえば、GitHub の問題 #578 と #294 をご覧ください。

Config Connector とGoogle Cloud リソースモデルは異なるため、これは完全な方法ではありませんが、意図しない差分のほとんどを特定できます。

問題を解決できない場合は、その他のヘルプをご覧ください。

リソースにステータスがない

症状

リソースに status フィールドがない。

原因

Config Connector が正しく実行されていない可能性があります。

解決策

Config Connector が動作していることを確認します。

KNV2005: syncer がリソースを過剰に更新する

症状

Config Sync を使用していて、次のように Config Connector リソースに KNV2005 エラーが表示される。

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

原因

Config Sync と Config Connector のリソースが競合している可能性があります。

Config Sync と Config Connector は、同じフィールドを異なる値に更新し続けると、リソース間で「競合」発生すると言われています。一方の更新では、別のリソースがトリガーされてリソースが更新され、他のリソースではリソースの操作と更新などが行われます。この処理が無限に繰り返されます。

ほとんどのフィールドでの競合は問題ではありません。Config Sync で指定されたフィールドは、Config Connector によって変更されません。同様に、Config Sync で指定されず、Config Connector によってデフォルトで設定されるフィールドは、Config Sync で無視されます。したがって、ほとんどのフィールドでは、Config Sync と Config Connector が同じフィールドを更新する必要はありません。

例外はリスト フィールドです。Config Connector がオブジェクト フィールドのサブフィールドをデフォルトに設定する場合と同様に、Config Connector は、リスト内のオブジェクトのサブフィールドもデフォルトに設定できます。ただし、Config Connector リソースのリスト フィールドはアトミックであるため、サブフィールドのデフォルトはリストの値全体を変更するとみなされます。

したがって、Config Sync によってリスト フィールドが設定され、Config Connector がそのリスト内のサブフィールドはデフォルトで設定されると、Config Sync と Config Connector に競合が発生します。

解決策

この問題を回避するには、次のオプションがあります。

1. Config Connector がリソースを設定しようとするものと一致するように、Config Sync リポジトリのリソース マニフェストを更新します。

   これを行う方法の一つは、構成の同期を一時的に停止し、Config Connector がリソースの調整を完了するのを待ってから、Kubernetes API サーバー上のリソースと一致するようにリソース マニフェストを更新することです。

2. アノテーションを client.lifecycle.config.k8s.io/mutation を ignore に設定して、Kubernetes API サーバーでのリソースの更新に Config Sync が反応しないようにします。Config Sync でオブジェクトのミューテーションを無視させる方法をご覧ください。

3. リソースのアノテーション cnrm.cloud.google.com/state-into-spec を absent に設定して、Config Connector がリソースの仕様を完全に更新しないようにします。このアノテーションは、すべてのリソースでサポートされているわけではありません。ご自身のリソースがアノテーションをサポートしているかどうかを確認するには、対応するリソースのリファレンス ページをご覧ください。 アノテーションの詳細

Config Connector によってリソースが削除される

症状

クラスタからリソースが削除され、Config Connector によって削除された可能性がある。

原因

Config Connector は、外部の原因がなければリソースを削除することはありません。たとえば、Argo CD などの構成管理ツールや、カスタマイズされた API クライアントを使用して kubectl delete を実行すると、リソースが削除される可能性があります。

よくある誤解は、Config Connector が主導してクラスタ内の一部のリソースを削除するというものです。たとえば、Config Connector を使用している場合、Config Connector コントローラ マネージャーからコンテナ ログメッセージまたは Kubernetes クラスタ監査ログのいずれかに、特定のリソースに対する削除リクエストが届いていることに気づきます。これらの削除リクエストは、外部トリガーの結果であり、Config Connector は削除リクエストを調整しようとしているのです。

解決策

リソースが削除された理由を特定するには、対応するリソースに送信された最初のリクエストを調べる必要があります。詳しく調べるには、Kubernetes クラスタの監査ログを確認することをおすすめします。

たとえば、GKE を使用している場合は、GKE クラスタ監査ログに関して、Cloud Logging を使用してクエリを実行できます。たとえば、名前空間 bar の foo という名前の BigQueryDataset リソースに対する最初の削除リクエストを検索するには、次のようなクエリを実行します。

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/bar/bigquerydatasets/foo"

このクエリを使用すると、最初のリクエストを検索し、その削除ログ メッセージの authenticationInfo.principalEmail を確認して、削除の原因を特定できます。

コントローラ Pod の OOMKilled

症状

Config Connector コントローラ Pod に OOMKilled エラーが表示されます。Pod のステータスは OOMKilled または Terminating と表示されることがあります。

原因

許容範囲を超えるメモリを使用したため、コンテナまたは Pod 全体が停止しました。これは、kubectl describe コマンドを実行して確認できます。

kubectl describe pod POD_NAME -n cnrm-system

POD_NAME は、トラブルシューティングを行う Pod に置き換えます。

さらに、Pod のイベントログを調査すると、OOM 関連のイベントが発生したことが判明する場合があります。

解決策

この問題に対処するには、ControllerResource カスタム リソースを使用して、Pod のメモリ リクエストとメモリ上限を増やします。

削除

次のセクションでは、Config Connector との競合を引き起こす可能性のある、ユーザーが開始した削除オペレーションに関連する一般的な問題について説明します。

Namespace の削除が「終了しています」と表示されたまま停止している

症状

Namespace の削除が Terminating ステージで停止しています。

原因

この問題は、Config Connector を名前空間モードでインストール済みであり、対象の名前空間内のすべての Config Connector リソースが削除される前に名前空間の ConfigConnectorContext が削除された場合に発生する可能性があります。Namespace の ConfigConnectorContext が削除されると、その Namespace の Config Connector は無効になり、その Namespace の残りの Config Connector リソースが削除できなくなります。

解決策

この問題を解決するには、強制クリーンアップを実行した後で、基盤となる Google Cloud リソースを手動で削除する必要があります。

この問題を将来にわたって軽減するには、その名前空間内のすべての Config Connector リソースが Kubernetes から削除された後でのみ、ConfigConnectorContext を削除します。ConfigConnectorContext が最初に削除される可能性があるため、対象の前空間内のすべての Config Connector リソースを削除する前に、名前空間全体を削除することは回避してください。

プロジェクトが削除された後に「DeleteFailed」と表示されたまま停止しているリソースの削除

症状

Config Connector リソースの削除が DeleteFailed ステータスで失敗します。

原因

この問題は、リソースの前に Google Cloud プロジェクトが削除された場合に発生する可能性があります。

解決策

この問題を解決するには、Google Cloudでプロジェクトを復元して、Config Connector が Kubernetes から残りの子リソースを削除できるようにします。または、強制クリーンアップを行うこともできます。

今後におけるこの問題を軽減するには、すべての子 Config Connector リソースが Kubernetes から削除された後にのみ、 Google Cloud プロジェクトを削除します。Project リソースと子の Config Connector リソースの両方を含む可能性がある名前空間全体を削除することは回避してください。Project リソースが最初に削除される可能性があります。

権限と認証

次のセクションでは、権限と認証に関連する一般的な問題について説明します。

Compute Engine メタデータが定義されていない

症状

Config Connector リソースのステータスが UpdateFailed になり、次のようなエラー メッセージが表示されます。

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

原因

Config Connector で使用されている IAM サービス アカウントが存在しない可能性があります。

解決策

この問題を解決するには、Config Connector で使用する IAM サービス アカウントが存在することを確認します。

この問題を将来にわたって軽減するには、Config Connector のインストール手順に沿って操作してください。

エラー 403: リクエストに十分な認証スコープがありません

症状

Config Connector リソースのステータスが UpdateFailed になっており、認証スコープが不十分であることが原因で 403 エラーを示すメッセージが表示されている。次のようなエラーが表示されます。

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

原因

GKE クラスタで Workload Identity Federation for GKE が有効になっていない可能性があります。

Workload Identity Federation for GKE が有効になっていないことを確認するには、次の操作を行います。

1. 次の Pod 構成を wi-test.yaml として保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: cnrm-system
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
     serviceAccountName: cnrm-controller-manager
   

   名前空間モードを使用して Config Connector をインストールした場合、serviceAccountName は cnrm-controller-manager-NAMESPACE になります。NAMESPACE は、インストール時に使用した名前空間に置き換えます。

2. GKE クラスタに Pod を作成します。

   kubectl apply -f wi-test.yaml
   

3. Pod でインタラクティブ セッションを開きます。

   kubectl exec -it workload-identity-test \
       --namespace cnrm-system \
       -- /bin/bash
   

4. ID を一覧表示します。

   gcloud auth list
   

5. 表示された ID が、リソースにバインドされた Google サービス アカウントと一致していることを確認します。

   Compute Engine のデフォルトのサービス アカウントが表示されている場合は、GKE クラスタまたはノードプール（あるいは、それらの両方）で Workload Identity Federation for GKE が有効になっていません。

6. インタラクティブ セッションを終了し、GKE クラスタから Pod を削除します。

   kubectl delete pod workload-identity-test \
       --namespace cnrm-system
   

解決策

この問題を解決するには、クラスタで Workload Identity Federation for GKE が有効になっていることを確認します。

引き続き同じエラーが表示される場合は、クラスタのノードプールで Workload Identity Federation for GKE を有効にしていることを確認してください。

403 Forbidden: 呼び出し元に権限がありません

症状

Config Connector リソースのステータスが UpdateFailed になり、Workload Identity Federation for GKE が原因で 403 エラーが発生したことを示すメッセージが表示されます。次のようなエラーが表示されます。

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

原因

Config Connector の Kubernetes サービス アカウントに、Workload Identity Federation for GKE ユーザーとして IAM サービス アカウントの権限を借用するための適切な IAM 権限がありません。

解決策

この問題を修正してその後の問題を軽減するには、Config Connector のインストール手順をご覧ください。

エラー 403: 呼び出し元に IAM 権限がありません

症状

Config Connector リソースのステータスが UpdateFailed になり、次のようなエラー メッセージが表示されます。

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

原因

Config Connector が使用している IAM サービス アカウントに、 Google Cloud リソースの管理に必要な IAM 権限がありません。

解決策

IAM サービス アカウントに適切な IAM 権限を付与した後も同じエラーが引き続き表示される場合は、リソースが正しいプロジェクト内に作成されていることを確認してください。Config Connector リソースの spec.projectRef フィールド（または、リソースが spec.projectRef フィールドをサポートしていない場合はリソースの cnrm.cloud.google.com/project-id アノテーション）を確認し、リソースが正しいプロジェクトを参照していることを確認します。リソース、名前空間のいずれによってもターゲット プロジェクトが指定されていない場合、Config Connector は名前空間の名前をプロジェクト ID として使用します。プロジェクトを対象にしたリソースのターゲット プロジェクトを構成する方法について詳細をご確認ください。

引き続き同じエラーが表示される場合は、Workload Identity Federation for GKE が GKE クラスタで有効になっているかどうかを確認します。

この問題を将来にわたって軽減するには、Config Connector のインストール手順に沿って操作してください。

IAMPolicy、IAMPartialPolicy、IAMPolicyMember による更新エラー

症状

サービス アカウントが存在しないため、400 エラーを示すエラー メッセージとともに UpdateFailed ステータスが表示されます。

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

原因

そのサービス アカウントに依存する IAMPolicy、IAMPartialPolicy、IAMPolicyMember リソースをクリーンアップする前に IAMServiceAccount Config Connector リソースを削除すると、Config Connector は調整中にそれらの IAM リソースで参照されるサービス アカウントを見つけることができなくなります。

解決策

この問題を解決するには、サービス アカウントを確認し、これらの IAM リソースに必要なサービス アカウントが削除されているかどうかを確認します。サービス アカウントが削除された場合は、関連する IAM Config Connector リソースもクリーンアップします。IAMPolicyMember については、リソース全体を削除します。IAMPolicy と IAMParitialPolicy については、削除されたサービス アカウントを含むバインディングのみを削除します。ただし、このようなクリーンアップでは、Google Cloud ロール バインディングはすぐに削除されません。削除されたサービス アカウントが保持されるため、 Google Cloud ロール バインディングは 60 日間保持されます。詳細については、 Google CloudIAM のドキュメントのサービス アカウントを削除するをご覧ください。

注: 削除中に問題が発生した場合は、強制クリーンアップが必要になることがあります。 Google CloudIAM バインディングをすぐに削除する場合は、gcloud を使用して基盤となる Google Cloud リソースを手動で削除する必要があります。

この問題を回避するには、参照先の IAMServiceAccount を削除する前に、必ず IAMPolicy、IAMPartialPolicy、IAMPolicyMember の Config Connector リソースをクリーンアップする必要があります。

ServiceIdentity リソースが IAM_SERVICE_NOT_CONFIGURED_FOR_IDENTITIES で失敗する

症状

ServiceIdentity リソースのステータスが UpdateFailed になり、次のようなエラー メッセージが表示されます。

Update call failed: error applying desired state: summary: Error creating Service Identity: googleapi: Error 400: com.google.api.tenant.error.TenantManagerException: IAM_SERVICE_NOT_CONFIGURED_FOR_IDENTITIES: ...

原因

このエラーは、指定されたリソースがオンデマンド サービス ID の作成をサポートしていないことを意味します。

解決策

ServiceIdentity リソースは、サポートされているサービスに対してのみサービス ID を生成できます。構成を適用する前に、サービスがオンデマンド サービス ID の作成をサポートしているかどうかを確認するには、次のコマンドを実行します。

gcloud beta services identity create --service SERVICE_NAME.googleapis.com

SERVICE_NAME は、サービスの名前（spanner など）に置き換えます。

コマンドが成功すると、Config Connector はそのサービスの ID を作成できます。コマンドが失敗した場合、Config Connector はそのサービスの ID を作成できません。

インストールとアップグレード

次のセクションでは、Config Connector のインストールまたはバージョンのアップグレードに関連する一般的な問題について説明します。

バージョンがConfig Connector アドオンのインストールでサポートされていない

症状

Config Connector アドオンを正常に有効にできない場合は、Node version 1.15.x-gke.x s unsupported というエラー メッセージが表示されます。

エラー メッセージは、Workload Identity Federation for GKE または GKE Monitoring が無効になっている場合にも表示されます。

原因

GKE クラスタのバージョンが要件を満たしていないか、必要な機能が無効になっている。

解決策

このエラーを解決するには、GKE クラスタのバージョンが、バージョンと機能の要件を満たしていることを確認します。Workload Identity Federation for GKE と GKE Monitoring が有効になっていることを確認します。

クラスタのすべての有効なバージョンを取得するには、次のコマンドを実行します。

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

ZONE を Compute Engine ゾーンに置き換えます。

要件を満たすリストからバージョンを選択します。

failed calling webhook

症状

Config Connector をアンインストールできず、次のようなエラーが表示されます。

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

原因

この問題は、Config Connector アドオンを使用して、Config Connector CRD を削除する前に Config Connector を無効にした場合に発生する可能性があります。

解決策

このエラーを解決するには、まず手動で Webhook を削除する必要があります。

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

その後、Config Connector のアンインストールを続行できます。

PodSecurityPolicy が原因でアップグレードできない

症状

Config Connector アドオンから手動インストールに切り替え、Config Connector を新しいバージョンにアップグレードした後、cnrm Pod の更新が失敗します。

原因

PodSecurityPolicies を使用すると、cnrm Pod の更新が妨げられる可能性があります。

PodSecurityPolicy がアップグレードを妨げていることを確認するには、config-connector-operator のイベントを確認して、次のようなエラーを探します。

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

解決策

この問題を解決するには、エラーで示されるアノテーションに対応する PodSecurityPolicy にアノテーションを指定する必要があります。前述の例では、アノテーションは seccomp.security.alpha.kubernetes.io です。

構成

次のセクションでは、リソースの構成に関する一般的な問題について説明します。

変更不可のフィールドを変更できない

Config Connector は、アドミッション時に変更不可のフィールドの更新を拒否します。

たとえば、kubectl apply で変更不可のフィールドを更新すると、コマンドが直後に失敗します。

つまり、継続的にリソースを再適用するツール（GitOps など）は、アドミッション エラーを処理しないとリソースの更新中にツール自身が動作を停止していることを検出する可能性があります。

Config Connector は変更不可のフィールドの更新を許可していないため、このような更新を実行する唯一の方法は、リソースを削除して再作成することです。

更新がないときに、変更不可のフィールドの更新中にエラーが発生する

Config Connector を使用して Google Cloud リソースを作成または取得した直後に、Config Connector のステータスで次のエラーが表示されることがあります。

• Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation （例）

• Update call failed: cannot make changes to immutable field(s) （例）

これは、リソースが実際に更新されたことを意味しているのではなく、 Google Cloud API が Config Connector リソースで管理された不変フィールドを変更したことが原因となっている場合があります。これにより、望ましい状態と変更不可のフィールドのライブ状態の不一致が生じています。

この問題を解決するには、ライブ状態と一致させるために、Config Connector リソース内の変更不可のフィールドの値を更新します。そのためには、次の手順を完了する必要があります。

1. Config Connector リソースの YAML 構成を更新して、cnrm.cloud.google.com/deletion-policy アノテーションを abandon に設定します。
2. 更新された YAML 構成を適用して Config Connector リソースの削除ポリシーを更新します。
3. Config Connector リソースを放棄します。
4. gcloud CLI を使用して、対応する Google Cloud リソースのライブ状態を印刷します。
5. gcloud CLI の出力と Config Connector リソースの YAML 構成の不一致を見つけて、YAML 構成でこれらのフィールドを更新します。
6. 更新された YAML 構成を適用して、放棄されたリソースを取得します。

「Foo」という種類に一致する結果が見つからない

症状

No matches for kind "Foo" というエラーが表示されます。

原因

Kubernetes クラスタに Foo リソースタイプ用の CRD がインストールされていません。

解決策

その種類が Config Connector でサポートされているリソースの種類であることを確認します。

その種類がサポートされている場合は、Config Connector のインストールが期限切れまたは無効のいずれかです。

GKE アドオンを使用して Config Connector をインストールした場合、インストールは自動的にアップグレードされます。Config Connector を手動でインストールした場合、手動アップグレードを実行する必要があります。

GitHub リポジトリを確認して、Config Connector のバージョンごとにサポートされているリソースの種類を確認してください（たとえば、Config Connector v1.44.0 でサポートされる種類はこちらです）。

ラベルが Google Cloud リソースに伝播されない

症状

YAML のラベルが Google Cloud リソースに表示されない。

原因

すべての Google Cloud リソースがラベルをサポートしているわけではありません。

解決策

Config Connector は、metadata.labels にあるラベルを、基盤となるGoogle Cloud リソースにプロパゲートします。リソースの REST API ドキュメント（PubSubTopic の API ドキュメントなど）を確認して、ラベルがサポートされているかどうかを確認します。

リソース名で特殊文字を使用したことによるエラー

症状

metadata.name の無効な文字に関連するエラーが表示されます。

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

原因

Kubernetes の metadata.name フィールドでは、特殊文字を使用できません。

解決策

リソースに有効な Kubernetes 名ではなく、有効な Google Cloud リソース名を付与する場合は、次の例のように resourceID を使用します。

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: [e-mail]

この構成により、Config Connector は、リソースの名前として metadata.name の代わりに resourceID を使用します。

リソース仕様からフィールドを削除できない

症状

Config Connector リソースの仕様からフィールドを削除しても、リソースから削除されることはありません。

原因

Config Connector で管理されているリソースの仕様からフィールドを削除しても、そのフィールドは空になったり、デフォルト値に戻ったりすることはありません。代わりに、そのフィールドは 外部管理になります。

注: 例外が 1 つあります。それは、リスト内のフィールドです。リストはアトミックです。つまり、Config Connector は、基盤となる Google Cloudのリストが仕様で指定されているものと同等になるように設定しようとします。

解決策

基盤となるGoogle Cloud リソースのフィールドの値を空またはデフォルトに変更するには、Config Connector リソース仕様のフィールドを完全に取り除く必要があります。

• リスト型のフィールドの場合は、[] を使用してフィールドを空のリストに設定します。

  次の例は、削除する targetServiceAccounts フィールドを示しています。

  spec:
    targetServiceAccounts:
      - external: "[e-mail]"
      - external: "[e-mail]"
  

  このフィールドを削除するには、値を空に設定します。

  spec:
    targetServiceAccounts: []
  

• プリミティブ型のフィールドの場合は、次のいずれかを使用してフィールドを空に設定します。

  タイプ	空の値
  文字列	""
  bool	"false"
  整数	0

  次の例は、削除する identityNamespace フィールドを示しています。

  spec:
    workloadIdentityConfig:
      identityNamespace: "foo-project.svc.id.goog"
  

  このフィールドを削除するには、値を空に設定します。

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• オブジェクト タイプのフィールドについては、前のセクションのガイダンスに従って、オブジェクト タイプのサブフィールドを空またはデフォルトに設定して、動作するかどうかを確認できます。ただし、この方法が必ず機能するとは限りません。

Arm ベースのノードで Config Connector が起動しない

クラスタに Arm アーキテクチャ（C4A、N4A、Tau T2A マシンシリーズなど）を使用するノードプールが含まれている場合、Config Connector コンポーネントが実行されないことがあります。これは既知の制限事項です。Config Connector は Arm ベースのシステムをサポートしていません。

現象

Config Connector インスタンスがこの問題の影響を受けている場合、次の症状が発生することがあります。

• cnrm-system Namespace の Pod が Pending 状態のままになる。
• Pod のログに、次のようなエラー メッセージを含む CrashLoopBackOff が表示されることがあります。 exec user process caused "exec format error"。
• Pod の説明を行うと、スケジューリングの失敗やアーキテクチャの不一致が明らかになります。

解決策

この問題を解決するには、Config Connector コンポーネントが x86 アーキテクチャのノードでスケジュールされていることを確認します。

• x86 ノードプールを追加する: クラスタに Arm ノードのみが含まれている場合は、Config Connector コントローラ Pod をホストするために、x86 マシンタイプ（e2-standard-2 など）を使用して 1 つ以上のノードプールを追加します。
• ノード taint を確認する: GKE Arm ノードは通常、kubernetes.io/arch=arm64:NoSchedule で taint され、x86 専用のワークロードがスケジュールされないようにします。これらのノードで実行できる tolerations を Config Connector のデプロイに追加していないことを確認します。

強制クリーンアップ

Config Connector リソースが削除時に停止しており、単純に Kubernetes クラスタから対象のリソースを削除する処理を行う必要がある場合は、finalizer を削除することで強制的に削除できます。

警告: このオペレーションは最終的な解決策としてのみ行う必要があります。ファイナライザを削除することは、Config Connector の通常の使用の範囲外であり、予期しない結果を生じする可能性があります。特に、基盤となる Google Cloud リソースに対して生じる影響については保証されません。

リソースのファイナライザを削除するには、kubectl edit を使用してリソースを編集し、metadata.finalizers フィールドを削除してからファイルを保存して、Kubernetes API Server に対して行った変更の内容を保持します。

リソースのファイナライザを削除することによって、Kubernetes クラスタから直ちにリソースを削除できるため、Config Connector は基盤となるGoogle Cloud リソースの削除を完了できない可能性があります（ただし、そうでない場合も考えられます）。つまり、後で Google Cloud リソースを手動で削除することもできます。

モニタリング

Config Connector をモニタリングして、ログを調べることで、問題の原因を特定し、予期しない動作をより深く理解できます。

指標

Prometheus を使用して、Config Connector から指標を収集して表示できます。

ロギング

すべての Config Connector Pod は、JSON 形式で構造化ログを出力します。

コントローラ Pod のログは、リソース調整に関する問題のデバッグに特に有用です。

ログ メッセージで以下のフィールドをフィルタすることで、特定のリソースのログをクエリできます。

• logger: 小文字のリソースの種類が含まれます。たとえば、PubSubTopic リソースには pubsubtopic-controller の logger が存在します。
• resource.namespace: リソースの名前空間が含まれます。
• resource.name: リソースの名前が含まれます。

高度なログクエリにロギングを使用する

GKE を使用している場合は、特定のリソースに対して次のクエリを行い Cloud Logging を使用してログをクエリできます。

注: クエリ構文では、コメントがサポートされていません。次のクエリでは、説明のテキストを提供するために # というコメントの規則を使用しますが、これらのコメントをクエリに含めることはできません。

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

以下を置き換えます。

• GKE_CLUSTER_NAME は、Config Connector を実行している GKE クラスタの名前に置き換えます
• GKE_CLUSTER_LOCATION は、Config Connector を実行している GKE クラスタの場所に置き換えます。例: us-central1
• RESOURCE_KIND は、小文字のリソースの種類に置き換えます。例: pubsubtopic
• RESOURCE_NAMESPACE は、リソースの名前空間に置き換えます。
• RESOURCE_NAME は、リソースの名前に置き換えます。

その他の参考情報

追加のサポートをご利用いただくには、GitHub で問題を報告するか、Google Cloud サポートにお問い合わせください。