Fehlerreferenz

Auf dieser Seite werden Config Sync-Fehlercodes und empfohlene Maßnahmen zum Beheben dieser Fehler beschrieben.

Config Sync-Fehlermeldungen enthalten eine Fehler-ID im Format KNV1234, wobei 1234 eine eindeutige Nummer ist, gefolgt von einer Beschreibung des Problems und einem Vorschlag zur Behebung. K wird von den Kubernetes-Konventionen übernommen, Regeln mit dem Präfix N gelten spezifisch für nomos und V bezieht sich speziell auf Fehler, die im Anfangszustand des Repositorys und des Clusters erkannt werden können. Codes für Fehler, die im Anfangszustand des Repositorys und des Clusters erkennbar sind, haben die Form KNV1XXX. Codes für Fehler, die nur während der Laufzeit erkannt werden können, haben das Format KNV2XXX.

KNV-Fehlertabelle

Fehlercode Beschreibung Empfohlene Maßnahmen

Die ID von InternalError wurde mit Config Sync-Version 1.6.1 zu KNV9998 geändert.

–

In Config Sync 1.3 verworfen.

–

In Config Sync 1.3 verworfen.

–

Bei Verwendung einer hierarchischen Repository-Struktur darf ein Verzeichnis, das eine Namespace-Konfiguration enthält, keine Unterverzeichnisse enthalten.

Ein Verzeichnis ohne Namespace-Konfiguration ist ein abstraktes Namespace-Verzeichnis, aus dessen Verzeichnissen übernommen werden. Daher müssen abstrakte Namespace-Verzeichnisse Unterverzeichnisse haben. Ein Verzeichnis, das eine Namespace-Konfiguration enthält, ist ein Namespace-Verzeichnis und kann nicht übernommen werden. Daher darf es keine Unterverzeichnisse enthalten.

Entfernen Sie entweder die Namespace-Konfiguration aus dem übergeordneten Verzeichnis oder verschieben Sie das Unterverzeichnis an einen anderen Ort.

Ein clusterbezogenes Objekt darf nicht die Annotation configmanagement.gke.io/namespace-selector deklarieren. NamespaceSelectors können nur für Namespace-bezogene Objekte deklariert werden.

Entfernen Sie configmanagement.gke.io/namespace-selector aus dem Feld metadata.annotations.

Die einzige gültige Einstellung für die Verwaltungsanmerkung ist configmanagement.gke.io/managed=disabled. Diese Einstellung wird verwendet, um die Verwaltung einer Ressource im Git-Repository explizit aufzuheben, während die Konfiguration eingecheckt bleibt. Die Annotation configmanagement.gke.io/managed=enabled ist nicht erforderlich.

Die Verwaltungsannotation muss configmanagement.gke.io/managed=disabled sein.

Weitere Informationen finden Sie unter Objekte verwalten.

Ein im Repository deklariertes Objekt konnte nicht geparst werden.

Prüfen Sie Ihr YAML-Format. Sie können beispielsweise den Befehl kubectl --validate verwenden.

Wenn nomos vet diesen Fehler für einen Typ mit group: configsync.gke.io zurückgibt (z. B. RepoSync), laden Sie zur Behebung v1.6.0-rc.6 oder höher von der Downloadseite herunter.

Bei Verwendung eines unstrukturierten Repositorys dürfen Konfigurationen nicht in einem abstrakten Namespace-Verzeichnis deklariert werden.

Verschieben Sie die in der Fehlermeldung aufgeführte Konfiguration in ein Namespace-Verzeichnis.

Weitere Informationen finden Sie unter Unstrukturiertes Repository verwenden.

Wenn Sie eine hierarchische Repository-Struktur verwenden, müssen Konfigurationen entweder Namespaces deklarieren, die dem Namespace-Verzeichnis entsprechen, das sie enthalten, oder das Feld weglassen.

Aktualisieren Sie das in der Fehlermeldung angegebene Namespace-Feld.

Weitere Informationen finden Sie unter Struktur des hierarchischen Repositorys.

Konfigurationen dürfen keine nicht unterstützten Annotationen deklarieren, die mit configmanagement.gke.io beginnen.

