Fehlerbehebung bei Webhook-Fehlern in IBM Cloud- Kubernetes-Clustern

Beheben Sie Probleme im Zusammenhang mit Webhooks in Ihrem IBM Cloud- Kubernetes-Cluster, indem Sie den problematischen Webhook identifizieren und debuggen.

Wenn Sie oc-Befehle ausführen, werden Fehlernachrichten ähnlich den folgenden Beispielen angezeigt.

Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out

error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s

Fehlgeschlagene Webhooks können auch zu Problemen wie den folgenden führen.

  • Sie können keine Pods, geheimen Schlüssel oder Namensbereiche erstellen oder ändern.
  • Sie können einem Cluster keine Workerknoten hinzufügen oder einen geheimen Schlüssel erstellen, der den LUKS-Verschlüsselungsschlüssel enthält.
  • Sie können kein Patch, Update oder Upgrade durchführen und der zugrunde liegende Fehler bezieht sich auf die Erstellung von Ressourcen im Cluster.

Ein Problem im aufgerufenen Service oder im sicheren Tunnel kann dazu führen, dass Anforderungen aufgrund von Zeitlimitüberschreitungen fehlschlagen. Sie wissen möglicherweise nicht, dass Sie Webhooks für Zugangssteuerung installiert haben, bis dies geschieht.

Webhooks für die Zugangssteuerung bieten die Möglichkeit, Kubernetes-API-Anforderungen zu validieren, zu ändern oder zu ändern. Diese Webhooks werden vom Cluster apiserver oder openshift-apiserver aufgerufen und rufen normalerweise einen Service auf, der im Cluster ausgeführt wird. Webhooks für die Zulassungskontrolle verfügen über Regeln, die die Art der Ressource (z. B. Pod, Namespace usw.) und den Vorgang, für den sie aufgerufen werden (z. B. Erstellen, Abrufen, Aktualisieren oder Löschen), definieren.

Webhooks verfügen über eine Fehlerrichtlinie, die angibt, ob Kubernetes Verbindungsfehler beim Aufrufen des Webhooks ignorieren kann oder ob Verbindungsfehler die Operation fehlschlagen müssen. Eine ValidatingWebhookConfiguration-Ressource überprüft die Anforderung, während eine MutatingWebhookConfiguration-Ressource die Anforderungsdaten ändert, bevor sie verarbeitet wird.

Webhooks können auch Anforderungen im Rahmen des normalen Betriebs verweigern: Ein Webhook kann Anforderungen zurückweisen, die gegen Sicherheitsrichtlinien verstoßen, oder andere Datenvalidierungen durchführen. In solchen Fällen enthalten die Fehlerinformationen eine denied the request-Antwort mit einer Fehlerursache.

admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported

In Red Hat OpenShift on IBM Cloudverwenden Webhooks, die im Cluster ausgeführte Services aufrufen, dazu einen sicheren Tunnel, der die Clustersteuerebene in einem IBM Cloud-Konto mit Cluster-Workerknoten in Ihrem Kundenkonto verbindet.

Führen Sie die folgenden Schritte aus, um den Webhook zu identifizieren, der das Problem verursacht. Debuggen Sie anschließend den zugehörigen Service und entfernen oder erstellen Sie Ihren Webhook bei Bedarf erneut.

  1. Führen Sie die folgenden Befehle aus, um die VPN-Pod-Protokolle abzurufen. Wenn Sie die VPN-Protokolle nicht abrufen können, führen Sie die Schritte zum Debuggen allgemeiner CLI-Probleme aus und kehren Sie zu dieser Seite zurück, wenn Sie die Protokolle abrufen können. Wenn die Befehle erfolgreich sind und Sie die Protokolle abrufen können, funktioniert der VPN-Tunnel und Sie können mit dem nächsten Schritt fortfahren.

    oc get pods -n kube-system -l app=vpn

    oc logs -n kube-system -l app=vpn

  2. Beschreiben Sie Ihre Webhooks für die Zugangssteuerung und speichern Sie die Ausgabe in einer Datei namens webhooks.txt.

    kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt

  3. Überprüfen Sie die Datei webhooks.txt auf Fehlernachrichten. Webhook-bezogene Fehlernachrichten einer Anwendung, einschließlich oc, können bei der Identifizierung des Webhooks helfen.

  4. Überprüfen Sie die API-Server-Metriken für den Zurückweisungstyp, die Anzahl und den Zurückweisungscode. Mit dem folgenden Befehl können Sie sich einen Überblick über die Kennzahlen verschaffen.

    kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count

    apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16

    Der Wert 0 für rejection_code gibt an, dass beim Aufrufen des Webhooks ein Fehler aufgetreten ist. Ein Wert ungleich null für rejection_code gibt an, dass der Webhook die Anforderung zurückgewiesen hat.

    Es gibt drei API-Server-Instanzen. Der Befehl oc ruft Metriken von einer von ihnen ab und spiegelt die Aktivität dort wider. Jeder API-Server gibt unterschiedliche Daten zurück. Instanzen, die die fehlgeschlagenen Anforderungen nicht verarbeitet haben, geben diese Metrik möglicherweise nicht zurück.

  5. Überprüfen Sie die Befehlsausgabe der vorherigen Schritte und suchen Sie nach Webhookbeschreibungen, um den jeweiligen MutatingWebhookConfiguration-oder ValidatingWebhookConfiguration-Wert zu ermitteln. Wenn die Fehler, Protokolle oder Metriken nicht helfen, überprüfen Sie die Webhookbeschreibungen, die Sie zuvor abgerufen haben. Jede Webhook-Konfiguration verfügt über eine Gruppe von Regeln, die angeben, für welche Arten von Ressourcen und Aktionen der Webhook aufgerufen wird. Diese Informationen können verwendet werden, um die möglichen Webhooks zu identifizieren.

    • Wenn beim Aufrufen des Webhooks ein Fehler auftritt, finden Sie in der Dokumentation zu diesem Service produktspezifische Fehlerbehebungsschritte.

    • Wenn der Webhook die Anforderungen zurückweist, sehen Sie sich die Richtlinien und Konfigurationsoptionen für den Webhook an. Möglicherweise können Sie sie anpassen, um die Anforderung zuzulassen. Oder die Anforderung verstößt möglicherweise gegen die Richtlinien und die Anforderung oder die Anwendung, die die Anforderung stellt, muss geändert werden. Weitere Informationen finden Sie unter Best Practices für die Verwendung von Webhooks.

