Probleme mit Google Distributed Cloud-Webhook beheben

Auf dieser Seite erfahren Sie, 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 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 Google Distributed Cloud daran hindern, Ressourcen im verwalteten Namespace kube-system zu erstellen und zu ändern, was die Funktionalität des Clusters beeinträchtigen kann.

Zu problematischen Webhooks gehören:

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

  1. Suchen Sie die Bereitstellungs-Pods für den Dienst, der dem Webhook zugeordnet 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, 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.

  2. Prüfen Sie die Bereitstellungs-Pods für diesen Dienst. Ermitteln Sie, welche Pods nicht ausgeführt werden. Listen Sie dazu das Deployment auf:

    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
    

    Prüfen Sie für alle nicht ausgeführten Pods in den Pod-Logs, warum der Pod nicht ausgeführt wird.

Webhooks, die als unsicher gelten

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 Rufen Sie die Webhook-Konfiguration ab:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
    

    Ersetzen Sie CONFIGURATION_NAME durch den Namen Webhook-Konfiguration.

    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 der Ausgabe werden ein oder mehrere Webhooks aufgeführt.

  2. Bearbeiten Sie die Konfiguration je nachdem, warum der Webhook als unsicher gilt:

    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 wie im folgenden Beispiel aus:

      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 * gesetzt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Achten Sie darauf, dass wenn operator NotIn ist, kube-system und kube-node-lease in values enthalten sein müssen.

    • 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 * gesetzt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt wird. Achten Sie darauf, dass kube-system und kube-node-lease nicht in values enthalten ist, wenn operator In ist.

    Übereinstimmende Ressourcen ausschließen

    Ein Webhook gilt auch als unsicher, wenn nodes, tokenreviews, subjectaccessreviews oder certificatesigningrequests wie im folgenden Beispiel unter 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.