Fehlerreferenz

Auf dieser Seite werden Config Sync-Fehlercodes und empfohlene Maßnahmen zur Behebung 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 Kubernetes-Konventionen übernommen. Regeln mit dem Präfix N sind spezifisch für nomos. V ist spezifisch für Fehler, die im Ausgangszustand des Repositorys und des Clusters erkannt werden können. Codes für Fehler, die im Ausgangszustand des Repositorys und des Clusters erkennbar sind, haben das Format KNV1XXX. Codes für Fehler, die nur zur Laufzeit erkannt werden können, haben das Format KNV2XXX.

KNV-Fehlertabelle

Fehlercode Beschreibung Empfohlene Maßnahmen

Die ID von InternalError wurde in Config Sync 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 mit einer Namespace-Konfiguration keine Unterverzeichnisse enthalten.

Ein Verzeichnis ohne Namespace-Konfiguration ist ein abstraktes Namespace-Verzeichnis, aus dem Verzeichnisse Objekte übernehmen. Daher müssen abstrakte Namespace-Verzeichnisse Unterverzeichnisse haben. Ein Verzeichnis mit einer Namespace-Konfiguration ist ein Namespace-Verzeichnis, aus dem keine Objekte übernommen werden können. Daher darf es keine Unterverzeichnisse enthalten.

Entfernen Sie 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 dürfen 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 Verwaltungsannotation ist configmanagement.gke.io/managed=disabled. Diese Einstellung wird verwendet, um die Verwaltung einer Ressource im Git-Repository explizit aufzuheben, wobei die Konfiguration eingecheckt bleibt. Die Annotation configmanagement.gke.io/managed=enabled ist nicht erforderlich.

Prüfen Sie, ob die Verwaltungsanmerkung configmanagement.gke.io/managed=disabled lautet.

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 bei einem Typ mit group: configsync.gke.io zurückgibt, z. B. einer RepoSync, laden Sie v1.6.0-rc.6 oder höher von der Downloadseite herunter, um ihn zu beheben.

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.

Bei Verwendung einer hierarchischen Repository-Struktur müssen Konfigurationen entweder Namespaces deklarieren, die mit dem Namespace-Verzeichnis übereinstimmen, in dem sie enthalten sind, 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, dass Sie eine der folgenden unterstützten Anmerkungen 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üssel-Prä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önnen 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 alle fehlenden Selektoren oder entfernen Sie alle Konfigurationen, die darauf verweisen, wenn der Selektor entfernt wurde.

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

Achten Sie darauf, dass Sie die Konfiguration mit dem entsprechenden Datenschema angeben:

In Config Sync 1.3.2 verworfen. –

Bei Verwendung der hierarchischen Repository-Struktur muss eine Konfiguration für den ConfigManagement Operator im Verzeichnis system/ des Repositorys vorhanden sein. Diese Konfiguration muss erforderliche Informationen wie die semantische Version des Repositorys enthalten.

Definieren Sie mindestens eine minimale Konfiguration für den Config Management 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. Der Wert muss mit dem Namen des Namespace-Verzeichnisses übereinstimmen. Korrigieren Sie den Wert von metadata.name oder das Verzeichnis des Namespace.

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

Erstellen Sie eine CustomResourceDefinition für die Ressource, auf die in der Fehlermeldung verwiesen wird. Für Ressourcentypen, die keine integrierten Kubernetes-Objekte sind, muss eine CustomResourceDefinition vorhanden sein.

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

Verschieben Sie die in der Fehlermeldung referenzierte Ressource 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 des 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 dürfen maximal 63 Zeichen lang sein und nur kleingeschriebene alphanumerische Zeichen und Bindestriche enthalten. Sie müssen mit einem alphanumerischen Zeichen beginnen und enden.

Benennen Sie das falsch benannte Verzeichnis um oder entfernen Sie es.

Konfigurationen desselben Typs müssen im selben Namespace und in den übergeordneten abstrakten Namespaces eindeutige Namen haben.

Benennen Sie alle in der Fehlermeldung genannten Konfigurationen um oder entfernen Sie sie, damit sie alle eindeutige Namen haben.

Mehrere Namespace-Ressourcen können nicht im selben Verzeichnis vorhanden sein.

Entfernen Sie die doppelten Konfigurationen, sodass nur noch eine Namespace-Ressource vorhanden ist.

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 die Arten HierarchyConfig und Repo nur im Verzeichnis system/ deklarieren.

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

