エラー リファレンス

このページでは、Config Sync のエラーコードと、これらのエラーを処理するために推奨される対応について説明します。

Config Sync のエラー メッセージは、KNV1234 という形式のエラー ID で構成されます。1234 は一意の番号で、その後に問題の説明と修正方法の提案が表示されます。K は Kubernetes の慣例から継承されます。接頭辞 N を持つルールは nomos に固有のものです。V は、リポジトリとクラスタの初期状態で検出可能なエラーに固有のものです。リポジトリとクラスタの初期状態で検出可能なエラーのコードは、KNV1XXX の形式です。実行時にのみ検出できるエラーのコードは KNV2XXX の形式です。

KNV エラーテーブル

エラーコード 説明 ご対応のお願い

Config Sync バージョン　1.6.1 で InternalError の ID が KNV9998 に変更されました。

なし

Config Sync 1.3 で非推奨になっています。

なし

Config Sync 1.3 で非推奨になっています。

なし

階層型リポジトリ構造を使用する場合、名前空間構成ファイルが含まれるディレクトリにサブディレクトリを含めることはできません。

名前空間構成ファイルが含まれていないディレクトリは抽象名前空間ディレクトリであり、それを継承するディレクトリがあります。したがって、抽象名前空間ディレクトリにはサブディレクトリが必要です。名前空間構成を含むディレクトリは名前空間ディレクトリであり、そこから構成を継承することはできないため、サブディレクトリを持つことはできません。

親ディレクトリから名前空間構成を削除するか、サブディレクトリを別の場所に移動します。

クラスタ スコープ オブジェクトはアノテーション configmanagement.gke.io/namespace-selector を宣言できません。NamespaceSelector は、名前空間スコープ オブジェクトに対してのみ宣言できます。

metadata.annotations フィールドから configmanagement.gke.io/namespace-selector を削除します。

管理アノテーションの有効な設定は configmanagement.gke.io/managed=disabled のみです。この設定は、構成をチェックインしたまま、Git リポジトリ内のリソースを明示的に管理対象外にするために使用されます。アノテーション configmanagement.gke.io/managed=enabled は必要ありません。

管理アノテーションが configmanagement.gke.io/managed=disabled であることを確認します。

詳細については、オブジェクトの管理をご覧ください。

リポジトリ内で宣言されたオブジェクトを解析できませんでした。

YAML 形式を検証します。たとえば、kubectl --validate コマンドを使用できます。

nomos vetgroup: configsync.gke.io注: v1.6.0-rc.6が を含むタイプ（RepoSync など）に関するこのエラーを返した場合、解決するために、ダウンロード ページから 以降をダウンロードしてください。

非構造化リポジトリを使用する場合は、抽象名前空間ディレクトリで構成ファイルを宣言しないでください。

エラー メッセージに記載されている構成を Namespace ディレクトリに移動します。

詳細については、非構造化リポジトリの使用をご覧ください。

階層型リポジトリ構造を使用する場合、構成ファイルで名前空間ディレクトリに一致する名前空間が宣言されているか、このフィールドが省略されている必要があります。

エラー メッセージで特定された Namespace フィールドを更新します。

詳細については、階層型リポジトリの構造をご覧ください。

構成で、configmanagement.gke.io で始まるサポートされていないアノテーションを宣言することはできません。

次のサポートされているアノテーションのいずれかを使用していることを確認してください。

configmanagement.gke.io/ で始まるキーを持つラベルを構成に含めることはできません。このラベルキー接頭辞は、Config Sync で使用するために予約されています。

エラー メッセージで特定されたラベルを更新します。たとえば、
configmanagement.gke.io/example-label: label-value
という名前のラベルを宣言しようとした場合は、
example-label: label-value に変更できます。

Config Sync 1.3 で非推奨になっています。

 なし

構成で、存在していない ClusterSelector または NamespaceSelector を参照しています。構成のアノテーションでセレクタを使用するには、そのセレクタが存在している必要があります。

不足しているセレクタを作成するか、セレクタが削除された場合は、それを参照している構成を削除します。

ClusterSelector 構成と NamespaceSelector 構成で正しい構文が使用されているものの、構文エラーが見つかりました。

適切なデータスキーマを使用して構成を指定します。
Config Sync 1.3.2 で非推奨になっています。 なし