Achten Sie darauf, eine der folgenden unterstützten Annotationen zu verwenden:

  • configmanagement.gke.io/managed. Weitere Informationen finden Sie unter Objekte verwalten.
  • configmanagement.gke.io/namespace-selector. Weitere Informationen finden Sie unter Namespace-bezogene Objekte.
  • configmanagement.gke.io/cluster-selector. Weitere Informationen finden Sie unter ClusterSelectors.

Konfigurationen dürfen keine Labels mit Schlüsseln haben, die mit configmanagement.gke.io/ beginnen. Dieses Labelschlüsselpräfix ist für die Verwendung durch Config Sync reserviert.

Aktualisieren Sie alle in der Fehlermeldung angegebenen Labels. Wenn Sie beispielsweise versucht haben, ein Label mit dem Namen
configmanagement.gke.io/example-label: label-value,
zu deklarieren, könnten Sie es in
example-label: label-value ändern.

In Config Sync 1.3 verworfen.

 –

Die Konfiguration verweist auf einen nicht vorhandenen ClusterSelector oder NamespaceSelector. Bevor Sie einen Selektor in einer Annotation für eine Konfiguration verwenden können, muss der Selektor vorhanden sein.

Erstellen Sie entweder fehlende Selektoren oder entfernen Sie alle Konfigurationen, die sich darauf beziehen, falls der Selektor entfernt wurde.

ClusterSelector- und NamespaceSelector-Konfigurationen verwenden die richtige Syntax, es wurde jedoch ein Syntaxfehler gefunden.

Geben Sie die Konfiguration mit dem entsprechenden Datenschema an:

In Config Sync 1.3.2 verworfen. –

Wenn Sie die hierarchische Repository-Struktur verwenden, muss im Verzeichnis system/ des Repositorys eine Konfiguration für den ConfigManagement Operator vorhanden sein. Diese Konfiguration muss erforderliche Informationen wie die semantische Version des Repositorys enthalten.

Definieren Sie mindestens eine Mindestkonfiguration für den ConfigManagement Operator. Weitere Informationen finden Sie unter Struktur des hierarchischen Repositorys.

In Config Sync 1.3 verworfen. –

Bei Verwendung der hierarchischen Repository-Struktur dürfen Namespaces nicht direkt im Verzeichnis namespaces/ deklariert werden.

Erstellen Sie ein Unterverzeichnis für die in der Fehlermeldung aufgeführten Namespace-Konfigurationen. Weitere Informationen finden Sie unter Struktur des hierarchischen Repositorys.

Bei Verwendung einer hierarchischen Repository-Struktur deklariert eine Namespace-Konfiguration metadata.name und der Wert muss mit dem Namen des Namespace-Verzeichnisses übereinstimmen. Korrigieren Sie die metadata.name des Namespace oder sein Verzeichnis.

Für die Ressource im Cluster ist keine CustomResourceDefinition definiert.

Erstellen Sie eine CustomResourceDefinition für die Ressource, auf die in der Fehlermeldung verwiesen wird. Ressourcentypen, die keine integrierten Kubernetes-Objekte sind, müssen eine CustomResourceDefinition haben.

Wenn Sie ein hierarchisches Repository verwenden, können Konfigurationen dieser Art nicht im Verzeichnis system/ deklariert werden.

Verschieben Sie die Ressource, auf die in der Fehlermeldung verwiesen wird, aus dem Verzeichnis system/. Weitere Informationen finden Sie unter Struktur des hierarchischen Repositorys.

Das Feld spec.version in der Repository-Konfiguration steht für die semantische Version des Repositorys. Dieser Fehler weist darauf hin, dass Sie eine nicht unterstützte Version verwenden.

Wenn das Format Ihres Repositorys mit der unterstützten Version kompatibel ist, aktualisieren Sie das Feld spec.version. Wenn Sie ein Upgrade durchführen müssen, können Sie sich an die Anleitung in den Versionshinweisen halten.

Verzeichnisnamen müssen weniger als 64 Zeichen lang sein, aus alphanumerischen Kleinbuchstaben oder „-“ bestehen und mit einem alphanumerischen Zeichen beginnen und enden.

