Config Sync の既知の問題

このページでは、サポートされている Config Sync のバージョンに関する既知の問題について説明します。既知の問題をプロダクト バージョンまたは問題のカテゴリでフィルタするには、次のプルダウン メニューからフィルタを選択します。

Config Sync のバージョンを選択します。

問題のカテゴリを選択します。

または、次のように既知の問題をフィルタします。

カテゴリ 識別されたバージョン 固定バージョン 問題と回避策
コンポーネントの健全性 1.15.0 1.17.0

AutoPilot での Reconciler コンテナ OOMKilled

Autopilot クラスタでは、Config Sync コンポーネント コンテナに CPU とメモリのリソース上限が設定されています。負荷がかかった状態では、過剰なメモリ使用量が原因で kubelet またはカーネルによってこれらのコンテナが強制終了される可能性があります。

回避策:

バージョン 1.17.0 以降にアップグレードします。Config Sync バージョン 1.17.0 では、デフォルトの CPU とメモリの上限が調整され、ほとんどのユースケースでメモリ不足エラーが回避されるようになりました。

アップグレードできない場合は、リソースのオーバーライドを使用して、より高い値のメモリ上限を指定します。
コンポーネントの健全性 1.15.0

Reconciler のスケジュールが設定できない

Config Sync Reconciler に必要なリソース量は、RootSync または RepoSync の構成によって異なります。構成の中には、他の構成よりも多くのリソースを必要とするものがあります。

Reconciler がスケジュール不可の場合は、ノードで使用可能な量を超えるリソースをリクエストしている可能性があります。

標準モードの GKE クラスタを使用している場合、Reconciler リソース リクエストは非常に低く設定されます。この設定は、スロットリングやパフォーマンス低下につながる場合でもあっても、スケジューリングを可能にすることを目的として選択されています。これにより、Config Sync は小規模なクラスタや小規模なノードでも機能します。ただし、GKE Autopilot クラスタでは、同期中の使用状況をより現実的に表すように、Reconciler リクエストが高い値に設定されます。

回避策:

ノードの自動プロビジョニングが有効になっている GKE Autopilot または GKE Standard は、リクエストされたリソース数を確認し、スケジューリングを可能にするために適切なサイズのノードを作成できる必要があります。ただし、ノードまたはノード インスタンス サイズを手動で構成する場合は、Reconciler Pod のリソース要件に合わせて、それらの設定の調整が必要になる可能性があります。
KNV のエラー 1.15.0 Kubernetes バージョン 1.27

構成が正常に適用されているにもかかわらず KNV1067 エラーが発生する

OpenAPI v2 の問題により、構成が正常に適用された場合でも KNV1067 エラーが表示される可能性があります。

回避策:

クラスタで 1.27 より前の Kubernetes バージョンが実行されている場合は、デフォルトの TCP を使用している場合でも protocol フィールドが spec: containers: ports: の下に明示的に設定されるようにする必要があります。
KNV のエラー 1.15.0 1.16.0

Config Sync が KNV2002 エラーで調整に失敗する

Config Sync が KNV2002 error と調整できない場合は、client-go の問題による既知の問題が原因である可能性があります。この問題により、external.metrics.k8s.io/v1beta1 API グループのリソースが空のリストになり、RootSync オブジェクトまたは RepoSync オブジェクトからのエラー メッセージ、または Reconciler のログに次のように表示されます。


KNV2002: API discovery failed: APIServer error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: received empty response for:
external.metrics.k8s.io/v1beta1

回避策:

この問題を解決するには、GKE クラスタを GKE バージョン 1.28 以降にアップグレードするか、Config Sync をバージョン 1.16.0 以降にアップグレードします。どちらのバージョンにも client-go に関する問題の修正が含まれています。
指標 1.15.0 1.17.2

エクスポート失敗: 認識されない指標ラベル

バージョン 1.15.0 では、Config Sync によって多くの指標に type ラベルと commit ラベルが追加されました。これらのラベルによって指標のカーディナリティが増加し、エクスポートされる指標の数が増加しました。Cloud Monarch へのエクスポート時に、これらのラベルをフィルタする属性処理も追加されましたが、このフィルタリングの構成が誤っており、otel-collector ログに変換エラーが生じていました。

回避策:

バージョン 1.17.2 以降にアップグレードします。
指標 1.15.0 1.16.1

高い指標のカーディナリティと変換エラー

バージョン 1.15.0 では、Config Sync によって多くの指標に type ラベルと commit ラベルが追加されました。これらのラベルによって指標のカーディナリティが増加し、エクスポートされる指標の数が増加しました。Cloud Monarch へのエクスポート時に、これらのラベルをフィルタする属性処理も追加されましたが、このフィルタリングの構成が誤っており、otel-collector ログに変換エラーが生じていました。

回避策:

バージョン 1.16.1 以降にアップグレードします。バージョン 1.16.1 ではタイプ フィールドの削除とフィルタリングの修正が行われ、commit フィールドが Cloud Monitoring からさらにフィルタリングされました。これによりエラーは修正され、指標のカーディナリティが削減されました。
指標 1.15.0

エクスポートに失敗しました。権限が却下されました

デフォルトでは、reconciler-manager がアプリケーションのデフォルト認証情報を検出すると、otel-collector は、Prometheus、Cloud Monitoring、Monarch に指標をエクスポートするように構成されます。

回避策:

Cloud Monitoring を構成していないか、Cloud Monitoring と Cloud Monarch を無効化していない場合は、otel-collector がエラーをログに記録します。
指標 1.15.0

カスタム構成で otel-collector がクラッシュする