Service überprüfen, den der Webhook aufruft

  1. Rufen Sie die Details des Service und seiner Endpunkte ab.

    kubectl get svc NAME -n NAMESPACE

    kubectl get ep NAME -n NAMESPACE

    • Wenn der Webhook einen Service aufruft, der nicht vorhanden ist, kann der Webhook von einem unvollständigen oder falschen Entfernen einer Anwendung übrig bleiben. Suchen Sie in diesem Fall nach servicespezifischer Dokumentation und führen Sie die Schritte zum Deinstallieren des Service aus.

    • Wenn Sie den Service nicht deinstallieren können, löschen Sie die Webhookkonfiguration.

        kubectl delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    kubectl delete mutatingwebhookconfiguration NAME
    ```

  2. Wenn der Service vorhanden ist, aber keine Endpunkte hat, überprüfen Sie den Zustand der Pod. Rufen Sie zuerst die Pod-Bezeichnungen aus dem Service ab.

    kubectl describe svc NAME -n NAMESPACE

    Beispielausgabe

    Selector:          app=my-webhook

  3. Listen Sie die Pods auf, die die Labels verwenden. Die Bezeichnung im folgenden Befehl lautet beispielsweise app=mywebhook.

    kubectl get pods -n NAMESPACE -l app=my-webhook

  4. Überprüfen Sie die Befehlsausgabe. Wenn die Pods nicht in ordnungsgemäßem Zustand sind, überprüfen Sie die Pod-Ereignisse, Protokolle, den Zustand der Worker-Knoten und andere Komponenten, um das Problem zu beheben. Weitere Informationen finden Sie unter Debugging für App-Bereitstellungen.

Webhook inaktivieren oder entfernen

  1. Ignorieren Sie vorübergehend Verbindungen und Zeitlimitüberschreitungen, indem Sie die Fehlerrichtlinie auf Ignore setzen. Bearbeiten Sie den Webhook, indem Sie die folgenden Befehle ausführen.

    kubectl edit validatingwebhookconfiguration NAME

    kubectl edit mutatingwebhookconfiguration NAME

  2. Suchen Sie nach failurePolicy und ändern Sie den Wert in Ignore.

  3. Speichern Sie die Konfiguration und schließen Sie den Editor. Wenn das Problem durch die Anpassung der Fehlerrichtlinie nicht behoben wird, wiederholen Sie die vorherigen Schritte und ändern Sie den Wert wieder in Fail.

  4. Entfernen Sie den Webhook vorübergehend. Speichern Sie die vorhandene Webhook-Konfiguration in einer Datei, bevor Sie sie löschen.

    kubectl get validatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

    kubectl get mutatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

  5. Löschen Sie die Webhook-Konfiguration.

    kubectl delete validatingwebhookconfiguration NAME

    kubectl delete mutatingwebhookconfiguration NAME

  6. Warten Sie einige Minuten und wiederholen Sie dann die kubectl-Befehle, die nicht feststellen konnten, ob das Problem behoben wurde.

  7. Erstellen Sie den Webhook erneut.

    kubectl apply -f webhook-config.yaml

  8. Wenn das Problem weiterhin auftritt, wenden Sie sich bitte an den Support. Öffnen Sie einen Supportfall. Stellen Sie in den Falldetails sicher, dass alle relevanten Protokolldateien, Fehlernachrichten oder Befehlsausgaben enthalten sind.