階層型リポジトリ構造を使用する場合、ConfigManagement Operator の構成ファイルはリポジトリの system/ ディレクトリに存在する必要があります。この構成には、リポジトリのセマンティック バージョンなどの必要な情報が含まれている必要があります。

ConfigManagement Operator の最小構成を定義します。詳細については、階層型リポジトリの構造をご覧ください。
Config Sync 1.3 で非推奨になっています。 なし

階層型リポジトリ構造を使用する場合、namespaces/ ディレクトリで名前空間を直接宣言することはできません。

エラー メッセージに記載されている Namespace 構成のサブディレクトリを作成します。詳細については、階層型リポジトリの構造をご覧ください。
階層型リポジトリ構造を使用する場合、名前空間構成ファイルに metadata.name を宣言します。その値は名前空間のディレクトリの名前と一致する必要があります。 Namespace の metadata.name を修正するか、ディレクトリ名を変更します。

クラスタ内のリソースに対して CustomResourceDefinition が定義されていません。

エラー メッセージで参照されているリソースの CustomResourceDefinition を作成します。組み込みの Kubernetes オブジェクトではないリソースタイプには、CustomResourceDefinition が必要です。

階層型リポジトリを使用している場合、この種類の構成は system/ ディレクトリで宣言できません。

エラー メッセージで参照されているリソースを system/ ディレクトリから移動します。詳細については、階層型リポジトリの構造をご覧ください。

Repo 構成の spec.version フィールドは、リポジトリのセマンティック バージョンを表します。このエラーは、サポートされていないバージョンが使用されていることを示します。

リポジトリの形式がサポートされているバージョンと互換性がある場合は、spec.version フィールドを更新します。アップグレードする必要がある場合は、リリースノートの指示に従ってください。

ディレクトリ名は 64 文字未満で、小文字の英数字または「-」で構成し、英数字で始まり英数字で終わる必要があります。

名前が間違っているディレクトリの名前を変更するか、削除します。

同じ Kind の構成は、同じ Namespace と親の抽象 Namespace 内で一意の名前を持つ必要があります。

エラー メッセージで参照されている構成の名前を変更するか、削除して、すべてが一意の名前になるようにします。

同じディレクトリに複数の Namespace リソースを存在させることはできません。

重複する構成を削除して、Namespace リソースが 1 つだけ残るようにします。

すべての構成で metadata.name を宣言する必要があります。

問題のある構成に metadata.name フィールドを追加します。

sourceFormat が unstructured に設定されている場合、型 Repo.configmanagement.gke.io は使用できません。

問題のある構成を削除するか、リポジトリを sourceFormat: hierarchy を使用するように変換します。

階層型リポジトリを使用している場合は、system/ ディレクトリで HierarchyConfig と Repo の Kind のみを宣言できます。

system/ ディレクトリで宣言された構成が、許可されている Kind のいずれかであることを確認します。そうでない場合は、別のディレクトリに移動します。

config-management-system、resource-group-system、config-management-monitoring、またはそれらのリソースを宣言することは禁止されています。

config-management-system 名前空間を宣言した場合は、その名前空間とその名前空間内の構成を削除します。

resource-group-system または config-management-monitoring Namespace を宣言した場合は、コントローラ Namespace の管理を解除します。

  1. Config Sync を更新して、名前空間の管理と宣言されたリソースを停止します。
  2. 同期を待ってから、対応するリソースがクラスタでは引き続き使用可能だが、nomos status では使用できないことを確認します。
  3. ソースからコントローラ Namespace の YAML ファイルを削除します。
  4. Config Sync にリソースの管理を再開させます。

以前に階層型リポジトリと同期していて、リソースとともにコントローラの名前空間を宣言する必要があった場合は、ソース構造で柔軟性を高めるために非構造化リポジトリへの切り替えを検討してください。

指定された metadata.name の形式が無効です。

次の条件を満たすように metadata.name を変更します。

  • 254 文字未満である
  • 小文字の英数字、「-」、「.」で構成されている
  • 先頭と末尾が英数字である

metadata.name が無効で、元のリソースでサポートされている場合は、これらの制限によって制約されないように、代わりに spec.resourceID フィールドを使用することを検討してください。詳細については、resourceID フィールドを使用したリソースの管理をご覧ください。
Config Sync 1.3 で非推奨になっています。 なし