Benennen Sie das Verzeichnis um oder entfernen Sie es.

Konfigurationen derselben Art müssen eindeutige Namen im selben Namespace und in ihren übergeordneten abstrakten Namespaces haben.

Benennen Sie alle Konfigurationen um, auf die in der Fehlermeldung verwiesen wird, oder entfernen Sie sie, sodass sie eindeutige Namen haben.

Mehrere Namespace-Ressourcen dürfen nicht im selben Verzeichnis vorhanden sein.

Entfernen Sie die doppelten Konfigurationen, damit nicht mehr als eine Namespace-Ressource übrig bleibt.

Alle Konfigurationen müssen metadata.name deklarieren.

Fügen Sie den problematischen Konfigurationen das Feld metadata.name hinzu.

Der Typ Repo.configmanagement.gke.io ist nicht zulässig, wenn sourceFormat auf unstructured festgelegt ist.

Entfernen Sie die problematische Konfiguration oder konvertieren Sie Ihr Repository zur Verwendung von sourceFormat: hierarchy.

Wenn Sie ein hierarchisches Repository verwenden, können Sie nur die Arten HierarchyConfig und Repo im Verzeichnis system/ deklarieren.

Achten Sie darauf, dass alle im Verzeichnis system/ deklarierten Konfigurationen zu den zulässigen Arten gehören. Ist dies nicht der Fall, verschieben Sie sie in ein anderes Verzeichnis.

Der config-management-system-Namespace oder die darin enthaltenen Ressourcen dürfen nicht deklariert werden.

Ab Config Sync Version 1.17.0 können auch die Namespaces resource-group-system und config-management-monitoring nicht mehr in einer „Source of Truth“ deklariert werden. Es wird auch nicht empfohlen, Ressourcen unter den Namespaces resource-group-system und config-management-monitoring zu deklarieren.

Wenn Sie den Namespace config-management-system deklariert haben, entfernen Sie ihn und alle Konfigurationen in diesem Namespace.

Wenn Sie die Namespaces resource-group-system oder config-management-monitoring deklariert haben, heben Sie die Verwaltung des Controller-Namespace auf:

  1. Aktualisieren Sie Config Sync, um die Verwaltung des Namespace und der darunter deklarierten Ressourcen zu beenden.
  2. Warten Sie auf eine Synchronisierung und prüfen Sie dann, ob die entsprechenden Ressourcen noch im Cluster, aber nicht in nomos status verfügbar sind.
  3. Entfernen Sie die YAML-Datei für den Controller-Namespace aus der Quelle.
  4. Lassen Sie Config Sync die Verwaltung der Ressourcen fortsetzen.

Wenn Sie zuvor eine Synchronisierung mit einem hierarchischen Repository durchgeführt haben und den Controller-Namespace zusammen mit allen Ressourcen deklarieren mussten, sollten Sie für mehr Flexibilität in Ihrer Quellstruktur zu einem unstrukturierten Repository wechseln.

Das angegebene metadata.name hat ein ungültiges Format.

Ändern Sie metadata.name so, dass die folgenden Bedingungen erfüllt sind:

  • kürzer als 254 Zeichen sein
  • Er muss aus alphanumerischen Kleinbuchstaben, „-“ oder „.“ bestehen
  • Muss mit einem alphanumerischen Zeichen beginnen und enden

Wenn metadata.name ungültig ist und die ursprüngliche Ressource dies unterstützt, sollten Sie stattdessen das Feld spec.resourceID verwenden, damit Sie nicht durch diese Einschränkungen eingeschränkt werden. Weitere Informationen finden Sie unter Ressourcen mit dem Feld „resourceID“ verwalten.

In Config Sync 1.3 verworfen. –

Namespace-bezogene Objekte dürfen außerhalb des Verzeichnisses namespaces/ nicht deklariert werden.

Verschieben Sie die problematischen Konfigurationen so, dass sie sich in einem legalen Verzeichnis befinden. Weitere Informationen zu Namespace-bezogenen Objekten finden Sie unter Namespace-bezogene Objekte.

Clusterbezogene Objekte dürfen außerhalb des Verzeichnisses cluster/ nicht deklariert werden.

