Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem Config Sync-Aufnahme-Webhook beheben. Weitere Informationen zum Webhook finden Sie unter Konfigurationsabweichungen verhindern.
KNV 2009-Fehler beheben
In den folgenden Abschnitten erfahren Sie, wie Sie KNV2009
-Fehler beheben können.
Zulassungs-Webhook-Verbindung abgelehnt
Wenn Sie den Schutz vor Konfigurationsabweichungen aktiviert haben, wird möglicherweise der folgende Fehler angezeigt, wenn der Abgleicher versucht, eine Konfiguration auf den Cluster anzuwenden:
KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post "https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s": dial tcp 10.92.2.14:8676: connect: connection refused
Dieser Fehler bedeutet, dass der Zulassungs-Webhook noch nicht verfügbar ist oder nicht mehr fehlerfrei funktioniert. Dies ist ein vorübergehender Fehler, den Sie möglicherweise beim Bootstrapping von Config Sync sehen.
Wenn das Problem weiterhin besteht, prüfen Sie anhand der Bereitstellung des Zugangs-Webhooks, ob dessen Pods geplant werden können und fehlerfrei sind.
kubectl describe deploy admission-webhook -n config-management-system
kubectl get pods -n config-management-system -l app=admission-webhook
Ein Deployment mit fehlerfreien Pods hat eine Ausgabe, die in etwa so aussieht:
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
...
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
...
E/A-Zeitüberschreitung bei Zulassungs-Webhook-Anfrage
Wenn Sie eine Fehlermeldung ähnlich der folgenden erhalten, wenn der Abgleicher versucht, eine Konfiguration auf den Cluster anzuwenden, ist der Webhook-Zugangsport 8676
möglicherweise durch die Firewall zum Netzwerk der Steuerungsebene blockiert:
KNV2009: Internal error occurred: failed calling webhook "v1.admission-webhook.configsync.gke.io": Post https://admission-webhook.config-management-system.svc:8676/admission-webhook?timeout=3s: dial tcp 10.1.1.186:8676: i/o timeout
Um dieses Problem zu beheben, fügen Sie eine Firewallregel hinzu, um Port 8676
zuzulassen, der vom Config Sync-Zulassungs-Webhook zur Vermeidung von Abweichungen verwendet wird. Port 8676
muss von der Steuerungsebene zu den Knoten geöffnet sein, da die Steuerungsebene das Webhook-Backend auf den Clusternknoten erreichen muss.
Annahme des Webhooks hat eine Anfrage abgelehnt
Wenn Sie beim Versuch, eine Änderung auf ein Feld anzuwenden, das von Config Sync verwaltet wird, den folgenden Fehler erhalten, hat Ihre Änderung möglicherweise einen Konflikt verursacht:
error: OBJECT could not be patched: admission webhook "v1.admission-webhook.configsync.gke.io"
denied the request: fields managed by Config Sync can not be modified
Wenn Sie den Drift-Schutz aktiviert haben, wird ein Feld, das Sie in einer Konfiguration deklarieren, von Config Sync verwaltet, sobald Ihr Repository mit einem Cluster synchronisiert wird. Jede Änderung, die Sie an diesem Feld vornehmen möchten, ist eine konfliktbehaftete Änderung.
Wenn Sie beispielsweise eine Deployment-Konfiguration in Ihrem Repository mit dem Label environment:prod
haben und versuchen, dieses Label in Ihrem Cluster in environment:dev
zu ändern, würde ein Konflikt entstehen und Sie erhalten die vorherige Fehlermeldung. Wenn Sie jedoch dem Deployment ein neues Label hinzufügen, z. B. tier:frontend
, entsteht kein Konflikt.
Wenn Config Sync alle Änderungen an einem Objekt ignorieren soll, können Sie die in Objektmutationen ignorieren beschriebene Annotation hinzufügen.
Fehler beim Löschen aller Ressourcentypen
Ein Namespace, der in der Phase Terminating
festhängt, hat die folgende Bedingung:
message: 'Failed to delete all resource types, 1 remaining: admission webhook
"v1.admission-webhook.configsync.gke.io" denied the request: system:serviceaccount:kube-system:namespace-controller
is not authorized to delete managed resource "_configmap_bookstore_cm1"'
reason: ContentDeletionFailed
status: "True"
type: NamespaceDeletionContentFailure
Dieser Fehler passiert, wenn Sie versuchen, ein Namespace
-Objekt aus einem Stamm-Repository zu löschen, einige Objekte unter dem Namespace werden jedoch weiterhin aktiv von einem Namespace-Abgleicher verwaltet. Wenn ein Namespace gelöscht wird, versucht der Namespace-Controller mit dem Dienstkonto system:serviceaccount:kube-system:namespace-controller
, alle Objekte in diesem Namespace zu löschen. Der Config Sync-Zulassungs-Webhook ermöglicht jedoch nur dem Root- oder Namespace-Abgleicher, diese Objekte zu löschen. Außerdem wird dem Namespace-Controller das Löschen dieser Objekte verweigert.
Um dieses Problem zu umgehen, löschen Sie den Config Sync-Zulassungs-Webhook:
kubectl delete deployment.apps/admission-webhook -n config-management-system
Der Config Management Operator erstellt den Config Sync-Zulassungs-Webhook neu.
Wenn diese Problemumgehung nicht funktioniert, müssen Sie Config Sync möglicherweise neu installieren.
Um zu vermeiden, dass der Fehler erneut auftritt, entfernen Sie das Namespace-Repository, bevor Sie den Namespace entfernen.
Nächste Schritte
Wenn weiterhin Probleme auftreten, sieh nach, ob dein Problem ein bekanntes Problem ist.
Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen:
- Sie können eine Supportanfrage erstellen, indem Sie sich an den Cloud Customer Care wenden.
- Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen.
Wenn Sie kpt oder Kustomize verwenden, suchen Sie mit dem Tag
kpt
oderkustomize
nach ähnlichen Problemen. - Sie können Fehler oder Funktionsanfragen über die öffentliche Problemverfolgung auf GitHub melden.