Namespace スコープ オブジェクトを namespaces/ ディレクトリ外で宣言することは禁止されています。

問題のある構成ファイルを正しいディレクトリに移動します。名前空間スコープ オブジェクトの詳細については、名前空間スコープ オブジェクトをご覧ください。

クラスタ スコープ オブジェクトを cluster/ ディレクトリ外で宣言することは禁止されています。

問題のある構成ファイルを正しいディレクトリに移動します。クラスタ スコープ オブジェクトの詳細については、クラスタ スコープ オブジェクトをご覧ください。
Config Sync 1.3 で非推奨になっています。 なし

このリソースの種類は HierarchyConfig で宣言してはなりません。

問題のあるリソースを削除します。HierarchyConfigs の詳細については、HierarchyConfigある特定のオブジェクト タイプについて継承を無効にするをご覧ください。

HierarchyConfig で HierarchyMode に対する不正な値が検出されました。

HierarchyMode を none または inherit に変更します。HierarchyConfigs の詳細については、ある特定のオブジェクト タイプについて継承を無効にするをご覧ください。

Config Sync はこのオブジェクトを構成できません。

 リポジトリから問題のある構成を削除します。

構成を含む抽象名前空間ディレクトリには、少なくとも 1 つの名前空間サブディレクトリが必要です。

抽象 Namespace ディレクトリの下に Namespace ディレクトリを追加するか、抽象 Namespace ディレクトリに Namespace 構成を追加するか、抽象 Namespace ディレクトリの構成を削除します。

metadata.ownerReference が指定された構成ファイルは使用できません。

ソース リポジトリから status フィールドを削除します。所有していないサードパーティ構成ファイルの場合は、kustomize patchesstatus パッチを使用して、マニフェストで指定された フィールドを一括して削除します。

この HierarchyConfig は、クラスタ スコープを持つリソースを参照します。HierarchyConfig ではクラスタ スコープ オブジェクトは許可されていません。

問題のあるリソースを参照しないように HierarchyConfig を更新します。

カスタム リソース定義（CRD）を削除し、対応するカスタム リソースをリポジトリに残すことはできません。

カスタム リソースとともに CRD を削除します。

CustomResourceDefinition の名前が無効です。

エラー メッセージに表示された推奨事項に名前を変更します。

構成で非推奨の Group と Kind が使用されています。

エラー メッセージの推奨事項に従って、グループまたは種類を変更します。

クラスタ スコープのリソースは metadata.namespace を宣言できません。

 クラスタ スコープのリソースから metadata.namespace フィールドを削除します。

名前空間スコープのリソースは、metadata.namespace または metadata.annotations.configmanagement.gke.io/namespace-selector のいずれかを宣言する必要があります。

不足しているフィールドを Namespace スコープのリソースに追加します。

構成ファイルのアノテーションに無効な値が含まれています。

エラー メッセージの手順に沿ってエラーを解決します。

metadata.namespace の値が有効な Kubernetes Namespace 名ではありません。

metadata.namespace の値を更新して、次のルールに準拠するようにします。

  • 長さが 63 文字以下である
  • 小文字（a ～ z）、数字（0 ～ 9）、ハイフン（-）のみで構成されている
  • 先頭と末尾は小文字または数字

リソースが非マネージド Namespace で宣言されています。

configmanagement.gke.io/managed: disabled アノテーションを削除するか、宣言されたリソースにアノテーションを追加します。

リソースに無効なラベルがあります。

エラー メッセージに記載されている無効なラベルを削除します。

Namespace リポジトリでは、リポジトリが適用される Namespace で名前空間スコープのリソースのみを宣言できます。

すべての Namespace リポジトリが Namespace スコープのリソースを正しく宣言していることを確認します。たとえば、shipping Namespace リポジトリのリポジトリは、shipping Namespace のリソースのみを管理できます。metadata.namespace の値は省略可能です。デフォルトでは、Config Sync は namespace リポジトリ内のすべてのリソースがその namespace に属していると想定します。

たとえば、shipping Namespace リポジトリの構成ファイルで metadata.namespace: billing が宣言されている場合、エラーが発生します。

Namespace スコープのリソースが正しく宣言されていることを確認するだけでなく、Namespace がルート リポジトリで宣言されていることを確認します。これは、namespace がクラスタ スコープであるため必要です。