Der Namespace config-management-system, resource-group-system und config-management-monitoring oder die darin enthaltenen Ressourcen dürfen nicht deklariert werden.

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 Namespaces und aller darunter deklarierten Ressourcen zu beenden.
  2. Warten Sie auf eine Synchronisierung und prüfen Sie dann, ob die entsprechenden Ressourcen weiterhin 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 mit einem hierarchischen Repository synchronisiert haben und den Controller-Namespace zusammen mit allen Ressourcen deklarieren mussten, sollten Sie auf ein unstrukturiertes Repository umstellen, um mehr Flexibilität bei der Quellstruktur zu erhalten.

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

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

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

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

In Config Sync 1.3 verworfen. –

Die Deklaration eines Namespace-bezogenen Objekts außerhalb des Verzeichnisses namespaces/ ist nicht zulässig.

Verschieben Sie die problematischen Konfigurationen in ein gültiges Verzeichnis. Weitere Informationen zu Namespace-bezogenen Objekten finden Sie unter Namespace-bezogene Objekte.

Die Deklaration eines Cluster-bezogenen Objekts außerhalb des Verzeichnisses cluster/ ist nicht zulässig.

Verschieben Sie die problematischen Konfigurationen in ein gültiges Verzeichnis. Weitere Informationen zu clusterbezogenen Objekten finden Sie unter Clusterbezogene Objekte.

In Config Sync 1.3 verworfen. –

Dieser Ressourcentyp 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.

Bei einer 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 oder eine Namespace-Konfiguration in Ihrem abstrakten Namespace-Verzeichnis hinzu oder entfernen Sie die Konfigurationen in Ihrem abstrakten Namespace-Verzeichnis.

Konfigurationen mit dem angegebenen metadata.ownerReference sind nicht zulässig.

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

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

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

Das Entfernen einer benutzerdefinierten Ressourcendefinition (CRD) und das Belassen der entsprechenden benutzerdefinierten Ressourcen im Repository ist nicht zulässig.

Entfernen Sie die CRD zusammen mit den benutzerdefinierten Ressourcen.

Die CustomResourceDefinition hat einen ungültigen Namen.

Ändern Sie den Namen entsprechend der Empfehlung in der Fehlermeldung.

Die Konfiguration verwendet eine nicht mehr unterstützte Gruppe und Art.

Ändern Sie die Gruppe oder Art entsprechend der Empfehlung in der Fehlermeldung.

Clusterbezogene Ressourcen dürfen metadata.namespace nicht deklarieren.

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

Für Ressourcen mit Namespace muss entweder metadata.namespace oder metadata.annotations.configmanagement.gke.io/namespace-selector deklariert werden.

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

Die 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, damit er den folgenden Regeln entspricht:

  • 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 die Annotation 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 auf das Namespace bezogene Ressourcen in dem Namespace deklarieren, für den das Repository gilt.

Achten Sie darauf, dass in allen Namespace-Repositories Namespace-bezogene Ressourcen richtig deklariert werden. Das Repository für das Namespace-Repository shipping kann beispielsweise nur Ressourcen im Namespace shipping verwalten. 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 shipping-Namespace-Repository metadata.namespace: billing deklariert hat, erhalten Sie einen Fehler.

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

Ein Namespace-Repository kann maximal eine Kptfile-Ressource deklarieren.

 Entfernen Sie alle Kptfile-Ressourcen bis auf eine.

Beim Verwalten 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 dasselbe Objekt beispielsweise von einem RootSync- und einem RepoSync-Objekt verwaltet wird, hat das RootSync-Objekt Vorrang. Wenn RootSync zuerst angewendet wird, meldet RepoSync einen Statusfehler KNV1060. Wenn das RepoSync-Objekt zuerst angewendet wird, überschreibt das RootSync-Objekt das Objekt des RepoSync-Objekts und das RepoSync-Objekt meldet einen KNV1060-Statusfehler, wenn es die Aktualisierung sieht.

Lösen Sie den Konflikt, indem Sie die Konfiguration an die andere verlässliche Quelle anpassen oder das in Konflikt stehende Objekt aus einer der Quellen löschen.

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

Ein InvalidRepoSyncError meldet, dass eine Repository-Konfiguration falsch konfiguriert ist. RepoSync-Objekte müssen ordnungsgemäß für Config Sync konfiguriert werden, damit die Konfiguration aus Namespace-Repositories synchronisiert werden kann.

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 haben, in dem sowohl die Kennzeichnung als auch das 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.

Das Format der CustomResourceDefinition ist fehlerhaft.

