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 がスケジューリングできない場合は、ノードで使用可能な量を超えるリソースをリクエストしている可能性があります。

Standard モードの 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 を使用している場合でも spec: containers: ports: に protocol フィールドを明示的に設定する必要があります。
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 では type フィールドの削除とフィルタリングの修正が行われ、commit フィールドが Cloud Monitoring からフィルタリングされました。これにより、エラーが修正され、指標のカーディナリティも減少しました。
指標 1.15.0

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

デフォルトでは、Reconciler マネージャーがアプリケーションのデフォルト認証情報を検出すると、Otel コレクタは 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 を読み込めない場合があります。

回避策:

指標のエクスポート構成をカスタマイズするには、config-management-monitoring Namespace に otel-collector-custom という名前の ConfigMap を作成します。
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 と Config Connector が StorageBucket などのリソースに対して競合状態になっているように見える場合があります。この問題は、信頼できる情報源のリソース spec.lifecycleRule.condition.withState のオプション フィールドの値を設定していない場合に発生します。

回避策:

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

GitHub での Git SSH 認証エラー

git-sync v4.2.1 には、SSH 使用時にリポジトリ URL からユーザー名が削除されるバグがあり、GitHub に接続するときに認証が失敗します。この場合、ユーザーは git である必要があります。

git のエラー メッセージは次のとおりです。git-sync@github.com: Permission denied (publickey).\r\nfatal: Could not read from remote repository.

回避策:

バージョン 1.17.2 にダウングレードするか、別の認証方法を使用します。
信頼できる情報源 1.16.1 1.16.2

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

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

回避策:

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

Cloud Source Repositories の認証情報が定期的に無効になる

Cloud Source Repositories の認証トークンが期限切れになると、Config Sync が定期的にエラーになることがあります。この問題は、トークンの更新が期限切れになるまで待ってからトークンを更新すると発生します。

回避策:

Config Sync をバージョン 1.18.0 以降に更新します。これらのバージョンでは、トークンの有効期限が切れてから 5 分以内に最初のリクエストが行われると、トークンが更新されます。これにより、認証情報が実際に無効でない限り、無効な認証情報エラーを防ぐことができます。
信頼できる情報源 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 リポジトリの構成をご覧ください。
非公開レジストリ

Config Sync が reconciler Deployment に非公開レジストリを使用しない場合

非公開レジストリが構成されている場合、Config Sync はすべての Deployment のイメージを置き換える必要があります。ただし、Config Sync は、Reconciler Deployment のイメージのイメージ レジストリに代わるものではありません。

回避策:

この問題を回避するには、containerd でイメージ レジストリ ミラーを構成します。

トップへ戻る

次のステップ