Probleme mit GKE on VMware-Webhooks beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme mit problematischen oder unsicheren Webhooks in GKE on VMware beheben.

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

Typen problematischer Webhooks

Zulassungs-Webhooks oder Webhooks in Kubernetes sind eine Art Admission-Controller, der in Kubernetes-Clustern verwendet werden kann, um Anfragen an die Steuerungsebene zu validieren oder zu ändern, bevor eine Anfrage gespeichert wird. Anwendungen von Drittanbietern verwenden häufig Webhooks, die für systemkritische Ressourcen und Namespaces ausgeführt werden. Falsch konfigurierte Webhooks können sich auf die Leistung und Zuverlässigkeit der Steuerungsebene auswirken. Beispielsweise kann ein falsch konfigurierter Webhook, der von einer Drittanbieteranwendung erstellt wurde, verhindern, dass GKE on VMware Ressourcen im verwalteten Namespace kube-system erstellt und ändert. Dies kann die Funktionalität des Clusters beeinträchtigen.

Zu den 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. Folgen Sie der Anleitung, um die Pods des Dienstes, die diesen Webhook-Endpunkt sichern, zu ermitteln und Fehler zu beheben, um die Webhook-Endpunkte verfügbar zu machen:

  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 im Webhook aufgeführten Dienstnamen nicht finden können, wird der nicht verfügbare Endpunkt möglicherweise durch eine Diskrepanz zwischen dem in der Konfiguration angegebenen Namen und dem tatsächlichen Namen des Dienstes verursacht. Wenn Sie die Endpunktverfügbarkeit korrigieren möchten, aktualisieren Sie den Dienstnamen in der Webhook-Konfiguration so, dass er mit dem richtigen Dienstobjekt übereinstimmt.

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

    kubectl get deployment -n SERVICE_NAMESPACE

    Alternativ können Sie den folgenden Befehl ausführen, um die Pods aufzulisten:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

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

Als unsicher eingestufte Webhooks

Wenn ein Webhook Ressourcen in vom System verwalteten Namespaces abfängt, sollten Sie die Webhooks aktualisieren, um ein Abfangen dieser Ressourcen zu vermeiden.

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

  2. Bearbeiten Sie die Konfiguration abhängig davon, warum 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 Bedingung operator 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 * festgelegt ist, damit der Webhook nur in bestimmten Namespaces ausgeführt werden kann. Wenn operator auf NotIn gesetzt ist, müssen kube-system und kube-node-lease in values enthalten sein.

    • Die operator-Bedingung ist In. 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 werden kann. 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 „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.