Fehlerbehebung beim Zulassungs-Webhook
Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem Config Sync-Zulassungs-Webhook beheben. Weitere Informationen zum Webhook finden Sie unter Konfigurationsabweichungen verhindern.
KNV2009-Fehler beheben
In den folgenden Abschnitten erfahren Sie, wie Sie den Fehler KNV2009 beheben.
Zulassungs-Webhook-Verbindung abgelehnt
Wenn Sie den Driftschutz aktiviert haben, wird möglicherweise der folgende Fehler angezeigt, wenn der Abgleich 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 bereit ist oder fehlerhaft ist. Dies ist in der Regel ein vorübergehender Fehler, der beim Bootstrapping von Config Sync auftreten kann.
Wenn das Problem weiterhin besteht, beschreiben Sie das Deployment des Zulassungs-Webhooks, um zu prüfen, ob die zugehörigen 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
Die Ausgabe eines Deployments mit fehlerfreien Pods sieht in etwa so aus:
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
...
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
...
E/A-Zeitlimit für Zulassungs-Webhook-Anfrage
Wenn Sie beim Versuch, eine Konfiguration auf den Cluster anzuwenden, einen ähnlichen Fehler wie den folgenden erhalten, wird der Zulassungs-Webhook-Port 8676 möglicherweise von der Firewall für das 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 aus offen sein, da die Steuerungsebene das Webhook-Back-End auf den Clusterknoten erreichen kann.
Zulassungs-Webhook 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 Driftschutz aktiviert haben und ein Feld in einer Konfiguration deklarieren und Ihr Repository mit einem Cluster synchronisiert wird, verwaltet Config Sync dieses Feld. Jede Änderung, die Sie an diesem Feld vornehmen, stellt einen Änderungskonflikt dar.
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 dem Deployment jedoch 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.
Es konnten nicht alle Ressourcentypen gelöscht werden
Ein Namespace, der in der Phase Terminating hängen bleibt, 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 tritt auf, wenn Sie versuchen, ein Namespace-Objekt aus einem Stamm-Repository zu löschen, aber einige Objekte unter dem Namespace weiterhin aktiv von einem Namespace-Abgleich verwaltet werden. Wenn ein Namespace gelöscht wird, versucht der Namespace-Controller, dessen Dienstkonto system:serviceaccount:kube-system:namespace-controller ist, alle Objekte in diesem Namespace zu löschen. Der Config Sync-Zulassungs-Webhook lässt jedoch nur zu, dass der Root- oder Namespace-Abgleicher diese Objekte löscht, und er verweigert dem Namespace-Controller, diese Objekte zu löschen.
Löschen Sie den Config Sync-Zulassungs-Webhook, um dieses Problem zu umgehen:
kubectl delete deployment.apps/admission-webhook -n config-management-system
Der ConfigManagement Operator erstellt den Config Sync-Zulassungs-Webhook neu.
Wenn dies nicht funktioniert, müssen Sie Config Sync möglicherweise neu installieren.
Damit der Fehler nicht noch einmal auftritt, entfernen Sie das Namespace-Repository, bevor Sie den Namespace entfernen.
Nächste Schritte
- Falls weiterhin Probleme auftreten, prüfen Sie, ob es sich um ein bekanntes Problem handelt.