namespace リポジトリで宣言できる Kptfile リソースは 1 つだけです。

 Kptfile リソースを 1 つだけ残して、他はすべて削除します。

複数の信頼できる情報源のオブジェクトを管理する場合、同じオブジェクト（一致するグループ、種類、名前、namespace）が複数のソースで宣言されると、競合が発生する可能性があります。

たとえば、同じオブジェクトが RootSync と RepoSync で管理されている場合、RootSync が優先されます。RootSync が最初に適用された場合、RepoSync は KNV1060 ステータス エラーを報告します。RepoSync が最初に適用された場合、RootSync は RepoSync のオブジェクトを上書きします。RepoSync はこの更新を検出し、KNV1060 ステータス エラーを報告します。

他の信頼できる情報源と一致するように構成ファイルを更新するか、競合するオブジェクトをいずれかのソースから削除することで、競合を解決します。

nomos vet コマンドは一度に 1 つのリポジトリでエラーをチェックするため、この問題を検出できません。

InvalidRepoSyncError によって、RepoSync が正しく構成されていないことが報告されます。Config Sync が Namespace リポから構成を同期するには、RepoSync オブジェクトを適切に構成する必要があります。

エラー メッセージの手順に沿って、構成エラーを修正します。

Kptfile に有効なインベントリ フィールドがありません。Kptfile には、ID と名前空間の両方を指定した、空ではないインベントリ フィールドが必要です。

Kptfile で .inventory.identifier と .inventory.namespace の値を指定します。

ルート リポジトリで Kptfile が見つかりました。kptfile は、名前空間にスコープされたリポジトリでのみサポートされています。

ルート リポジトリから Kptfile を削除します。

リポジトリ内の api-resources.txt ファイルを解析できませんでした。

エラー メッセージに表示される手順に沿って操作します。たとえば、kubectl api-resources > api-resources.txt を再実行する必要がある場合があります。

CustomResourceDefinition の形式が正しくありません。

エラー メッセージで指定されたフィールドを確認し、その値の形式が正しいことを確認します。

構成オブジェクトにより宣言されるクラスタセレクタ アノテーションは、1 つだけである必要があります。このエラーは、従来のアノテーション（configmanagement.gke.io/cluster-selector）とインライン アノテーション（configsync.gke.io/cluster-name-selector）の両方が存在する場合に発生します。

metadata.annotations フィールドからアノテーションの 1 つを削除します。

Reconciler が、宣言されたフィールドをサーバーサイドの適用と互換性のある形式にエンコードできない。古いスキーマが原因である可能性があります。

エラー メッセージで指定されたフィールドを確認し、それがリソースの種類のスキーマと一致することを確認します。

レンダリング プロセスでユーザーが対処できる問題が発生しました。

Git リポジトリに Kustomize 構成が含まれているが、Git 同期ディレクトリに kustomization.yaml ファイルが存在しない場合は、同期ディレクトリに kustomization.yaml を追加してレンダリング プロセスをトリガーするか、すべてのサブディレクトリから kustomization.yaml を削除してレンダリングをスキップします。

エラーが kustomize build の失敗に起因する場合は、Git リポジトリの Kustomize 構成の更新が必要になることがあります。nomos hydrate と nomos vet をそれぞれ使用して、更新された構成ファイルをローカルでプレビューして検証できます。更新された構成ファイルが正しくレンダリングされたら、新しい commit を push して KNV1068 エラーを修正できます。

公開リポジトリからリモートベースを pull するときに kustomize build エラーが発生した場合は、spec.override.enableShellInRendering を true に設定する必要があります。

Reconciler が自身の RootSync オブジェクトまたは RepoSync オブジェクトを調整しました。RootSync オブジェクトは他の RootSync オブジェクトと RepoSync オブジェクトを管理でき、RepoSync オブジェクトは他の RepoSync オブジェクトを管理できますが、これらは自分自身を管理することはできません。

RootSync オブジェクトまたは RepoSync オブジェクトを、そのオブジェクトの同期元となる信頼できるソースから削除します。

ファイル システム リソースにアクセスする OS レベルのシステムコールが失敗します。

