Stabilität der Steuerungsebene bei Verwendung von Webhooks gewährleisten

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 und K8S_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:

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:

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

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

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

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

  2. 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 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 Bedingung operator ist NotIn und values lässt kube-system und kube-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 auf Namespaced und nicht * festlegen, sodass 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 Bedingung operator ist In und values enthält kube-system und kube-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 auf Namespaced und nicht * festlegen, sodass 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 nur blue-system in values sein, da operator der Wert 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 belassen.

Nächste Schritte