Bei Verwendung von Webhooks für die Stabilität der Steuerungsebene sorgen

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. Es ist üblich, dass Anwendungen von Drittanbietern Webhooks verwenden, die mit systemkritischen Ressourcen und Namespaces ausgeführt werden. Falsch konfigurierte Webhooks können sich auf die Leistung und Zuverlässigkeit der Steuerungsebene auswirken. Beispiel: Ein falsch konfigurierter Webhook, der von einer Drittanbieteranwendung erstellt wurde, könnte GKE daran hindern, Ressourcen im verwalteten Namespace kube-system zu erstellen und zu ändern, was die Funktionalität des Clusters beeinträchtigen kann.

Die Google Kubernetes Engine (GKE) überwacht Ihre Cluster und verwendet den Recommender-Dienst, um eine Anleitung zum Optimieren Ihrer Nutzung der Plattform bereitzustellen. Damit Ihr Cluster stabil und leistungsfähig bleibt, finden Sie hier Empfehlungen von GKE für die folgenden Szenarien:

  • Webhooks, die funktionieren, die aber keine Endpunkte haben.
  • Webhooks, die als unsicher angesehen werden, da sie systemkritische Ressourcen und Namespaces bearbeiten.

In dieser Anleitung wird beschrieben, wie Sie Ihre potenziell falsch konfigurierten Webhooks prüfen und 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 identifizieren, die sich auf Ihren Cluster auswirken können

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. So erhalten Sie Statistiken:

  • Google Cloud Console verwenden.
  • Verwenden Sie die Google Cloud CLI oder die Recommender API und filtern Sie mit den Untertypen K8S_ADMISSION_WEBHOOK_UNSAFE und K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Nachdem Sie die Webhooks über die Statistiken identifiziert haben, folgen Sie der Anleitung zur Fehlerbehebung bei 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:

Fehlerbehebung bei erkannten Webhooks

In den folgenden Abschnitten finden Sie eine Anleitung zur Fehlerbehebung bei Webhooks, die GKE als potenziell falsch konfiguriert erkannt hat.

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, die keine verfügbaren Endpunkte melden

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. Um die Webhook-Endpunkte verfügbar zu machen, folgen Sie der Anleitung, um die Pods des Dienstes zu finden und Fehler zu beheben, der diesen Webhook-Endpunkt unterstützt:

  1. Statistiken und Empfehlungen aufrufen und jeweils eine Statistik zur Fehlerbehebung auswählen. GKE generiert eine Statistik pro Cluster. Diese listet einen oder mehrere Webhooks mit einem fehlerhaften Endpunkt auf, die untersucht werden müssen. Für jeden dieser Webhooks gibt die Statistik auch den Servicenamen, den Endpunkt eines fehlerhaften Endpunkts und den letzten Aufruf des Endpunkts an.

  2. Suchen Sie die Bereitstellungs-Pods für den Dienst, der dem Webhook zugeordnet ist:

    Console

    Im Seitenleistenbereich der Statistik sehen Sie die Tabelle der falsch konfigurierten Webhooks. 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 können, könnte der nicht verfügbare Endpunkt durch eine Abweichung zwischen dem in der Konfiguration aufgelisteten Namen und dem tatsächlichen Namen des Dienstes entstanden sein. Aktualisieren Sie den Dienstnamen in der Webhook-Konfiguration mit dem richtigen Dienstobjekt, um die Endpunktverfügbarkeit zu korrigieren.

  3. Prüfen Sie die Bereitstellungs-Pods für diesen Dienst:

    Console

    Sehen Sie sich in den Dienstdetails unter Bereitstellungs-Pods die Liste der Pods an, die diesen Dienst unterstützen.

    kubectl

    Ermitteln Sie, welche Pods nicht ausgeführt werden. Listen Sie dazu das Deployment oder die Pods auf:

    kubectl get deployment -n SERVICE_NAMESPACE

    Oder führen Sie diesen Befehl aus:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Prüfen Sie für alle nicht ausgeführten Pods in den Pod-Logs, warum der Pod nicht ausgeführt wird. Eine Anleitung zu häufigen Problemen mit Pods finden Sie unter Probleme mit bereitgestellten Arbeitslasten beheben.

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.

  1. Folgen Sie der Anleitung zum Aufrufen von Statistiken und Empfehlungen und wählen Sie jeweils eine Statistik zur Fehlerbehebung aus. GKE generiert nur eine Information pro Cluster und 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.

  2. Prüfen Sie die Webhook-Konfiguration:

    Console

    In der Seitenleiste der Statistik finden Sie die Tabelle. 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 jeder Konfiguration auf den Namen, um diese Konfiguration im GKE-Dashboard Objektbrowser aufzurufen.

    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 bei diesem Befehl nichts zurückgegeben wird, führen Sie den Befehl noch einmal aus und ersetzen Sie dabei validatingwebhookconfigurations durch mutatingwebhookconfigurations.

    Im Abschnitt webhooks sind ein oder mehrere Webhooks aufgeführt.

  3. 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 Bereich Namespaced ist und eine der folgenden Bedingungen erfüllt ist:

    • Die operator-Bedingung ist NotIn und values lässt kube-system und kube-node-lease wie im folgenden Beispiel aus:

      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 scope auf Namespaced und nicht auf * festgelegt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Wenn operator NotIn ist, können Sie kube-system und kube-node-lease in values (In diesem Beispiel mit blue-system) mit einschließen.

    • Die operator-Bedingung ist In und values enthält kube-system und kube-node-lease wie im folgenden Beispiel: 

      namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - blue-system
      - kube-system
      - kube-node-lease

      Achten Sie darauf, dass scope auf Namespaced und nicht auf * festgelegt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Stellen Sie sicher, dass wenn operator In ist, kube-system und kube-node-lease nicht in values mit einzuschließen. In diesem Beispiel sollte sich nur blue-system in values befinden, da der operator In ist.

    Übereinstimmende Ressourcen ausschließen

    Ein Webhook wird auch gemeldet, wenn nodes, tokenreviews, subjectaccessreviews oder certificatesigningrequests 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 und certificatesigningrequests aus dem Ressourcenabschnitt. Sie können pods in resources behalten.

Nächste Schritte