このエラーは、無効な YAML 構成または特殊文字の使用が原因で発生する可能性があります。YAML 構成が無効な場合は、KNV2001: yaml: line 2: did not find expected node content path:... のようなエラー メッセージが表示されます。この問題を解決するには、YAML ファイルを確認して、構成に関する問題を解決してください。これは、リポジトリ内の YAML 構成が原因で発生する可能性があります。

ファイル名またはパスに特殊文字が含まれていると、KNV2001: yaml: control characters are not allowed path:/repo/source/.../._pod.yaml のようなエラー メッセージが表示されることがあります。この例では、._pod.yaml は有効なファイル名ではありません。この問題を解決するには、ファイル名またはパス名から特殊文字を削除します。

Kubernetes API サーバーへのアクセス リクエストが失敗します。

Kubernetes API リクエストは、さまざまな理由で失敗する可能性があります。一般的には次のような原因が考えられます。

  • API 検出エラー
  • クライアントサイドまたはサーバーサイドのリクエストまたはレスポンスのタイムアウト
  • ID、認証、認可のエラー
  • ネットワーク接続エラー
  • Webhook によりリクエストが拒否された
  • Webhook が異常または API サーバーからアクセスできない

Config Sync は、ほとんどの API サーバー エラーの後に再試行します。一時的な問題で自然に解決するものもありますが、ほとんどはユーザーの介入が必要になります。API サーバーのエラーは Config Sync 自体が原因であることはほとんどありませんが、その可能性があると思われる場合は、バグレポートを送信してください。
OS レベルの一般的なシステムコールが失敗しました。

Config Sync が信頼できる情報源から読み取ることができない。

このエラーは、複数の問題が原因で発生する可能性があります。信頼できる情報源への接続のトラブルシューティングについては、信頼できる情報源への接続のトラブルシューティングをご覧ください。KNV2004 エラーの原因となる既知の問題については、既知の問題をご覧ください。
Config Sync がリソースに対して別のコントローラと競合しています。このような競合により、大量のリソースを消費し、パフォーマンスが低下する可能性があります。 コントローラの競合を診断して解決する方法については、コントローラの競合のトラブルシューティングをご覧ください。

誤って削除されないように、Config Sync では、1 回の commit ですべての Namespace やクラスタ スコープのリソースを削除することはできません。

Config Sync アドミッション Webhook が無効になっている場合は、すべてのリソースを削除する commit を元に戻します。
Config Sync アドミッション Webhook が有効になっている場合、Namespace が停止している可能性があります。 この問題を修正するには、次の手順を行います。

  1. Config Sync を無効にして、すべてのリソースがクリーニングされるか、安定したステータスになるまで待ちます。たとえば、kubectl get ns を実行して、名前空間の削除を確認できます。
  2. Config Sync を再度有効にします。
  3. すべてのリソースを削除する commit を元に戻します。

管理下のすべてのリソースセットを削除するには、次の操作を行います。

  1. 最初の commit で 1 つの名前空間またはクラスタ スコープのリソースを除くすべてを削除し、Config Sync でこれらの変更を同期できるようにします。
  2. 2 回目の commit で最後のリソースを削除します。

API サーバーのリソースが変更または削除されるときに、Config Sync がこのリソースを変更しようとしています。

このタイプのエラーが起動時のみ発生する場合、または発生する頻度が低い場合、このエラーは無視してかまいません。

これらのエラーが一時的なものではない場合（数分以上続く場合）、重大な問題が発生している可能性があります。その場合、nomos status がコントローラの競合を報告します。

これは、Config Sync が一部の構成ファイルをクラスタに同期できなかったことを示す一般的なエラーです。

このエラーは、さまざまな問題が原因で発生する可能性があります。同期に関する一般的な問題を解決するためのヒントについては、同期のトラブルシューティングをご覧ください。

これは、ある特定のリソースまたはリソースのセットに問題があることを示す一般的なエラーです。

エラーの原因となった具体的なリソースがメッセージに含まれています。これらのリソースを調査します。

続行するために特定のリソースが必要であるのに、そのリソースが見つかりませんでした。たとえば、ConfigManagement Operator があるリソースを更新しようとしていて、更新の計算中にそのリソースが削除された場合がこれに該当します。

不足しているリソースを作成または復元します。