Verschieben Sie die problematischen Konfigurationen so, dass sie sich in einem legalen Verzeichnis befinden. Weitere Informationen zu clusterbezogenen Objekten finden Sie unter Clusterbezogene Objekte.

In Config Sync 1.3 verworfen. –

Diese Ressourcenart darf nicht in einem HierarchyConfig deklariert werden.

Entfernen Sie die problematische Ressource. Weitere Informationen zu HierarchyConfig finden Sie unter Übernahme für einen Objekttyp deaktivieren.

Auf einem HierarchyConfig wurde ein ungültiger Wert für HierarchyMode erkannt.

Ändern Sie HierarchyMode in none oder inherit. Weitere Informationen zu HierarchyConfigs finden Sie unter Übernahme für einen Objekttyp deaktivieren.

Config Sync kann dieses Objekt nicht konfigurieren.

 Entfernen Sie die problematische Konfiguration aus dem Repository.

Ein abstraktes Namespace-Verzeichnis mit Konfigurationen muss mindestens ein Namespace-Unterverzeichnis haben.

Fügen Sie entweder ein Namespace-Verzeichnis unter Ihrem abstrakten Namespace-Verzeichnis hinzu, fügen Sie Ihrem abstrakten Namespace-Verzeichnis eine Namespace-Konfiguration hinzu oder entfernen Sie die Konfigurationen in Ihrem abstrakten Namespace-Verzeichnis.

Konfigurationen, für die metadata.ownerReference angegeben ist, sind nicht zulässig.

Entfernen Sie das Feld status aus dem Quell-Repository. Verwenden Sie für Drittanbieterkonfigurationen, die Ihnen nicht gehören, kustomize patches, um status-Felder, die in Ihren Manifesten angegeben sind, im Bulk zu entfernen.

Dieser HierarchyConfig verweist auf eine Ressource mit Clusterbereich. Clusterbezogene Objekte sind in HierarchyConfig nicht zulässig.

Aktualisieren Sie HierarchyConfig, damit sie nicht mehr auf die problematische Ressource verweist.

Eine benutzerdefinierte Ressourcendefinition (CRD) kann nicht entfernt werden und die entsprechenden benutzerdefinierten Ressourcen im Repository bleiben.

Entfernen Sie die CRD zusammen mit den benutzerdefinierten Ressourcen.

Die CustomResourceDefinition hat einen ungültigen Namen.

Ändern Sie den Namen in die Empfehlung aus der Fehlermeldung.

Die Konfiguration verwendet eine verworfene Gruppe und Art.

Ändern Sie die Gruppe oder Art in die Empfehlung, die in der Fehlermeldung angegeben ist.

Clusterbezogene Ressourcen dürfen metadata.namespace nicht deklarieren.

 Entfernen Sie das Feld metadata.namespace aus der clusterbezogenen Ressource.

Namespace-bezogene Ressourcen müssen entweder metadata.namespace oder metadata.annotations.configmanagement.gke.io/namespace-selector deklarieren.

Fügen Sie der Namespace-bezogenen Ressource das fehlende Feld hinzu.

Konfigurationen enthalten einen ungültigen Wert für eine Annotation.

Folgen Sie der Anleitung in der Fehlermeldung, um den Fehler zu beheben.

Der Wert von metadata.namespace ist kein gültiger Kubernetes-Namespace-Name.

Aktualisieren Sie den Wert von metadata.namespace so, dass er den folgenden Regeln entspricht:

  • Er darf maximal 63 Zeichen lang sein.
  • Besteht nur aus Kleinbuchstaben (a–z), Ziffern (0–9) und Bindestrichen (-)
  • Beginnt und endet mit einem Kleinbuchstaben oder einer Ziffer

Eine Ressource wird in einem nicht verwalteten Namespace deklariert.

Entfernen Sie entweder die Annotation configmanagement.gke.io/managed: disabled oder fügen Sie sie der deklarierten Ressource hinzu.

Eine Ressource hat ein ungültiges Label.

Entfernen Sie die in der Fehlermeldung aufgeführten unzulässigen Labels.

Ein Namespace-Repository kann nur Namespace-bezogene Ressourcen in dem Namespace deklarieren, für das das Repository gilt.