Prüfen Sie das in der Fehlermeldung angegebene Feld und achten Sie darauf, dass der Wert richtig formatiert ist.

Ein Konfigurationsobjekt darf nur eine Cluster-Selektor-Annotation 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 Annotationen aus dem Feld metadata.annotations.

Der Abgleicher kann die deklarierten Felder nicht in ein Format codieren, das mit Server-Side Apply kompatibel ist. Dies kann durch ein veraltetes Schema verursacht werden.

Prüfen Sie das in der Fehlermeldung angegebene Feld und achten Sie darauf, dass es mit dem Schema des Ressourcentyps übereinstimmt.

Beim Renderingprozess ist ein Problem aufgetreten, das Handlungsbedarf aufseiten des Nutzers erfordert.

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 die Kustomize-Konfigurationen womöglich in Ihrem Git-Repository aktualisieren. Sie können die aktualisierten Konfigurationen lokal mit nomos hydrate bzw. nomos vet anzeigen und validieren. Wenn die aktualisierten Konfigurationen erfolgreich gerendert werden, können Sie einen neuen Commit per Push übertragen, um den Fehler KNV1068 zu beheben.

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

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 selbstverwaltet sein.

Entfernen Sie das RootSync- oder RepoSync-Objekt aus der verlässlichen Quelle, aus 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 die folgende angezeigt: KNV2001: yaml: line 2: did not find expected node content path:.... Prüfen Sie Ihre YAML-Dateien und beheben Sie alle Konfigurationsprobleme, um dieses Problem zu beheben. Dies kann durch eine beliebige YAML-Konfiguration im Repository verursacht werden.

Wenn Ihr 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 Ihren Datei- oder Pfadnamen, um dieses Problem zu beheben.

Eine Anfrage für den Zugriff auf den Kubernetes API-Server schlägt fehl.

Kubernetes API-Anfragen können aus verschiedenen Gründen fehlschlagen. Das kann folgende Gründe haben:

  • Fehler bei der API-Erkennung
  • Clientseitiges oder serverseitiges Zeitlimit für Anfragen oder Antworten
  • Identitäts-, Authentifizierungs- oder Autorisierungsfehler
  • Fehler bei der Netzwerkverbindung
  • Webhook hat die Anfrage abgelehnt
  • Webhook fehlerhaft oder nicht vom API-Server erreichbar

Config Sync versucht es nach den meisten API-Server-Fehlern noch einmal. Einige sind möglicherweise vorübergehende Probleme, die sich von selbst beheben, die meisten erfordern jedoch eine Reaktion des Nutzers. API-Serverfehler werden selten durch Config Sync selbst verursacht. Wenn Sie jedoch vermuten, dass dies der Fall ist, erstellen Sie einen Fehlerbericht.

Ein allgemeiner Systemaufruf auf Betriebssystemebene schlägt fehl.

Config Sync kann nicht aus der Source of Truth lesen.

Dieser Fehler kann verschiedene Ursachen haben. Informationen zur Fehlerbehebung beim Herstellen einer Verbindung zur „Source of Truth“ finden Sie unter Fehler beim Herstellen einer Verbindung zur „Source of Truth“ beheben. Informationen zu bekannten Problemen, die KNV2004-Fehler verursachen, finden Sie unter Bekannte Probleme.

Config Sync konkurriert mit einem anderen Controller um eine Ressource. Solche Streits verbrauchen ein hohes Maß an Ressourcen und können die Leistung beeinträchtigen. Tipps zum Diagnostizieren und Beheben von Controller-Konflikten finden Sie unter Controller-Konflikte beheben.

Um ein versehentliches Löschen zu verhindern, lässt Config Sync das Löschen aller Namespaces oder clusterbezogenen Ressourcen in einem einzigen Commit nicht zu.

Wenn der Config Sync-Zulassungs-Webhook deaktiviert ist, setzen Sie den Commit zurück, der alle Ressourcen löscht.
Wenn der Config Sync-Zulassungs-Webhook aktiviert ist, wird Ihr Namespace möglicherweise nicht beendet. Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Deaktivieren Sie Config Sync und warten Sie, bis alle Ressourcen bereinigt oder stabil sind. 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 Namespaces außer einer Namespace- oder clusterbezogenen Ressource 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 versucht, sie zu ändern.

Wenn dieser Fehlertyp nur beim Start oder selten auftritt, können Sie ihn ignorieren.