このエラーは、ある APIResource が 1 つだけ許可されているコンテキストで、その APIResource のインスタンスが複数見つかったことを示します。たとえば、クラスタに存在できる Repo リソースは 1 つだけです。

追加の APIResource を削除します。

名前空間のリコンサイラにリソースを管理する権限が不足しています。

Reconciler に十分な権限があることを確認します。

この警告は、Config Sync Webhook の構成が不正に変更された場合に発生します。不正な Webhook の構成は無視されます。

不正に変更された Webhook を削除します。

レンダリング プロセスで内部問題が発生しました。たとえば、Config Sync がファイル システムにアクセスできない場合などです。

このエラーは、Pod が正常でないことを示している可能性があります。次のコマンドを実行して、Reconciler Pod を再起動できます。

# restart a root reconciler
kubectl delete pod -n config-management-system -l configsync.gke.io/reconciler=root-reconciler

# restart a namespace reconciler
kubectl delete pod -n config-management-system -l configsync.gke.io/reconciler=ns-reconciler-NAMESPACE

このエラーは、後で自動的に解決される一時的な問題を表します。たとえば、レンダリング状態がソース構成ファイルと一致しない場合、このエラーが表示されることがあります。

エラーは自動的に解決されます。

Config Sync 自体に問題があります。

バグレポートを提出してください。

エラー メッセージが文書化されていないエラーが発生しました。

発生したエラーに関するドキュメントはまだ作成されていません。

トップへ戻る

KNV コードのないエラー メッセージ

Config Sync Reconciler によって報告されるエラーには KNV エラーコードがありますが、他のコンポーネントから報告されるエラーには KNV コードがありません。たとえば、権限拒否エラーは、Config Sync の上位レイヤであるフリート コントローラから発生します。

次の表に、KNV 接頭辞のない一般的なエラーを示します。

エラー メッセージ ご対応のお願い

Error: cannot build exporters: error creating stackdriver exporter: cannot configure Google Cloud metric exporter: stackdriver: google: could not find default credentials.

Error: Permission monitoring.timeSeries.create denied (or the resource may not exist).

エクスポータをビルドできない

Open Telemetry Collector のコンポーネントが同じ Namespace のデフォルトのサービス アカウントにアクセスできない場合、config-management-monitoring の otel-collector Pod が CrashLoopBackoff ステータスになっていることがあります。また、次のようなエラー メッセージが表示されることもあります。

この問題は通常、クラスタで Workload Identity Federation for GKE が有効になっている場合に発生します。

この問題を解決するには、Config Sync のモニタリングの手順に沿って、デフォルトのサービス アカウントに指標の書き込み権限を付与します。

IAM を設定してもエラーが解決しない場合は、otel-collector Pod を再起動して変更を有効にします。
カスタム モニタリング ソリューションを使用しているが、デフォルトの otel-collector-googlecloud ConfigMap をフォークしている場合は、差分を確認してリベースします。
server certificate verification failed. CAfile:/etc/ca-cert/cert CRLfile: none

サーバー証明書の検証エラー

git-sync、helm-sync、oci-sync コンテナがアーティファクトの取得に失敗すると、このエラー メッセージが表示されることがあります。

このメッセージは、サーバーがカスタム認証局（CA）の証明書で構成されていることを示します。ただし、カスタム CA が正しく構成されていないため、コンテナがサーバーから取得できません。

この問題を解決するには、まず RootSync オブジェクトまたは RepoSync オブジェクトで caCertSecretRef フィールドが正しく構成されているかどうかを確認し、さらに 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 証明書を取得するよう依頼してください。
Error message: "MESSAGE": "Unable to retrieve pull secret, the image pull may not succeed."

pull シークレットを取得できない。イメージの pull が失敗する場合がある

Google Distributed Cloud で非公開レジストリを使用している場合、Config Sync のインストールまたはアップグレードが停止することがあります。次のようなエラー メッセージが表示されます。

この問題を解決するには、Config Sync をインストールまたはアップグレードする前に、非公開レジストリを使用して Config Sync を更新するの手順を行います。
Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

権限が却下されました

Config Sync を構成しようとしたときに、次の例のようなエラーが表示された場合は、GKE Hub 管理者ロールが割り当てられていない可能性があります。

必要な権限があることを確認するには、必要な IAM ロールが付与されていることを確認してください。

トップへ戻る

次のステップ