Achten Sie darauf, dass alle Namespace-Repositories Namespace-bezogene Ressourcen korrekt deklarieren. Mit dem Repository für das Namespace-Repository shipping können beispielsweise nur Ressourcen im Namespace shipping verwaltet werden. Der Wert von metadata.namespace ist optional. Standardmäßig geht Config Sync davon aus, dass alle Ressourcen in einem Namespace-Repository zu diesem Namespace gehören.

Wenn beispielsweise eine Konfiguration im Namespace-Repository shipping metadata.namespace: billing deklariert würde, wird ein Fehler ausgegeben.

Achten Sie nicht nur darauf, dass Namespace-bezogene Ressourcen korrekt deklariert sind, sondern auch, dass Namespaces im Root-Repository deklariert sind. Dies ist erforderlich, da Namespaces clusterbezogen sind.

Ein Namespace-Repository kann höchstens eine Kptfile-Ressource deklarieren.

 Entfernen Sie alle Kptfile-Ressourcen bis auf eine.

Bei der Verwaltung von Objekten in mehreren „Sources of Truth“ können Konflikte auftreten, wenn dasselbe Objekt (übereinstimmende Gruppe, Art, Name und Namespace) in mehr als einer Quelle deklariert wird.

Wenn beispielsweise dasselbe Objekt über RootSync und RepoSync verwaltet wird, gewinnt RootSync. Wenn RootSync zuerst angewendet wird, meldet RepoSync einen KNV1060-Statusfehler. Wenn RepoSync zuerst angewendet wird, überschreibt RootSync das RepoSync-Objekt und RepoSync meldet einen KNV1060-Statusfehler, wenn das Update erkannt wird.

Lösen Sie den Konflikt, indem Sie die Konfiguration so aktualisieren, dass sie mit der anderen „Source of Truth“ übereinstimmt, oder das in Konflikt stehende Objekt aus einer der Quellen löschen.

Der Befehl nomos vet prüft nur jeweils in einem Repository nach Fehlern, sodass dieses Problem nicht erkannt werden kann.

InvalidRepoSyncError meldet, dass RepoSync falsch konfiguriert ist. RepoSync-Objekte müssen ordnungsgemäß konfiguriert sein, damit Config Sync die Konfiguration aus Namespace-Repositories synchronisiert.

Folgen Sie der Anleitung in der Fehlermeldung, um die Konfigurationsfehler zu beheben.

Die Kptfile enthält kein gültiges Inventarfeld. Eine Kptfile muss ein nicht leeres Inventarfeld enthalten, in dem sowohl die ID als auch der Namespace angegeben sind.

Geben Sie die Werte für .inventory.identifier und .inventory.namespace in der Kptfile an.

Kptfiles wurden im Root-Repository gefunden. Kptfiles werden nur in Namespace-bezogenen Repositories unterstützt.

Entfernen Sie die Kptfiles aus dem Root-Repository.

Die Datei api-resources.txt in Ihrem Repository konnte nicht geparst werden.

Folgen Sie der Anleitung in der Fehlermeldung. Möglicherweise müssen Sie beispielsweise kubectl api-resources > api-resources.txt noch einmal ausführen.

In nomos-Version 1.16.1 und niedriger wird auch dieser Fehler angezeigt: KNV1064: unable to find APIGROUP column. Dieser Fehler wird durch die Änderung des Spaltennamens von APIGROUP in APIVERSION verursacht. Um dieses Problem zu beheben, ersetzen Sie APIVERSION in api-resources.txt manuell durch APIGROUP.

Die CustomResourceDefinition ist fehlerhaft.

Prüfen Sie, ob das in der Fehlermeldung angegebene Feld richtig formatiert ist.

Ein Konfigurationsobjekt muss nur eine Annotation für die Clusterauswahl deklarieren. Dieser Fehler tritt auf, wenn sowohl die Legacy-Annotation (configmanagement.gke.io/cluster-selector) als auch die Inline-Annotation (configsync.gke.io/cluster-name-selector) vorhanden sind.

Entfernen Sie eine der Anmerkungen aus dem Feld metadata.annotations.