デフォルトの ConfigMap のいずれか（otel-collector または otel-collector-google-cloud）を変更または削除しようとすると、otel-collector でエラーやクラッシュが発生し、必要な ConfigMap を読み込めない場合があります。

回避策:

指標のエクスポート構成をカスタマイズするには、otel-collector-custom という名前の ConfigMap を config-management-monitoring 名前空間に作成します。
指標 1.14.0

指標の合計が欠落している

Config Sync バージョン 1.14.0 では、resource_count_total、ready_resource_count_total、kcc_resource_count_total の指標が削除されました。

回避策:

合計値を追跡するには、Cloud Monitoring で Sum 集計タイプを使用します。
指標 1.14.1

Pod の指標が欠落している

Config Sync バージョン 1.14.1 では、ほとんどの Config Sync の指標が k8s_pod タイプではなく k8s_container タイプを使用するように変更されました。これにより、指標の取得元であるコンテナを識別できます。これは、多数のコンテナがある Reconciler Pod で特に有用です。この変更により、これらの指標を追跡していたダッシュボードとアラートが機能しなくなる可能性があります。

回避策:

指標を更新して、k8s_container タイプの指標を追跡します。
nomos CLI 1.15.0 1.17.2

nomos status と nomos bugreport は Pod で機能しません。

バージョン 1.17.2 より前の nomos では、nomos bugreport と nomos status は Kubernetes Pod 内で実行している場合にのみローカル クラスタに接続できました。nomos バージョン 1.17.2 では、認証方法が kubectl により近い動作をするように変更されました。この変更のため、デフォルトでローカル クラスタがターゲットになります。この構成をオーバーライドするには、KUBECONFIG 環境変数を指定します。

回避策:

nomos バージョン 1.17.2 にアップグレードします。
修復

Config Sync が自身と競合している

Config Sync が自身とコントローラの競合状態にあるように見えることがあります。この問題は、Git リポジトリ内のリソースのオプション フィールドにデフォルト値を設定した場合に発生します。たとえば、RoleBinding のサブジェクトに対して apiGroup: "" を設定すると、apiGroup フィールドがオプションになり、空の文字列がデフォルト値になるため、これがトリガーされます。文字列、ブール値、整数のフィールドのデフォルト値は、それぞれ ""、false、0 です。

回避策:

リソース宣言からフィールドを削除します。
修復

Config Sync が Config Connector リソースと競合している

Config Sync が、リソース（例: StorageBucket）に対して Config Connector と競合しているように見える場合があります。この問題は、信頼できる情報源のリソース spec.lifecycleRule.condition.withState のオプション フィールドの値を設定していない場合に発生します。

回避策:

この問題を回避するには、リソース宣言に withState=ANY フィールドを追加します。または、cnrm.cloud.google.com/state-into-spec: absent アノテーションを使用してリソースを破棄して再取得することもできます。
信頼できる情報源 1.16.1 1.16.2

定期的にソースリンクを評価できない状態になる

Reconciler が起動し、ソースリンクが定期的に評価できなくなると、Config Sync で問題が発生する場合があります。この問題は、git-sync がまだソース リポジトリのクローンを作成していないために発生します。

回避策:

Config Sync をバージョン 1.16.2 以降に更新します。これらのバージョンでは、これは一時的なエラーであるため、ログに記録されますが、エラーとして報告されません。
信頼できる情報源 1.15.0 1.17.0

リポジトリの同期エラー: コンテキストの期限を超過した

1.17.0 より前のバージョンでは、Config Sync はデフォルトで Git リポジトリの全履歴をチェックアウトしていました。このため、多数の commit がある大規模なリポジトリで取得リクエストがタイムアウトする可能性があります。

回避策:

バージョン 1.17.0 以降にアップグレードします。バージョン 1.17.0 以降では、Git の取得は --depth=1 を使用して実行されます。これにより、最新の commit のみが取得されます。これにより、ソースの取得が高速化され、ほとんどのタイムアウトが回避され、Git サーバーの負荷が軽減されます。

アップグレード後もこの問題が引き続き発生する場合は、信頼できる情報源に多数のファイルがある、Git サーバーのレスポンスが遅い、または他のネットワークの問題がある可能性があります。
同期 1.15.0

監査ログに無効な PATCH リクエストが多数ある

Config Sync のリメディエーターは、ドライランを使用してドリフトを検出します。これにより、PATCH が永続化されていない場合でも、監査ログでドライランと通常のリクエストを区別しないため、監査ログに PATCH リクエストが表示される場合があります。

回避策:

監査ログではドライランと非ドライランのリクエストを区別できないため、PATCH リクエストを無視できます。
同期 1.17.0

Config Sync がブランチから最新の commit を pull できない

Config Sync バージョン 1.17.0 以降では、同じブランチが複数のリモートで参照されていて、それらが同期されていない場合、Config Sync が特定のブランチの HEAD から最新の commit を pull できないという問題が発生する可能性があります。たとえば、リモート リポジトリ origin の main ブランチは、リモート リポジトリ upstream の同じブランチの前にある場合がありますが、Config Sync は最後のラインの commit SHA のみをフェッチして、それが最新の commit ではない可能性があります。

この問題の例を以下に示します。


git ls-remote -q [GIT_REPOSITORY_URL] main  main^{}
244999b795d4a7890f237ef3c8035d68ad56515d    refs/heads/main               # the latest commit
be2c0aec052e300028d9c6d919787624290505b6    refs/remotes/upstream/main    # the commit Config Sync pulls from

回避策:

この問題を軽減するには、Git ブランチ（spec.git.branch）に設定された値に関係なく、Git リビジョン（spec.git.revision）を最新の commit SHA に設定します。Git 構成の詳細については、Git リポジトリの構成をご覧ください。

トップへ戻る

次のステップ