Config Sync のトラブルシューティング
このページでは、Config Sync に関する問題を解決する方法について説明します。
Config Sync が常に機能するよう努めていますが、セットアップのトラブルシューティングが必要となる場合もあります。このガイドでは、発生した問題の解決に役立つ一般的なメカニズムについて説明します。
一般的に推奨される利用方法
Config Sync のステータスを確認する
nomos status
コマンドは、Config Sync のインストールで起きていることを把握するために役立つ、集計データとエラーを提供します。次の情報は nomos status
で使用できます。
- クラスタあたりのインストール ステータス
- 同期エラー(Git からの読み取りと変更の調整の両方)
nomos status
を使用するには、nomos
コマンドをインストールします。
gcloud alpha anthos config sync repo
コマンドまたは Config Sync ダッシュボードを使用して、リポジトリごとに Config Sync のステータスを表示することもできます。
サービスレベル指標(SLI)を使用する
Config Sync が意図したとおりに機能していないときに通知を受け取るには、Config Sync SLI に基づいて Prometheus アラートルールを設定します。詳細については、Config Sync SLI を使用するをご覧ください。
kubectl を使用してリソースを調べる
Config Sync は、kubectl
コマンドでクエリ可能な複数のカスタム リソースで構成されています。次のコマンドを使用すると、Config Sync の各オブジェクトのステータスを確認できます。
Config Sync で管理されている Kubernetes リソースについて、次の情報を把握しておく必要があります。
config-management-system
は、Config Sync のすべてのコアシステム コンポーネントの実行に使用する名前空間です。configmanagement.gke.io/v1
とconfigsync.gke.io
は、すべてのカスタム リソースに使用するバージョン プレフィックスです。
カスタム リソースの一覧を取得するには、次のコマンドを実行します。
kubectl api-resources | grep -E "configmanagement.gke.io|configsync.gke.io"
個別のカスタム リソースを使用するには、kubectl get RESOURCE -o yaml
を実行します。
たとえば、次のコマンドの出力では、RootSync オブジェクトのステータスを確認できます。
kubectl get rootsync -n config-management-system -o yaml
gcloud alpha anthos config sync resources
コマンドまたは Config Sync ダッシュボードを使用して、Config Sync が管理するリソースを表示することもできます。
RootSync オブジェクトと RepoSync オブジェクトを確認する
kubectl
を使用して Config Sync をインストールする場合は、ルート リポジトリの構成に関する詳細を含む RootSync オブジェクトを作成します。Google Cloud Console または Google Cloud CLI を使用して Config Sync をインストールすると、Config Sync によって RootSync オブジェクトが自動的に作成されます。複数のリポジトリから同期を構成するときに、名前空間リポジトリの構成情報を含む RepoSync オブジェクトを作成します。
これらのオブジェクトを調べると、Config Sync の状態に関する貴重な情報が得られます。詳細については、RootSync オブジェクトと RepoSync オブジェクトをモニタリングするをご覧ください。
監査ログを使用する
監査ログは有用なデバッグツールです。
Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールした場合は、次の手順で監査ログを使用して Config Sync の調査を行います。
コンソール
GKE Connect / Hub API 監査ログを有効にします。
Google Cloud コンソールで、IAM の [監査ログ] ページに移動します。
表で [GKE Connect / Hub API] チェックボックスをオンにします。
次のチェックボックスをオンにします。
- 管理読み取り
- データ読み取り
- データ書き込み
[保存] をクリックします。
[ログ エクスプローラ] ページに移動します。
[クエリビルダー] テキスト ボックスに次のフィルタを追加します。
resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
[実行] をクリックします。
[クエリ結果] セクションで、エントリを選択してイベントの詳細を確認します。
一般的な問題のトラブルシューティング
FailedScheduling のイベント
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.
このイベントは、ノードで Pod をスケジュールできない場合に発生します。通常は、ノード上の CPU またはメモリが不足していることを示します。このエラーを修正するには、次のいずれかのオプションを選択します。
- 既存の GKE ノードプールにノードを追加する。
- より大きなノードでノードプールを作成する。
有効であるが正しくない ConfigManagement オブジェクト
kubectl
コマンドを使用して Config Sync をインストールし、YAML または JSON 構文エラーに起因しない ConfigManagement オブジェクトの問題によってインストールが失敗した場合、オブジェクトはクラスタでインスタンス化される場合もありますが、正しく動作しない可能性があります。この場合、nomos status
コマンドを使用してオブジェクトのエラーを確認できます。
問題のない有効なインストールのステータスは 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 によって即時に検出されるため、構成を再適用する必要はありません。
ResourceGroup フィールドが変わり続ける
クラスタと同期された Git リポジトリの場合は、すべてのリソースの調整ステータスが ResourceGroup というリソースに集約されます。RootSync オブジェクトや RepoSync オブジェクトごとに ResourceGroup が生成され、クラスタに適用される一連のリソースを取り込んで、それらのステータスを集約します。
場合によっては、ResourceGroup が、ResourceGroup の spec
を更新し続けるループに陥ることがあります。この現象が起きると、次のような問題が発生する可能性があります。
- ResourceGroup の
metadata.generation
が、短時間で増加し続ける。 - ResourceGroup
spec
が変わり続ける。 - ResourceGroup
spec
に、クラスタに同期されているリソースのstatus.resourceStatuses
が含まれない。
こうした問題が見られる場合は、Git リポジトリの一部のリソースがクラスタに適用されていないことを意味します。この問題の原因は、そのリソースを適用するために必要な権限がないことです。
権限がないことは、RepoSync リソースのステータスを取得することで確認できます。
kubectl get reposync repo-sync -n NAMESPACE -o yaml
NAMESPACE
は、Namespace リポジトリを作成した Namespace に置き換えます。
nomos status
を使用することもできます。
ステータスに次のメッセージが確認される場合は、NAMESPACE
の調整ツールに、リソースを適用するために必要な権限がないことを意味します。
errors:
- code: "2009"
errorMessage: |-
KNV2009: deployments.apps "nginx-deployment" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler- default" cannot get resource "deployments" in API group "apps" in the namespace "default"
For more information, see https://g.co/cloud/acm-errors#knv2009
この問題を解決するには、対象の Namespace でエラーが発生したリソースを管理する権限を ns-reconciler-NAMESPACE
サービス アカウントに付与する RoleBinding 構成を宣言する必要があります。RoleBinding を追加する方法についての詳細は、複数のリポジトリからの同期の構成をご覧ください。
Git リポジトリにリソースが多い
RepoSync オブジェクトや RootSync オブジェクトによってクラスタと同期された Git リポジトリに数千を超えるリソースの構成が含まれていると、ResourceGroup で etcd
オブジェクトのサイズ上限を超える可能性があります。この状態になると、Git リポジトリ内のリソースの集約ステータスを表示できません。集計されたステータスを表示できませんが、リポジトリは引き続き同期される可能性があります。
RootSync オブジェクト、RepoSync オブジェクト、または調整ツールのログから次のエラーが表示された場合、ResourceGroup リソースが etcd
オブジェクト サイズの上限を超えていることを意味します。
KNV2009: etcdserver: request is too large
この問題を解決するには、Git リポジトリを複数のリポジトリに分割することをおすすめします。詳細については、リポジトリを複数のリポジトリに分割するをご覧ください。
Config Sync v1.11.0 以降では、Git リポジトリを分割できない場合、ステータス データのサーフェスを無効にすることで、この問題を回避できます。これを行うには、RootSync オブジェクトまたは RepoSync オブジェクトの .spec.override.statusMode
フィールドを disabled
に設定します。これにより、Config Sync は ResourceGroup オブジェクトのマネージド リソース ステータスの更新を停止します。ResourceGroup オブジェクトのサイズが小さくなります。ただし、nomos status
または gcloud alpha anthos config sync
からのマネージド リソースのステータスは表示できません。
Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールした場合は、spec.override.statusMode
を設定できるように編集可能な RootSync オブジェクトを作成します。詳細については、kubectl
コマンドを使用して Config Sync を構成するをご覧ください。
RootSync オブジェクトまたは RepoSync オブジェクトからエラーがまったく表示されない場合は、Git リポジトリがクラスタに同期されていることを意味します。ResourceGroup リソースが etcd
オブジェクトのサイズ上限を超えているかどうかを確認するには、ResourceGroup リソースのステータスと ResourceGroup コントローラのログの両方を確認します。
ResourceGroup のステータスを確認します。
- RootSync オブジェクトを確認するには、次のコマンドを実行します。
kubectl get resourcegroup.kpt.dev root-sync -n config-management-system
- RepoSync オブジェクトを確認するには、次のコマンドを実行します。
kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE
出力は次のようになります。
NAME RECONCILING STALLED AGE root-sync True False 35m
RECONCILING
列の値がTrue
の場合は、ResourceGroup リソースが、まだ調整中であることを意味します。ResourceGroup コントローラのログを確認します。
kubectl logs deployment/resource-group-controller-manager -c manager -n resource-group-system
出力に次のエラーが表示される場合は、ResourceGroup リソースのサイズが大きすぎ、
etcd
オブジェクトのサイズ上限を超えています。"error":"etcdserver: request is too large"
ResourceGroup が大きくなりすぎることを防ぐには、Git リポジトリ内のリソース数を減らします。手順に沿って、1 つのルート リポジトリを複数のルート リポジトリに分割できます。
Git リポジトリと同期されていない
新しい commit が Git リポジトリに push されているにもかかわらず、クラスタの Config Sync ステータスが長時間(spec.git.period
以上)、古い commit と Synced
状態になっている場合は、git-sync
コンテナのログを確認する必要があります。
# check git-sync logs for a root reconciler
kubectl logs -n config-management-system deployment/root-reconciler -c git-sync
# check git-sync logs for a namespace reconciler
kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE -c git-sync
git-sync
が Git リポジトリとの同期に失敗していて、Reconciler が以前に同期した commit との同期を継続している可能性があります。次の出力例は、git-sync
に問題があることを示しています。
"msg"="unexpected error syncing repo, will retry" "error"="Run(git fetch -f
--tags --depth 1 origin develop): exit status 128: { stdout: "", stderr: "fatal:
couldn't find remote ref develop\n" }"
削除された RootSync / RepoSync によって管理されていたリソースを更新または削除するリクエストを Webhook が拒否する
RootSync オブジェクトまたは RepoSync オブジェクトを削除しても、Config Sync のアノテーションとラベルがクリーンアップされません。クラスタで Config Sync がまだ有効になっている場合、Config Sync アドミッション Webhook は、これらのリソースを変更または削除するリクエストを拒否します。
これらのマネージド リソースを維持する場合は、Git リポジトリ内で宣言されているマネージド リソースごとに、configmanagement.gke.io/managed
アノテーションを disabled
に設定し、これらのリソースを管理対象外にします。Config Sync のアノテーションとラベルはマネージド リソースから削除されますがこれらのリソースは削除されません。同期の完了後、RootSync オブジェクトまたは RepoSync オブジェクトを削除できます。
これらのマネージド リソースを削除する場合は、まず、空の Git ディレクトリから同期するように RootSync または RepoSync オブジェクトを変更して、マネージド リソースを削除します。同期の完了後、RootSync オブジェクトまたは RepoSync オブジェクトを削除できます。
マネージド リソースを管理対象にする前または削除する前に RootSync オブジェクトまたは RepoSync オブジェクトを削除した場合は、RootSync オブジェクトまたは RepoSync オブジェクトを再度追加し、マネージド リソースを管理対象外にするか削除してから、RootSync オブジェクトまたは RepoSync オブジェクトを再度削除します。
水平 Pod 自動スケーリングが機能しない
Config Sync は、Git リポジトリのマニフェストで指定したすべてのフィールドを管理します。Config Sync で水平 Pod 自動スケーリングを使用しようとしたときに、2 つのコントローラが同じフィールドを制御しようとすると、リソースの競合が発生することがあります。
水平 Pod 自動スケーリングを使用する場合は、Git リポジトリ内のすべてのマニフェストから spec.replicas
フィールドを削除して、HorizontalPodAutoscaler を管理します。それ以外の場合、Config Sync はリポジトリで指定された変更を元に戻そうと試みます。
PersistentVolumeClaim のステータスが Lost
Kubernetes クラスタをバージョン 1.22 以降にアップグレードすると、マネージド PersistentVolumeClaims が Lost
ステータスになる可能性があります。これは、PersistentVolumes と PersistentVolumeClaims のバインディングが、PersistentVolume リソース内の claimRef
フィールドを使用して定義されている場合に発生します。アップストリームの Kubernetes の変更により、claimRef
フィールドがアトミックになっています。サーバーサイドの適用時に、claimRef
サブフィールドごとに異なるフィールドのオーナーを使用できないため、このバグが発生します。
この問題がアップストリームの Kubernetes で解決されるまで(GitHub 公開バグトラッカー、バグ修正 PR)、PersistentVolume と PersistentVolumeClaim のリソースを更新し、別のバインディング方法を使用することをおすすめします。バインディングは、PersistentVolumeClaim リソースの spec.volumeName
内で設定できます。この処理は、Kubernetes バージョン 1.21 以前で行うことができます。これにより、1.22 へのアップグレード時の中断を防ぐことができます。
以下に、staging-pvc
を staging-pv
にバインドする最小限の例を示します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: staging-pvc
namespace: staging
spec:
volumeName: staging-pv
...
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: staging-pv
spec:
...
バインディングに claimRef
ではなく volumeName
を使用しても、PersistentVolume へのバインディング権限は保証されません。
エラー メッセージが表示される場合のトラブルシューティング
KNV1045: status が指定された構成ファイルが使用できない
ソース リポジトリに status
フィールドを指定すると、KNV1045: Configs with "status" is not allowed というエラーが表示されます。Config Sync を使用して status
フィールドを同期することはできません。別のコントローラが、クラスタ内の status
フィールドの管理と更新を動的に行う必要があります。Config Sync が status
フィールドの望ましい状態を制御しようとすると、status
フィールドを管理するコントローラと競合します。
このエラーを修正するには、ソース リポジトリから status
フィールドを削除します。所有していないサードパーティ構成ファイルの場合は、kustomize
パッチを使用して、マニフェストで指定された status
フィールドを一括して削除します。
KNV2004: git-sync コンテナでリポジトリを同期できないエラー
Config Sync は Git リポジトリのシャロー クローンを作成します。まれに、Config Sync がシャロー クローンから commit を見つけられない場合があります。この場合、Config Sync は取得する Git commit の数を増やします。
取得する Git commit の数を設定するには、RootSync オブジェクトまたは RepoSync オブジェクトの spec.override.gitSyncDepth
フィールドを設定します。
- このフィールドを指定しない場合は、Config Sync によって自動的に構成されます。
- このフィールドが 0 の場合、Config Sync はフルクローンを実行します。このフィールドが 0 より大きい場合はシャロー クローンを実行します。
このフィールドに負の値を設定することはできません。
Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールした場合は、
spec.override.gitSyncDepth
を設定できるように編集可能な RootSync オブジェクトを作成します。詳細については、kubectl
コマンドを使用して Config Sync を構成するをご覧ください。
88
に取得する Git commit の数の設定例を次に示します。
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
name: root-sync
namespace: config-management-system
spec:
override:
gitSyncDepth: 88
git:
...
次のコマンドを実行して、変更が有効になったことを確認します(root-reconciler-git-sync
ConfigMap の data
フィールドで GIT_SYNC_DEPTH
を 88
に設定します)。
kubectl get cm root-reconciler-git-sync -n config-management-system -o yaml
同様に、Namespace Reconciler で取得する Git commit の数をオーバーライドできます。
エラー: アクセスが拒否された
Config Sync を構成しようとしたときに、次の例のようなエラーが表示された場合は、GKE Hub 管理者ロールが割り当てられていない可能性があります。
Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'
必要な権限があることを確認するには、必要な IAM ロールが付与されていることを確認してください。
エラー: アドミッション Webhook によりリクエストが拒否された
Config Sync で管理されているフィールドに変更を適用しようとして次のエラーが発生した場合は、競合が生じる変更を行った可能性があります。
error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified
構成ファイルでフィールドを宣言し、リポジトリがクラスタに同期されると、そのフィールドは Config Sync が管理します。そのフィールドを変更しようとすることは、競合する変更に該当します。
たとえば、リポジトリに environment:prod
のラベルが付いた Deployment 構成ファイルがあり、クラスタ内でそのラベルを environment:dev
に変更しようとすると、それは競合する変更となり、このエラー メッセージが表示されます。ただし、新しいラベル(tier:frontend
など)を Deployment に追加することでは、競合は発生しません。
Config Sync でオブジェクトへの変更が無視されるようにするには、オブジェクトのミューテーションを無視するで説明されているアノテーションを追加します。
エラー: アドミッション Webhook リクエストの I/O タイムアウト
Reconciler がクラスタに構成を適用しようとしたときに次のエラーが発生した場合、ファイアウォールにより、アドミッション Webhook ポート 8676
でコントロール プレーン ネットワークへの通信がブロックされることがあります。
KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout
この問題を解決するには、ポート 8676
を許可するファイアウォール ルールを追加します。これは、Config Sync アドミッション Webhook がドリフト防止に使用するポートです。
エラー: アドミッション Webhook の接続が拒否された
Reconciler が構成をクラスタに適用しようとしたときに次のエラーが発生した場合、アドミッション Webhook の準備がまだできていません。
KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused
これは、Config Sync のブートストラップ時に発生する一時的なエラーです。この問題が繰り返し発生する場合は、アドミッション Webhook Deployment を調べて、Pod がスケジュール可能で正常な状態かどうかを確認します。
kubectl describe deploy admission-webhook -n config-management-system
kubectl get pods -n config-management-system -l app=admission-webhook
エラー: Git Secret をマウントできない
git-sync
コンテナがリポジトリを Secret と同期しようとしたときに次のエラーが発生した場合、Git Secret が git-sync
コンテナに正常にマウントされません。
KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory
これは、Git リポジトリの認証タイプを none
、gcenode
、または gcpserviceaccount
から Secret を必要とするタイプに切り替えると発生する可能性があります。
この問題を解決するには、次のコマンドを実行して Reconciler Manager と Reconciler を再起動します。
# Stop the reconciler-manager Pod. The reconciler-manager Deployment will spin
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system
# Delete the reconciler Deployments. The reconciler-manager will recreate the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system
エラー: 公開リポジトリからリモートベースを pull できない
レンダリング プロセス中に次のエラーが発生した場合、公開リポジトリからリモートベースを pull しようとすると、レンダリング プロセスが正常に完了しません。
KNV1068: failed to run kustomize build in /repo/source/0a7fd88d6c66362584131f9dfd024024352916af/remote-base, stdout:...
no 'git' program on path: exec: "git": executable file not found in $PATH
For more information, see https://g.co/cloud/acm-errors#knv1068
この問題を解決するには、spec.override.enableShellInRendering
を true
に設定します。
Reconciler Pod 内のコンテナで OOMKilled が発生する
ルート リポジトリまたは Namespace リポジトリの CPU やメモリのリクエストと上限をオーバーライドできます。これらの値をオーバーライドするには、RootSync や RepoSync オブジェクトの spec.override.resources
フィールドを使用します。Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールした場合は、spec.override.resources
を設定できるように編集可能な RootSync オブジェクトを作成します。詳細については、kubectl
コマンドを使用して Config Sync を構成するをご覧ください。
次の例は、reconciler
コンテナの CPU とメモリの上限と、ルート Reconciler の git-sync
コンテナの CPU リクエストとメモリの上限をオーバーライドする方法を示しています。git-sync
、oci-sync
、helm-sync
、hydration-controller
、reconciler
の各コンテナをオーバーライドできます。部分的なオーバーライドは可能です。リソース リクエストまたは上限のオーバーライド値が指定されていない場合は、リクエストまたは上限のデフォルトのリソース値が使用されます。
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
name: root-sync
namespace: config-management-system
spec:
sourceFormat: "unstructured"
override:
resources:
- containerName: "reconciler"
cpuLimit: "800m"
memoryLimit: "500Mi"
- containerName: "git-sync"
cpuRequest: "100m"
memoryLimit: "400Mi"
git:
...
次のコマンドを実行して、新しいリソース上限が有効であることを確認します。
kubectl get deployment.apps/root-reconciler -n config-management-system -o yaml
同様に、Namespace Reconciler のリソース上限をオーバーライドできます。
エラー: Namespace が Terminating
フェーズでスタックする
次の条件が発生すると、Terminating
フェーズで名前空間がスタックします。
message: 'Failed to delete all resource types, 1 remaining: admission webhook
"v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
is not authorized to delete managed resource "_configmap_bookstore_cm1"'
reason: ContentDeletionFailed
status: "True"
type: NamespaceDeletionContentFailure
このエラーは、ルート リポジトリから Namespace を削除しようとしたときに、その Namespace の下にある一部のオブジェクトが Namespace Reconciler によってアクティブに管理されていると発生します。名前空間が削除されると、名前空間コントローラ(サービス アカウントが system:serviceaccount:kube-system:namespace-controller
)は、その名前空間にあるすべてのオブジェクトを削除しようとします。ただし、Config Sync アドミッション Webhook は、ルートまたは名前空間の Reconciler にのみこれらのオブジェクトの削除を許可し、名前空間コントローラによる削除を拒否します。
これを回避するには、Config Sync アドミッション Webhook を削除します。
kubectl delete deployment.apps/admission-webhook -n config-management-system
Config Management Operator が Config Sync アドミッション Webhook を再作成します。
この回避策で問題が解決しない場合は、Config Sync の再インストールが必要になることがあります。
エラーの再発を防ぐため、名前空間を削除する前に名前空間リポジトリを削除してください。
エラー: ValidatingWebhookConfiguration に webhooks
フィールドが見つからない
kubectl logs -n config-management-system -l app=admission-webhook
の実行時に、Config Sync アドミッション Webhook ログに次のエラーが記録されている場合があります。
cert-rotation "msg"="Unable to inject cert to webhook." "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "gvk"={"Group":"admissionregistration.k8s.io","Version":"v1","Kind":"ValidatingWebhookConfiguration"} "name"="admission-webhook.configsync.gke.io"
controller-runtime/manager/controller/cert-rotator "msg"="Reconciler error" "error"="`webhooks` field not found in ValidatingWebhookConfiguration" "name"="admission-webhook-cert" "namespace"="config-management-system"
これは、root-reconciler
がクラスタにリソースを同期していないことを意味します。原因としては、root-reconciler
の準備ができていないか、Git リポジトリから同期されているものがないこと(同期ディレクトリが空になっているなど)が考えられます。問題が解決しない場合は、root-reconciler
のヘルスチェックを行います。
kubectl get pods -n config-management-system -l configsync.gke.io/reconciler=root-reconciler
root-reconciler
がクラッシュ ループしているか、OOMKilled が発生している場合は、そのリソースの上限を引き上げます。
エラー: Stackdriver / GoogleCloud エクスポータを作成できない
Open Telemetry Collector のコンポーネントが同じ Namespace のデフォルトのサービス アカウントにアクセスできない場合、config-management-monitoring
の otel-collector
Pod が CrashLoopBackoff ステータスになっていることがあります。また、次のようなエラー メッセージが表示されることもあります。
Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
この問題は通常、クラスタで Workload Identity が有効になっている場合に発生します。
この問題を解決するには、Config Sync のモニタリングの手順に沿って、デフォルトのサービス アカウントに指標の書き込み権限を付与します。
IAM を設定してもエラーが解決しない場合は、otel-collector
Pod を再起動して変更を有効にします。
エラー: サーバー証明書の検証に失敗しました
git-sync
コンテナによる Git リポジトリのクローン作成が失敗し、エラー メッセージ「server certificate verification failed. CAfile:
/etc/ca-cert/cert CRLfile: none
」が表示される場合は、Git サーバーがカスタム認証局(CA)の証明書を使用して構成されていますが、カスタム CA が正しく構成されておらず、それが原因で git-sync
コンテナが Git リポジトリのクローンを作成できないことを意味します。
まず、RootSync オブジェクトまたは RepoSync オブジェクトで spec.git.caCertSecretRef.name
フィールドが指定されているかどうかを確認し、さらに Secret オブジェクトが存在するかどうかも確認します。
このフィールドが構成されていて、Secret オブジェクトが存在する場合は、Secret オブジェクトに完全な証明書が含まれていることを確認します。
カスタム CA のプロビジョニング方法によっては、完全な証明書をチェックする方法が異なる場合があります。
サーバー証明書を一覧表示する方法の例を次に示します。
echo -n | openssl s_client -showcerts -connect HOST:PORT -servername SERVER_NAME 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
場合によっては、自社のネットワーク管理チームに CA 証明書を取得するよう依頼してください。