Die deklarierten Felder werden vom Abgleich nicht in einem Format codiert, das mit server-side apply kompatibel ist. Dies kann durch ein veraltetes Schema verursacht werden.

Prüfen Sie, ob das in der Fehlermeldung angegebene Feld mit dem Schema der Ressourcenart übereinstimmt.

Beim Rendering ist ein Problem aufgetreten, das vom Nutzer behoben werden kann.

Wenn das Git-Repository Kustomize-Konfigurationen enthält, aber keine kustomization.yaml-Datei im Git-Synchronisierungsverzeichnis vorhanden ist, fügen Sie entweder kustomization.yaml im Synchronisierungsverzeichnis hinzu, um den Renderingprozess auszulösen, oder entfernen Sie kustomization.yaml aus allen Unterverzeichnissen, um das Rendering zu überspringen.

Wenn der Fehler durch kustomize build-Fehler verursacht wird, müssen Sie möglicherweise die Kustomize-Konfigurationen in Ihrem Git-Repository aktualisieren. Sie können sich die aktualisierten Konfigurationen lokal mit nomos hydrate und nomos vet als Vorschau ansehen und validieren. Wenn die aktualisierten Konfigurationen erfolgreich gerendert werden, können Sie einen neuen Commit übertragen, um den KNV1068-Fehler zu beheben.

Wenn beim Abrufen von Remote-Basen aus öffentlichen Repositories der Fehler kustomize build auftritt, müssen Sie spec.override.enableShellInRendering auf true setzen.

Ein Abgleicher hat sein eigenes RootSync- oder RepoSync-Objekt abgeglichen. Ein RootSync-Objekt kann andere RootSync- und RepoSync-Objekte verwalten. Ein RepoSync-Objekt kann andere RepoSync-Objekte verwalten, aber nicht selbst verwalten.

Entfernen Sie das RootSync- oder RepoSync-Objekt aus der „Source of Truth“, mit der das Objekt synchronisiert wird.

Ein Systemaufruf auf Betriebssystemebene, der auf eine Dateisystemressource zugreift, schlägt fehl.

Dieser Fehler wird wahrscheinlich durch eine ungültige YAML-Konfiguration oder die Verwendung von Sonderzeichen verursacht. Wenn Sie eine ungültige YAML-Konfiguration haben, wird eine Fehlermeldung wie diese angezeigt: KNV2001: yaml: line 2: did not find expected node content path:.... Prüfen Sie Ihre YAML-Dateien und beheben Sie etwaige Konfigurationsprobleme, um dieses Problem zu beheben. Dies kann durch eine beliebige YAML-Konfiguration im Repository verursacht werden.

Wenn der Dateiname oder Pfad Sonderzeichen enthält, wird möglicherweise eine Fehlermeldung wie KNV2001: yaml: control characters are not allowed path:/repo/source/.../._pod.yaml angezeigt. In diesem Beispiel ist ._pod.yaml kein gültiger Dateiname. Entfernen Sie Sonderzeichen aus den Datei- oder Pfadnamen, um dieses Problem zu beheben.

Eine Anfrage, die auf den API-Server zugreift, schlägt fehl.

Möglicherweise tritt ein API-Erkennungsfehler auf. Weitere Informationen finden Sie unter API-Erkennungsfehler.

Ein allgemeiner Systemaufruf auf Betriebssystemebene schlägt fehl.

Config Sync kann nicht aus der Source of Truth lesen.

Dieser Fehler kann verschiedene Ursachen haben. Tipps zur Behebung häufiger Probleme beim Herstellen einer Verbindung zur „Source of Truth“ finden Sie hier.

Config Sync konkurriert mit einem anderen Controller um eine Ressource. Solche Streitigkeiten verbrauchen große Mengen an Ressourcen und können die Leistung beeinträchtigen. Tipps zur Diagnose und Behebung von Controller-Kämpfen findest du unter Fehlerbehebung bei Controller-Kämpfen.

Um versehentliches Löschen zu verhindern, können Sie mit Config Sync nicht alle Namespaces oder clusterbezogenen Ressourcen in einem einzelnen Commit entfernen.

