Zulassungs-Webhooks oder Webhooks sind in Kubernetes eine Art von Admission-Controller, die in Kubernetes-Clustern verwendet werden können, um Anfragen an die Steuerungsebene zu validieren oder zu mutieren, bevor eine Anfrage beibehalten wird. Anwendungen von Drittanbietern verwenden häufig Webhooks, die auf systemkritischen Ressourcen und Namespaces ausgeführt werden. Falsch konfigurierte Webhooks können die Leistung und Zuverlässigkeit der Steuerungsebene beeinträchtigen. Beispiel: Ein falsch konfigurierter Webhook, der von einer Drittanbieteranwendung erstellt wurde, kann verhindern, dass GKE Ressourcen im verwalteten Namespace kube-system
erstellt und ändert. Dies kann die Funktionalität des Clusters beeinträchtigen.
Google Kubernetes Engine (GKE) überwacht Ihre Cluster und bietet mit dem Recommender-Dienst Unterstützung für die Optimierung der Plattformnutzung. Damit Ihr Cluster stabil und leistungsfähig bleibt, finden Sie in den folgenden Szenarien Empfehlungen von GKE:
- Webhooks, die funktionieren, aber keine Endpunkte verfügbar haben.
- Webhooks, die als unsicher angesehen werden, funktionieren mit systemkritischen Ressourcen und Namespaces.
In dieser Anleitung finden Sie eine Anleitung dazu, wie Sie potenziell falsch konfigurierte Webhooks prüfen und diese bei Bedarf aktualisieren können.
Weitere Informationen zum Verwalten von Statistiken und Empfehlungen von Recommendern finden Sie unter Nutzung von GKE mit Statistiken und Empfehlungen optimieren.
Falsch konfigurierte Webhooks, die sich auf Ihren Cluster auswirken könnten, identifizieren
Folgen Sie der Anleitung zum Aufrufen von Statistiken und Empfehlungen, um Informationen zu erhalten, die Webhooks identifizieren, welche sich auf die Leistung und Stabilität Ihres Clusters auswirken können. Informationen erhalten Sie auf folgende Arten:
- Google Cloud Console verwenden.
- Verwenden Sie die Google Cloud CLI oder die Recommender API und filtern Sie mit den Untertypen
K8S_ADMISSION_WEBHOOK_UNSAFE
undK8S_ADMISSION_WEBHOOK_UNAVAILABLE
.
Nachdem Sie die Webhooks über die Statistiken identifiziert haben, folgen Sie der Anleitung zur Fehlerbehebung bei den erkannten Webhooks.
Wenn GKE falsch konfigurierte Webhooks erkennt
GKE generiert eine Statistik und eine Empfehlung, wenn eines der folgenden Kriterien für einen Cluster zutrifft:
K8S_ADMISSION_WEBHOOK_UNAVAILABLE
: Der GKE-Cluster hat einen oder mehrere Webhooks, die keine verfügbaren Endpunkte melden. Folgen Sie der Anleitung unter Webhooks prüfen, die keine verfügbaren Endpunkte melden.K8S_ADMISSION_WEBHOOK_UNSAFE
: Der GKE-Cluster hat einen oder mehrere Webhooks, die auf der Grundlage der abgefangenen Ressourcen als unsicher eingestuft werden. Folgen Sie der Anleitung zum Prüfen der Webhooks, die als unsicher gelten. Die folgenden Webhooks gelten als unsicher:- Webhooks fangen Ressourcen, einschließlich Pods und Freigaben, im Namespace
kube-system
ab. - Webhooks fangen Freigaben im Namespace
kube-node-lease
ab. - Webhooks fangen clusterbezogene Systemressourcen ab, einschließlich
Nodes
,TokenReviews
,SubjectAccessReviews
undCertificateSigningRequests
.
- Webhooks fangen Ressourcen, einschließlich Pods und Freigaben, im Namespace
Fehlerbehebung bei erkannten Webhooks
In den folgenden Abschnitten finden Sie Anleitungen zur Fehlerbehebung bei Webhooks, die von GKE als potenziell falsch konfiguriert erkannt wurden.
Nachdem Sie die Anleitung implementiert haben und die Webhooks ordnungsgemäß konfiguriert sind, wird die Empfehlung innerhalb von 24 Stunden aufgelöst und nicht mehr in der Console angezeigt. Wenn seit der Implementierung der Anleitung der Empfehlung weniger als 24 Stunden vergangen sind, können Sie die Empfehlung als erledigt markieren. Wenn Sie die Empfehlung nicht implementieren möchten, können Sie sie verwerfen.
Webhooks melden keine verfügbaren Endpunkte
Wenn ein Webhook meldet, dass er keine verfügbaren Endpunkte hat, hat der Dienst, der den Webhook-Endpunkt unterstützt, einen oder mehrere Pods, die nicht ausgeführt werden. Wenn Sie die Webhook-Endpunkte verfügbar machen möchten, folgen Sie der Anleitung zum Suchen und Beheben von Pods des Dienstes, der diesen Webhook-Endpunkt unterstützt:
Statistiken und Empfehlungen aufrufen und jeweils eine Statistik zur Fehlerbehebung auswählen. GKE generiert eine Statistik pro Cluster. Diese Statistik listet einen oder mehrere Webhooks mit einem fehlerhaften Endpunkt auf, der untersucht werden muss. Für jeden dieser Webhooks werden auch der Dienstname, der Endpunkt der Unterbrechung und der Zeitpunkt des letzten Aufrufs angegeben.
Suchen Sie die Bereitstellungs-Pods für den Dienst, der dem Webhook zugeordnet ist:
Console
Im Seitenleistenbereich der Statistik wird die Tabelle mit falsch konfigurierten Webhooks angezeigt. Klicken Sie auf den Namen des Dienstes.
kubectl
Führen Sie den folgenden Befehl aus, um den Dienst zu beschreiben:
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
Ersetzen Sie SERVICE_NAME und SERVICE_NAMESPACE durch den Namen bzw. den Namespace des Dienstes.
Wenn Sie den Dienstnamen im Webhook nicht finden, kann der nicht verfügbare Endpunkt durch eine Abweichung zwischen dem in der Konfiguration aufgeführten Namen und dem tatsächlichen Namen des Dienstes verursacht werden. Um die Verfügbarkeit des Endpunkts zu beheben, aktualisieren Sie den Dienstnamen in der Webhook-Konfiguration so, dass er mit dem richtigen Dienstobjekt übereinstimmt.
Prüfen Sie die Bereitstellungs-Pods für diesen Dienst:
Console
Unter Bereitstellungs-Pods in den Dienstdetails finden Sie die Liste der Pods, die diesen Dienst unterstützen.
kubectl
Ermitteln Sie, welche Pods nicht ausgeführt werden, indem Sie die Bereitstellung oder die Pods auflisten:
kubectl get deployment -n SERVICE_NAMESPACE
Oder führen Sie den folgenden Befehl aus:
kubectl get pods -n SERVICE_NAMESPACE -o wide
Prüfen Sie in Bezug auf alle nicht ausgeführten Pods die Pod-Logs, um festzustellen, warum der Pod nicht ausgeführt wird. Informationen zu häufigen Problemen mit Pods finden Sie unter Fehlerbehebung bei bereitgestellten Arbeitslasten.
Webhooks, die als unsicher gelten
Wenn ein Webhook Ressourcen in systemverwalteten Namespaces oder bestimmten Ressourcentypen abfängt, betrachtet GKE dies als unsicher und empfiehlt Ihnen, die Webhooks zu aktualisieren, damit diese Ressourcen nicht abgefangen werden.
- Folgen Sie der Anleitung zum Aufrufen von Statistiken und Empfehlungen und wählen Sie jeweils eine Statistik zur Fehlerbehebung aus. GKE generiert nur eine Statistik pro Cluster. Diese Statistik listet eine oder mehrere Webhook-Konfigurationen auf, die jeweils einen oder mehrere Webhooks auflisten. Für jede aufgeführte Webhook-Konfiguration wird in der Statistik der Grund für die Meldung der Konfiguration angegeben.
Prüfen Sie die Webhook-Konfiguration:
Console
Sehen Sie sich die Tabelle im Seitenleistenbereich der Statistik an. In jeder Zeile sind der Name der Webhook-Konfiguration und der Grund für die Meldung dieser Konfiguration aufgeführt.
Klicken Sie zum Prüfen der einzelnen Konfigurationen auf den Namen, um zu dieser Konfiguration im GKE-Dashboard Objektbrowser zu wechseln.
kubectl
Führen Sie den folgenden
kubectl
-Befehl aus, um die Webhook-Konfiguration abzurufen. Ersetzen Sie dabei CONFIGURATION_NAME durch den Namen der Webhook-Konfiguration:kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
Wenn dieser Befehl nichts zurückgibt, führen Sie den Befehl noch einmal aus und ersetzen Sie
validatingwebhookconfigurations
durchmutatingwebhookconfigurations
.Im Abschnitt
webhooks
sind ein oder mehrere Webhooks aufgeführt.Bearbeiten Sie die Konfiguration abhängig davon, warum der Webhook gemeldet wurde:
Namespaces „kube-system” und „kube-node-lease” ausschließen
Ein Webhook wird gemeldet, wenn
scope
*
ist. Oder ein Webhook wird gemeldet, wenn der BereichNamespaced
ist und eine der folgenden Bedingungen erfüllt ist:Die Bedingung
operator
istNotIn
undvalues
lässtkube-system
undkube-node-lease
wie im folgenden Beispiel weg:webhooks: - admissionReviewVersions: ... namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - blue-system objectSelector: {} rules: - apiGroups: ... scope: '*' sideEffects: None timeoutSeconds: 3
Achten Sie darauf, dass Sie
scope
aufNamespaced
und nicht*
festlegen, sodass der Webhook nur in bestimmten Namespaces ausgeführt wird. Wennoperator
NotIn
ist, können Siekube-system
undkube-node-lease
invalues
(In diesem Beispiel mitblue-system
) mit einschließen.Die Bedingung
operator
istIn
undvalues
enthältkube-system
undkube-node-lease
, wie im folgenden Beispiel gezeigt:namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - blue-system - kube-system - kube-node-lease
Achten Sie darauf, dass Sie
scope
aufNamespaced
und nicht*
festlegen, sodass der Webhook nur in bestimmten Namespaces ausgeführt wird. Stellen Sie sicher, dass wennoperator
In
ist,kube-system
undkube-node-lease
nicht invalues
mit einzuschließen. In diesem Beispiel sollte nurblue-system
invalues
sein, daoperator
der WertIn
ist.
Übereinstimmende Ressourcen ausschließen
Ein Webhook wird auch gemeldet, wenn
nodes
,tokenreviews
,subjectaccessreviews
odercertificatesigningrequests
wie im folgenden Beispiel unter Ressourcen aufgeführt sind:- admissionReviewVersions: ... resources: - 'pods' - 'nodes' - 'tokenreviews' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3
Entfernen Sie
nodes
,tokenreviews
,subjectaccessreviews
undcertificatesigningrequests
aus dem Ressourcenabschnitt. Sie könnenpods
inresources
belassen.