エラー リファレンス

このページでは、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 など）に関するこのエラーを返した場合、解決するために、ダウンロード ページから 以降をダウンロードしてください。

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

エラー メッセージに示された構成ファイルを名前空間ディレクトリに移動します。

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

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

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

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

構成で、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/ ディレクトリで名前空間を直接宣言しないでください。

エラー メッセージに記載されている名前空間構成ファイルのサブディレクトリを作成します。詳細については、階層型リポジトリの構造をご覧ください。

階層型リポジトリ構造を使用する場合、名前空間構成ファイルに metadata.name を宣言します。その値は名前空間のディレクトリの名前と一致する必要があります。 名前空間の metadata.name またはそのディレクトリを修正します。

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

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

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

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

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

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

ディレクトリ名は 64 文字未満で、小文字の英数字または「-」で構成します。先頭と末尾には英数字を使用する必要があります。

名前の異なるディレクトリの名前を変更するか、削除します。

同じ種類の構成ファイルには、同じ名前空間とその親の抽象名前空間内で一意の名前を付ける必要があります。

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

同じディレクトリに複数の名前空間リソースを配置することはできません。

重複する構成ファイルを削除して、名前空間リソースが 1 つも残らないようにします。

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

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

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

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

階層型リポジトリを使用する場合、system/ ディレクトリ内で宣言できる種類は HierarchyConfig と Repo だけです。

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

config-management-system 名前空間やその中のリソースを宣言することは禁止されています。

Config Sync バージョン 1.17.0 以降では、名前空間 resource-group-system と config-management-monitoring も信頼できる情報源で宣言できません。また、resource-group-system および config-management-monitoring 名前空間にリソースを宣言することもおすすめしません。

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

resource-group-system または config-management-monitoring 名前空間を宣言した場合は、コントローラの名前空間を管理対象外にします。

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

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

指定された metadata.name は無効な形式です。

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

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

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

名前空間スコープ オブジェクトを 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 に無効な名前があります。

エラー メッセージにある名前を推奨値に変更します。

構成では、非推奨のグループと種類が使用されています。

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

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

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

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

欠落しているフィールドを、名前空間スコープのリソースに追加します。

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

エラー メッセージの手順に沿ってエラーを解決してください。

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

次のルールに従うように、metadata.namespace の値を更新します。

  • 長さが 63 文字以下である
  • 小文字（az）、数字（0 ～ 9）、ハイフン（-）のみを使用する
  • 先頭と末尾は小文字または数字

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

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

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

エラー メッセージにリストされている不正なラベルを削除します。

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

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

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

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

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

 1 つを除くすべての Kptfile リソースを削除します。

複数の信頼できる情報源のオブジェクトを管理する場合、同じオブジェクト（一致するグループ、種類、名前、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 の再実行が必要になる場合があります。

nomos バージョン 1.16.1 以前では、次のエラーも表示されます: KNV1064: unable to find APIGROUP column。このエラーは、列名を APIGROUP から APIVERSION に変更したことが原因で発生します。この問題を軽減するには、api-resources.txt の APIVERSION を手動で APIGROUP に戻します。

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

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

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

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

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

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

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

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 は有効なファイル名ではありません。この問題を解決するには、ファイル名またはパス名から特殊文字を削除します。

API サーバーにアクセスするリクエストが失敗します。

API 検出エラーが発生している可能性があります。詳細については、API 検出のエラーをご覧ください。

OS レベルの一般的なシステムコールが失敗します。

Config Sync は信頼できる情報源からの読み取りはできません。

このエラーの原因として複数の問題が考えられます。信頼できる情報源への接続に関する一般的な問題を解決する方法のヒントについては、信頼できる情報源への接続のトラブルシューティングをご覧ください。

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 で最後のリソースを削除します。

Config Sync もその変更を試みる間に、API サーバー上のリソースが変更または削除されます。

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

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

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

このエラーの原因として複数の問題が考えられます。同期に関する一般的な問題の解決方法については、同期のトラブルシューティングをご覧ください。

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

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

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

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

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

追加の APIResource を削除します。

名前空間のリコンシラに、リソースを管理するための十分な権限がありません。

リコンサイラに十分な権限があることを確認してください。

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

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

レンダリング プロセスで内部エラーが発生しました。たとえば、Config Sync はファイル システムにアクセスできません。

このエラーは、Pod が正常でないことを示している可能性があります。次のコマンドを実行して、調整 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

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

エラーは自動的に解決されるはずです。

nomos コマンドライン ツール自体に問題がある。

実行した正確なコマンドと発生したメッセージを記載したバグレポートを提出してください。

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

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

トップへ戻る

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 が有効になっている場合に発生します。

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

IAM を設定してもエラーが解決しない場合は、otel-collector Pod を再起動して変更を有効にします。
カスタム モニタリング ソリューションを使用しているものの、デフォルトの otel-collector-googlecloud ConfigMap をフォークしている場合は、違いを確認してリベースします。

server certificate verification failed. CAfile:/etc/ca-cert/cert CRLfile: none

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

git-sync コンテナによる Git リポジトリのクローン作成が失敗すると、このエラー メッセージが表示されることがあります。

このメッセージは、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 証明書を取得するようリクエストできます。

Error message: "MESSAGE": "Unable to retrieve pull secret, the image pull may not succeed."

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

GKE on VMware で限定公開レジストリを使用すると、Config Sync のインストールまたはアップグレードが停止する可能性があります。このメッセージのようなエラーが表示されます。

この問題を解決するには、Config Sync をインストールまたはアップグレードする前に、非公開レジストリを使用して Config Sync を更新するの手順を行ってください。

Permission 'gkehub.features.create' denied on 'projects/PROJECT_ID/locations/global/features/configmanagement'

権限が却下されました

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

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

トップへ戻る

次のステップ