Wenn der Config Sync-Zulassungs-Webhook deaktiviert ist, setzen Sie den Commit zurück, durch den alle Ressourcen gelöscht werden.
Wenn der Zulassungs-Webhook von Config Sync aktiviert ist, kann es sein, dass Ihr Namespace nicht mehr beendet wird. Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Deaktivieren Sie Config Sync und warten Sie, bis alle Ressourcen bereinigt wurden oder sich in einem stabilen Status befinden. Sie können beispielsweise kubectl get ns ausführen, um sicherzustellen, dass die Namespaces gelöscht werden.
  2. Aktivieren Sie Config Sync wieder.
  3. Setzen Sie den Commit zurück, der alle Ressourcen löscht.

Wenn Sie alle verwalteten Ressourcen löschen möchten, führen Sie die folgenden Schritte aus:

  1. Entfernen Sie alle Namespace- oder clusterbezogenen Ressourcen in einem ersten Commit und lassen Sie zu, dass Config Sync diese Änderungen synchronisiert.
  2. Entfernen Sie die letzte Ressource in einem zweiten Commit.

Eine Ressource auf dem API-Server wird geändert oder gelöscht, während Config Sync ebenfalls versucht, sie zu ändern.

Wenn diese Art von Fehler nur beim Start oder selten auftritt, können Sie sie ignorieren.

Wenn diese Fehler nicht vorübergehend sind (mehrere Minuten andauern), kann dies auf ein schwerwiegendes Problem hindeuten und nomos status meldet Controller-Kämpfe.

Dies ist ein allgemeiner Fehler, der darauf hinweist, dass Config Sync einige Konfigurationen nicht mit dem Cluster synchronisieren konnte.

Dieser Fehler kann verschiedene Ursachen haben. Tipps zur Behebung häufiger Probleme bei der Synchronisierung finden Sie unter Fehlerbehebung bei der Synchronisierung.

Dies ist ein allgemeiner Fehler, der auf ein Problem mit einer Ressource oder einer Gruppe von Ressourcen hinweist.

Die Fehlermeldung enthält die spezifischen Ressourcen, die den Fehler verursacht haben. Sehen Sie sich diese Ressourcen an.

Zum Fortfahren ist eine bestimmte Ressource erforderlich, die jedoch nicht gefunden wurde. Beispiel: Der ConfigManagement Operator hat versucht, eine Ressource zu aktualisieren, aber die Ressource wurde beim Berechnen der Aktualisierung gelöscht.

Erstellen Sie die fehlende Ressource oder stellen Sie sie wieder her.

Dieser Fehler meldet, dass mehr als eine Instanz einer APIResource in einem Kontext gefunden wurde, in dem genau eine dieser APIResource-Instanzen zulässig ist. In einem Cluster darf beispielsweise nur eine Repo-Ressource vorhanden sein.

Entfernen Sie die zusätzliche APIResource.

Ein Namespace-Abgleicher hat nicht genügend Berechtigungen zum Verwalten von Ressourcen.

Prüfen Sie, ob der Abgleicher die erforderlichen Berechtigungen hat.

Diese Warnung wird angezeigt, wenn die Config Sync-Webhook-Konfiguration illegal geändert wird. Die ungültigen Webhook-Konfigurationen werden ignoriert.

Entfernen Sie den illegal geänderten Webhook.

Beim Rendering ist ein internes Problem aufgetreten. Config Sync kann beispielsweise nicht auf das Dateisystem zugreifen.

Dieser Fehler kann darauf hindeuten, dass der Pod nicht fehlerfrei ist. Sie können die Abgleich-Pods neu starten, indem Sie die folgenden Befehle ausführen:


# 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

Dieser Fehler ist ein vorübergehendes Problem, das später automatisch behoben werden sollte. Wenn der Renderingstatus beispielsweise nicht mit der Quellkonfiguration übereinstimmt, wird möglicherweise dieser Fehler angezeigt.

Der Fehler sollte automatisch behoben werden.

Es gibt ein Problem mit dem nomos-Befehlszeilentool.

Senden Sie einen Fehlerbericht, der genau den Befehl enthält, den Sie ausgeführt haben, und die Meldung, die Sie erhalten haben.

