Warum schlagen Cluster-Master-Vorgänge aufgrund eines fehlerhaften Webhooks fehl?

Virtuelle Private Cloud Klassische Infrastruktur

Dieses Fehlerbehebungsthema bezieht sich nicht auf die allgemeine Fehlerbehebung für Webhooks. Informationen zu Webhook-Problemen, die nicht mit der Aktualisierung des Cluster-Masters zusammenhängen, finden Sie unter Debugging webhooks.

Beheben Sie Probleme mit fehlerhaften Webhooks, die den Betrieb des Cluster-Masters beeinträchtigen.

Bei einer Operation des Masters, wie der Aktualisierung Ihrer Clusterversion, hatte der Cluster eine defekte Webhook-Anwendung.

Jetzt können Master-Operationen nicht abgeschlossen werden. Es wird eine Fehlernachricht ähnlich der folgenden angezeigt:

Cannot complete cluster master operations because the cluster has a broken webhook application. For more information, see the troubleshooting docs: 'https://ibm.biz/master_webhook'

Ihr Cluster verfügt über konfigurierbare Kubernetes-Webhook-Ressourcen, Zugangs-Webhooks vom Typ 'Validating' oder 'Mutating', die Anforderungen von unterschiedlichen Services im Cluster an den API-Server im Cluster-Master abfangen und modifizieren können.

Da Webhooks Änderungen an Anforderung vornehmen und Anforderungen zurückweisen können, können sich unterbrochene Webhooks auf verschiedene Weisen nachteilig auf die Funktionalität des Clusters auswirken, zum Beispiel dadurch, dass Sie die Masterversion nicht mehr aktualisieren können oder andere Wartungsoperationen nicht durchführen können. Weitere Informationen finden Sie unter Dynamic Admission Control in der Dokumentation zu Kubernetes.

Zu den möglichen Ursachen für unterbrochene Webhooks zählen unter anderem die folgenden:

Die zugrunde liegende Ressource, von der die Anforderung ausgegeben wird, wie zum Beispiel ein Kubernetes Service, ein Endpunkt oder ein Pod, fehlt entweder oder befindet sich nicht in einem einwandfreien Zustand.
Der Webhook ist Teil eines Add-ons oder einer anderen Plug-in-Anwendung, die nicht ordnungsgemäß installiert wurde oder sich nicht in einwandfreiem Zustand befindet.
Bei Ihrem Cluster liegt möglicherweise ein Problem mit der Netzkonnektivität vor, das den Webhook daran hindert, mit dem Kubernetes-API-Server im Cluster-Master zu kommunizieren.

Führen Sie die folgenden Befehle aus, um einen Test-Pod zu erstellen und einen Fehler zu erhalten, der den fehlerhaften Webhook identifiziert. Wenn der Test erfolgreich ist, war der Fehler möglicherweise nur vorübergehend und der Vorgang kann erneut versucht werden.

Führen Sie die folgenden Befehle aus, um den Test-Pod zu erstellen und den ibm-system Namespace zu kennzeichnen.

oc run webhook-test --image us.icr.io/armada-master/pause:3.10 -n ibm-system
oc delete pod -n ibm-system webhook-test --ignore-not-found
oc label ns ibm-system ibm-cloud.kubernetes.io/webhook-test-at="$(date -u +%FT%H_%M_%SZ)" --overwrite

Gegebenenfalls enthält die Fehlermeldung den Namen des unterbrochenen Webhooks. In der folgenden Beispielausgabe lautet der Webhook trust.hooks.securityenforcement.admission.cloud.ibm.com.

Error from server (InternalError): Internal error occurred: failed calling webhook "trust.hooks.securityenforcementadmission.cloud.ibm.com": Post https://ibmcloud-image-enforcement.ibm-system.svc:443/mutating-pods?timeout=30s: dialtcp 172.21.xxx.xxx:443: connect: connection timed out

Rufen Sie den Namen des unterbrochenen Webhooks ab.

