Probleme mit Google Distributed Cloud-Webhook beheben

Auf dieser Seite wird beschrieben, wie Sie Probleme mit problematischen oder unsicheren Webhooks in Google Distributed Cloud beheben.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Arten problematischer Webhooks

Zulassungs-Webhooks oder Webhooks in Kubernetes sind eine Art Admission-Controller, mit dem in Kubernetes-Clustern Anfragen an die Steuerungsebene validiert oder mutiert werden können, bevor eine Anfrage beibehalten wird. Anwendungen von Drittanbietern verwenden häufig Webhooks für systemkritische Ressourcen und Namespaces. Falsch konfigurierte Webhooks können die Leistung und Zuverlässigkeit der Steuerungsebene beeinträchtigen. Beispielsweise kann ein falsch konfigurierter Webhook, der von einer Drittanbieteranwendung erstellt wurde, verhindern, dass Google Distributed Cloud Ressourcen im verwalteten Namespace kube-system erstellt und ändert, was die Funktionalität des Clusters beeinträchtigen könnte.

Zu problematischen Webhooks gehören die folgenden Typen:

Webhooks ohne verfügbare Endpunkte

Wenn ein Webhook 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, der diesen Webhook-Endpunkt unterstützt, und mögliche Fehler zu beheben:

  1. Suchen Sie die bereitstellenden Pods für den Dienst, der mit dem Webhook verknüpft ist. Führen Sie den folgenden Befehl aus, um den Dienst zu beschreiben:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Ersetzen Sie Folgendes:

    • SERVICE_NAME durch den Namen des Dienstes.
    • SERVICE_NAMESPACE durch den Namen des Namespace.

    Wenn Sie den Dienstnamen im Webhook nicht finden können, wird der nicht verfügbare Endpunkt möglicherweise durch eine Abweichung zwischen dem Namen in der Konfiguration und dem tatsächlichen Namen des Dienstes verursacht. Aktualisieren Sie den Dienstnamen in der Webhook-Konfiguration, damit er mit dem richtigen Dienstobjekt übereinstimmt, um die Endpunktverfügbarkeit zu korrigieren.

  2. Prüfen Sie die bereitstellenden Pods für diesen Dienst. Listen Sie das Deployment auf, um herauszufinden, welche Pods nicht ausgeführt werden:

    kubectl get deployment -n SERVICE_NAMESPACE

    Oder führen Sie den folgenden Befehl aus, um die Pods aufzulisten:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Sehen Sie sich die Pod-Logs an, um herauszufinden, warum der Pod nicht ausgeführt wird.

Als unsicher eingestufte Webhooks

Wenn ein Webhook Ressourcen in vom System verwalteten Namespaces abfängt, empfehlen wir, die Webhooks zu aktualisieren, damit diese Ressourcen nicht abgefangen werden.

  1. Prüfen Sie die Webhook-Konfiguration. Führen Sie den folgenden kubectl-Befehl aus, um die Webhook-Konfiguration abzurufen:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Ersetzen Sie CONFIGURATION_NAME durch den Namen der Webhook-Konfiguration.

    Wenn dieser Befehl nichts zurückgibt, führen Sie den Befehl noch einmal aus und ersetzen Sie validatingwebhookconfigurations durch mutatingwebhookconfigurations.

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

  2. Bearbeiten Sie die Konfiguration je nachdem, aus welchem Grund der Webhook als unsicher eingestuft wird:

    Namespaces „kube-system” und „kube-node-lease” ausschließen

    Ein Webhook gilt als unsicher, wenn scope den Wert * hat oder 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 aus, wie im folgenden Beispiel:

      webhooks:
- admissionReviewVersions:
  ...
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - blue-system # add 'kube-system' and 'kube-node-lease' if `NotIn`
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*' # 'Namespaced'
  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 auf NotIn gesetzt ist, müssen kube-system und kube-node-lease in values enthalten sein.

    • 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 # remove as operator is `In`
      - kube-node-lease # remove as operator is `In`

      Achten Sie darauf, dass scope auf Namespaced und nicht auf * festgelegt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Wenn operator auf In gesetzt ist, dürfen kube-system und kube-node-lease nicht in values enthalten sein.

    Übereinstimmende Ressourcen ausschließen

    Ein Webhook gilt auch dann als unsicher, wenn nodes, tokenreviews, subjectaccessreviews oder certificatesigningrequests wie im folgenden Beispiel unter den Ressourcen aufgeführt sind:

    - admissionReviewVersions:
...
    resources:
    - 'pods' # keep, remove everything else
    - 'nodes'
    - 'tokenreviews'
    - 'subjectacessreviews'
    - 'certificatesigningrequests'
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

    Entfernen Sie nodes, tokenreviews, subjectaccessreviews und certificatesigningrequests aus dem Ressourcenabschnitt.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.