Es ist ein Fehler aufgetreten, für den keine Fehlermeldung vorliegt.

Wir haben noch keine Dokumentation zu dem aufgetretenen Fehler verfasst.

Nach oben

Fehlermeldungen ohne KNV-Code

Fehler, die von Config Sync-Abgleichen gemeldet werden, haben den KNV-Fehlercode, aber Fehler, die von anderen Komponenten gemeldet werden, haben keinen KNV-Code. Der Fehler „Berechtigung verweigert“ stammt beispielsweise vom Flottencontroller, der eine Ebene über Config Sync ist.

In der folgenden Tabelle sind einige häufige Fehler ohne das KNV-Präfix aufgeführt.

Fehlermeldung Empfohlene Maßnahmen

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).

Exporter können nicht erstellt werden

Wenn eine Komponente in Open Telemetry Collector nicht auf das Standarddienstkonto unter demselben Namespace zugreifen kann, stellen Sie möglicherweise fest, dass der Pod otel-collector unter config-management-monitoring den CrashLoopBackoff-Status hat oder dass eine ähnliche Fehlermeldung angezeigt wird.

Dieses Problem tritt normalerweise auf, wenn Workload Identity in einem Cluster aktiviert ist.

Folgen Sie der Anleitung in Monitoring Config Sync, um dem Standarddienstkonto die Berechtigung zum Schreiben von Messwerten zu gewähren.

Wenn der Fehler nach dem Einrichten von IAM weiterhin besteht, starten Sie den otel-collector-Pod neu, damit die Änderungen wirksam werden.
Wenn Sie eine benutzerdefinierte Monitoringlösung verwenden, aber die Standard-otel-collector-googlecloud-ConfigMap abgespalten haben, prüfen Sie alle Unterschiede und stützen Sie sie neu.

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

Serverzertifikatüberprüfung fehlgeschlagen

Wenn der git-sync-Container das Git-Repository nicht klonen kann, wird diese Fehlermeldung möglicherweise angezeigt.

Diese Nachricht gibt an, dass der Git-Server mit Zertifikaten von einer benutzerdefinierten Zertifizierungsstelle konfiguriert ist. Da die benutzerdefinierte Zertifizierungsstelle jedoch nicht richtig konfiguriert ist, kann der Container git-sync das Git-Repository nicht klonen.

Zur Behebung dieses Problems können Sie zuerst prüfen, ob das Feld spec.git.caCertSecretRef.name in Ihrem RootSync- oder RepoSync-Objekt angegeben wurde und ob das Secret-Objekt vorhanden ist.

Wenn das Feld konfiguriert wurde und das Secret-Objekt vorhanden ist, prüfen Sie als Nächstes, ob das Secret-Objekt die vollständigen Zertifikate enthält.
Je nachdem, wie die benutzerdefinierte Zertifizierungsstelle bereitgestellt wird, können die Ansätze zur Überprüfung der vollständigen Zertifikate variieren.

Hier ist ein Beispiel dafür, wie die Serverzertifikate aufgelistet werden können: 


echo -n | openssl s_client -showcerts -connect HOST:PORT -servername SERVER_NAME 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Sie können Ihr Netzwerkverwaltungsteam bitten, die CA-Zertifikate für Sie abzurufen.

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

Pull-Secret kann nicht abgerufen werden. Der Image-Abruf ist möglicherweise nicht erfolgreich.

Wenn Sie eine private Registry mit GKE on VMware verwenden, kann die Installation oder das Upgrade von Config Sync hängen bleiben. Es wird ein Fehler wie diese Meldung angezeigt.

Führen Sie die Schritte unter Config Sync mit einer privaten Registry aktualisieren aus, bevor Sie Config Sync installieren oder aktualisieren, um dieses Problem zu beheben.

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

Berechtigung verweigert

Wenn Sie beim Konfigurieren von Config Sync einen Fehler wie in diesem Beispiel erhalten, haben Sie möglicherweise nicht die Rolle GKE-Hub-Administrator.

Prüfen Sie, ob Sie die erforderlichen IAM-Rollen gewährt haben, damit Sie die erforderlichen Berechtigungen haben.

Nach oben

Nächste Schritte