Wenn diese Fehler nicht vorübergehend sind (mehrere Minuten andauern), kann ein schwerwiegendes Problem die Ursache sein und nomos status meldet Controller-Konflikte.

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

Für diesen Fehler gibt es mehrere mögliche Gründe. Tipps zur Behebung häufiger Probleme bei der Synchronisierung findest du 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: ConfigManagement Operator hat versucht, eine Ressource zu aktualisieren, doch die Ressource wurde beim Berechnen der Aktualisierung gelöscht.

Erstellen oder stellen Sie die fehlende Ressource wieder her.

Dieser Fehler meldet, dass mehrere Instanzen einer APIResource in einem Kontext gefunden wurden, in dem nur eine dieser APIResource-Instanzen zulässig ist. Beispiel: Ein Cluster darf nur eine Repo-Ressource enthalten.

Entfernen Sie die zusätzliche APIResource.

Ein Namespace-Abgleicher hat nicht die erforderlichen Berechtigungen zur Verwaltung von Ressourcen.

Prüfen Sie, ob der Abgleicher über die erforderlichen Berechtigungen verfügt.

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

Entfernen Sie den illegal modifizierten Webhook.

Beim Renderingprozess ist ein internes Problem aufgetreten. Beispiel: Config Sync kann nicht auf das Dateisystem zugreifen.

Dieser Fehler kann darauf hinweisen, dass der Pod nicht fehlerfrei ist. Sie können die Abgleich-Pods mit den folgenden Befehlen neu starten:

# 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 vorübergehend und sollte später automatisch behoben werden. Dieser Fehler wird beispielsweise angezeigt, wenn der Renderingstatus nicht mit der Quellkonfiguration übereinstimmt.

Der Fehler sollte automatisch behoben werden.

Es gibt ein Problem mit Config Sync selbst.

Reichen Sie bitte einen Fehlerbericht ein.

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-Abstimmungsfunktionen gemeldet werden, haben den KNV-Fehlercode. 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 liegt.

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

Exporte können nicht erstellt werden

Wenn eine Komponente in Open Telemetry Collector nicht auf das Standarddienstkonto im selben Namespace zugreifen kann, sehen Sie möglicherweise, dass sich der otel-collector-Pod unter config-management-monitoring im CrashLoopBackoff-Status befindet, oder Sie erhalten möglicherweise eine Fehlermeldung ähnlich den unten aufgeführten.

Dieses Problem tritt normalerweise auf, wenn Workload Identity-Föderation für GKE in einem Cluster aktiviert ist.

Folgen Sie zur Behebung des Problems der Anleitung unter Monitoring von Config Sync, um dem Standarddienstkonto die Schreibberechtigung für Messwerte zu erteilen.

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-ConfigMap otel-collector-googlecloud geforkt haben, prüfen und rebasen Sie alle Unterschiede.

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

Serverzertifikatüberprüfung fehlgeschlagen

Wenn der git-sync-, helm-sync- oder oci-sync-Container keine Artefakte abrufen kann, wird möglicherweise diese Fehlermeldung angezeigt.

Diese Meldung weist darauf hin, dass der Server mit Zertifikaten einer benutzerdefinierten Zertifizierungsstelle konfiguriert ist. Die benutzerdefinierte Zertifizierungsstelle ist jedoch nicht richtig konfiguriert, sodass der Container keine Daten vom Server abrufen kann.

Um dieses Problem zu beheben, können Sie zuerst prüfen, ob das Feld caCertSecretRef in Ihrem RootSync- oder RepoSync-Objekt richtig konfiguriert wurde, und auch prüfen, 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 CA bereitgestellt wird, können die Methoden zum Prüfen der vollständigen Zertifikate variieren.

Hier ist ein Beispiel für das Auflisten der Serverzertifikate: 

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 Netzwerkadministrationsteam bitten, die CA-Zertifikate für Sie zu besorgen.

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

Pull-Secret kann nicht abgerufen werden. Das Abrufen des Images schlägt möglicherweise fehl.

Wenn Sie eine private Registry mit Google Distributed Cloud verwenden, kann die Installation oder das Upgrade von Config Sync hängen bleiben. Es wird ein Fehler ähnlich dieser Meldung angezeigt.

Folgen Sie zur Behebung dieses Problems der Anleitung unter Config Sync mit einer privaten Registry aktualisieren, bevor Sie Config Sync installieren oder aktualisieren.

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 das folgende Beispiel erhalten, haben Sie möglicherweise nicht die Rolle GKE-Hub-Administrator.

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

Nach oben

Nächste Schritte