Falls die Fehlermeldung einen unterbrochenen Webhook enthält, ersetzen Sie trust.hooks.securityenforcement.admission.cloud.ibm.com durch den zuvor ermittelten unterbrochenen Webhook.

    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations -o jsonpath='{.items[?(@.webhooks[*].name=="trust.hooks.securityenforcement.admission.cloud.ibm.com")].metadata.name}{"\n"}'
    ```
    Beispielausgabe
    ```sh {: pre}
    image-admission-config
    ```
*   Wenn die Fehlernachricht keinen defekten Webhook enthält, listen Sie alle Webhooks in Ihrem Cluster auf und überprüfen Sie deren Konfiguration in den folgenden Schritten.
```sh {: pre}
    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations
    ```

Überprüfen Sie die Service- und die Standortdetails der Konfiguration der Webhooks vom Typ 'Validating' bzw. 'Mutating' im Abschnitt clientConfig in der Ausgabe des folgenden Befehls. Ersetzen Sie image-admission-config durch den zuvor ermittelten Namen. Falls der Webhook außerhalb des Clusters vorhanden ist, setzen Sie sich mit dem Eigner des Clusters in Verbindung, um den Webhookstatus zu prüfen.
```
oc get mutatingwebhookconfiguration image-admission-config -o yaml
```
```
oc get validatingwebhookconfigurations image-admission-config -o yaml
```
Beispielausgabe
```
  clientConfig:
    caBundle: <redacted>
    service:
        name: <name>
        namespace: <namespace>
        path: /inject
        port: 443
```
Optional: Sichern Sie die Webhooks, insbesondere wenn Sie nicht wissen, wie Sie den Webhook neu installieren können oder nicht über die erforderlichen Berechtigungen zum Erstellen von Webhooks verfügen.
```
oc get mutatingwebhookconfiguration <name> -o yaml > mutatingwebhook-backup.yaml
```
```
oc get validatingwebhookconfiguration <name> -o yaml > validatingwebhook-backup.yaml
```

Prüfen Sie den Status des zugehörigen Service und der Pods für den Webhook.

Prüfen Sie den Inhalt der Felder für den Typ (Type), den Selektor (Selector) und den Endpunkt (Endpoint).

    oc describe service -n <namespace> <service_name>
    ```
2. Wenn der Diensttyp **ClusterIP** ist, stellen Sie sicher, dass sich der Konnectivity-Pod im Status **Running** befindet, damit der Webhook eine sichere Verbindung zur Kubernetes-API im Cluster-Master herstellen kann. Wenn der Pod nicht in einwandfreiem Zustand ist, überprüfen Sie die Pod-Ereignisse, die Protokolle, den Zustand des Workerknotens und andere Komponenten, die für die Fehlerbehebung infrage kommen.

    * Überprüfen Sie die Konnectivity-Agentenpods.
        ```sh {: pre}
        oc describe pods -n kube-system -l app=konnectivity-agent
        ```

1. Falls der Service keinen Endpunkt besitzt, überprüfen Sie den Zustand der Sicherungsressourcen, wie zum Beispiel einer Bereitstellung oder eines Pods. Wenn sich die Ressource nicht in einwandfreiem Zustand befindet, prüfen Sie die Podereignisse, die Protokolle, den Allgemeinzustand des Workerknotens und andere Komponenten zwecks Fehlerbehebung. Weitere Informationen finden Sie unter [Debugging für App-Bereitstellungen](/docs/openshift?topic=openshift-debug_apps).
```sh {: pre}
    oc get all -n my-service-namespace -l <key=value>
    ```
1. Falls für den Dienst keine Backing-Ressourcen vorhanden sind oder die Fehlerbehebung bei den Pods das Problem nicht behebt, entfernen Sie die zuvor identifizierte Konfiguration des mutierenden oder validierenden Webhooks.
```sh {: pre}
    oc delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    oc delete mutatingwebhookconfiguration NAME
    ```

Wiederholen Sie die Cluster-Master-Operation wie zum Beispiel das Aktualisieren des Clusters.
Wenn der Fehler weiterhin gemeldet wird, liegen möglicherweise Probleme mit dem Workerknoten oder mit der Netzkonnektivität vor.
- Beheben Sie Workerknotenfehler.
- Stellen Sie sicher, dass der Webhook eine Verbindung zum Kubernetes-API-Server im Cluster-Master herstellen kann. Wenn Sie beispielsweise die Calico-Netzrichtlinien, Sicherheitsgruppen oder eine andere Art von Firewall verwenden, richten Sie Ihren klassischen oder VPC-Cluster mit dem entsprechenden Zugriff ein.
- Wenn der Webhook von einem Add-on verwaltet wird, das von Ihnen installiert wurde, deinstallieren Sie das Add-on. Zu den gängigen Add-ons, die Probleme mit Webhooks verursachen können, zählen unter anderem die folgenden:
  - Portieris
Erstellen Sie den Webhook erneut oder installieren Sie das Add-on erneut.
Wenn das Problem weiterhin auftritt, wenden Sie sich bitte an den Support. Öffnen Sie einen Supportfall. Fügen Sie den Falldetails unbedingt alle relevanten Protokolldateien, Fehlermeldungen oder Befehlsausgaben bei.