Sidecar-Proxy-/Webhook-Probleme in Cloud Service Mesh beheben

In diesem Abschnitt werden häufige Cloud Service Mesh-Probleme und deren Behebung erläutert . Weitere Informationen finden Sie unter Support.

Cloud Service Mesh enthält zwei Webhooks:

  • Der validierte Webhook sorgt dafür, dass die angewendete Istio-Konfiguration gültig ist.
  • Durch den mutierenden Webhook wird die automatische Sidecar-Einfügung für neue Pods festgelegt.

Ein Konfigurationsproblem in einem dieser Webhooks kann dazu führen, dass neue Pods nicht gestartet werden oder dass bei kubectl apply Fehlermeldungen auftreten.

Probleme bei der Sidecar-Einfügung

Wenn Sie ein verwaltetes Cloud Service Mesh bereitgestellt haben, wenden Sie sich bitte an den Support.

Die Sidecar-Einfügung funktioniert nicht richtig, wenn Folgendes angezeigt wird:

  • Pods, die ohne Sidecars planen
  • Pods, in die Sidecar-Dateien eingefügt werden sollen, werden nie angezeigt, kubectl get pods, aber das entsprechende Replikatset aus kubectl get replicaset ist vorhanden.

Führen Sie die folgenden Schritte aus, um Probleme bei der Sidecar-Einfügung zu beheben.

  1. Prüfen Sie, ob Ihr Namespace oder Pod das richtige Einfügelabel hat.

    Wenn Sie Istio mit einer einzigen Überarbeitung ausführen (die Standardeinstellung), prüfen Sie, ob Ihre Namespace- oder Pod-Spezifikation das Label „istio-injection=enabled“ enthält.

    Wenn Sie Istio mit mehreren Überarbeitungen ausführen (z. B. für Migrationen ohne Ausfallzeiten oder mehrere Steuerungsebenen), prüfen Sie, ob Ihre Namespace- oder Pod-Spezifikation das entsprechende istio.io/rev=REVISION-Label hat. Dabei gilt: REVISION ist die Überarbeitungsnummer des Cloud Service Mesh auf istiod, die der ausgewählten Cloud Service Mesh-Version entspricht. Weitere Informationen Informationen zu Überarbeitungslabels finden Sie unter Sidecar-Proxys einfügen.

  2. Prüfen Sie, ob Ihr Istio-Sidecar-Injection-Webhook vorhanden ist und über ein CA-Bundle verfügt.

    Der Sidecar-Injektor-Webhook, der für die automatische Sidecar-Einfügung verwendet wird, erfordert ein CA-Bundle, um sichere Verbindungen mit dem API-Server und istiod herzustellen. Dieses CA-Bundle wird von istiodin die Konfiguration eingefügt, kann aber manchmal überschrieben werden, beispielsweise wenn Sie die Webhook-Konfiguration neu anwenden.

    Mit diesem Befehl können Sie das Vorhandensein des CA-Bundles prüfen: Die enthält istio-sidecar-injector-asm-1225-1, was spezifisch für diese Version des Cloud Service Mesh. Achten Sie darauf, dass Sie Ihren tatsächlichen falls sie sich unterscheiden.

    kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1225-1 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'

    Wenn die Ausgabe nicht leer ist, ist das CA-Bundle konfiguriert. Wenn das CA-Bundle fehlt, starten Sie istiod neu, um den Webhook noch einmal zu scannen und das CA-Bundle neu zu installieren.

  3. Prüfen Sie, ob Fehler bei der Sidecar-Einfügung aufgetreten sind.

    Wenn Sie das Einfügen aktiviert haben, aber keine Pods geplant sind, prüfen Sie den Status der nächsthöheren Abstraktionsebene. Wenn Sie beispielsweise ein Deployment ausführen, aber keine Pods geplant sind, prüfen Sie den Status der entsprechenden Replikatsätze mit dem folgenden Befehl:

    kubectl -n my-namespace describe replicaset your-deployment-name

    Wenn das Replikatset vorhanden ist, prüfen Sie das Ereignislog am Ende der Beschreibung auf Fehler. Wenn sich der Fehler auf die Sidecar-Einfügung bezieht, prüfen Sie die istiod-Logs auf eine mögliche Fehlerursache.

  4. Sollte das Problem weiterhin bestehen, kann das folgende Gründe haben:

    • Fehlerhafte Injector-Konfiguration
    • Probleme mit der Firewallkonfiguration
    • Ein Problem im Istio-Code selbst

    Weitere Diagnoseschritte finden Sie unter Fehlerbehebung bei Istio.

Envoy-Proxys erhalten keine Konfiguration von istiod

Es gibt mehrere Probleme, die verhindern, dass Proxys Konfigurationen von istiod empfangen.

  1. istiod überträgt die Konfiguration nicht per Push an die Envoy-Proxys, wenn Probleme auftreten. z. B. aufgrund eines RBAC-Problems, das die Konfigurationsressource nicht lesen kann.

  2. Falsche Discovery-Adresse (nicht fehlerfreie vorgelagerte Fehler)

  3. Die für den Sidecar-Injektor angegebene Discovery-Adresse ist falsch. Wenn Sie Logs sehen, in denen gRPC config stream closed, no healthy upstream erwähnt wird, prüfen Sie, ob die Discovery-Adresse im Mesh ProxyConfig stimmt und auf Ihren istiod-Dienst verweist.

  4. Ungültige Konfiguration zum Übertragen an den Proxy. In diesem Fall wird die Konfiguration erfolgreich an den Proxy übertragen, aber die Konfiguration ist ungültig. Es werden wiederkehrende Nachrichten wie die folgenden angezeigt:

    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected

    In diesem Beispiel ist cds der Cluster Discovery Service, der ein von istiod aktualisiertes Update meldet, und lds der Listener Discovery Service, für den eine Aktualisierung von istiod abgelehnt wird. Oft wird in einer früheren Fehlermeldung der Grund für die Ablehnung angezeigt, der normalerweise mit einer Warnung zur Envoy-Konfiguration oder Ähnlichem beginnt.

    Zur Behebung des Problems untersuchen Sie die Ursache der abgelehnten Konfiguration. Eine häufige Ursache sind ungültige EnvoyFilter-Ressourcen. Wenn kein Grund angegeben ist, senden Sie einen Fehlerbericht mit einem Konfigurations-Dump des Proxys.

Pod-Erstellung schlägt fehl

Wenn Sie feststellen, dass Pods nicht erfolgreich erstellt werden, suchen Sie mithilfe des folgenden Befehls nach Fehlermeldungen, die möglicherweise Aufschluss über das Kernproblem geben:

kubectl describe replicaset YOUR_REPLICA_SET

Häufige Fehlermeldungen aus dem Webhook

Fehlermeldungen, die vom Befehl kubectl apply ausgegeben werden, können einen Hinweis auf ihre Ursache geben. In der folgenden Tabelle finden Sie häufig auftretende Fehlermeldungen, deren Ursachen sowie mögliche Lösungen.

Fehlermeldung Ursache Lösung
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) Möglicherweise liegt ein Problem mit der Netzwerkverbindung vor. Achten Sie darauf, dass Ihre Firewallregeln an Port 15017 eine Verbindung zu Istiod ermöglichen.
no endpoints available for service 'istiod' Das kann passieren, wenn der Istiod-Pod nicht verfügbar oder nicht bereit ist. Prüfen Sie, ob die Istiod-Pods ausgeführt werden und bereit sind.
Service "istiod" not found Das kann auftreten, wenn der Istiod-Dienst nicht vorhanden ist. Prüfen Sie, ob Ihre Istio-Installation erfolgreich war und korrekt ist.
x509: certificate signed by unknown authority Hier kann ein Problem mit dem Webhook-Zertifikat vorliegen. Prüfen Sie, ob caBundle für den Webhook korrekt festgelegt ist.
Failed to update validatingwebhookconfiguration istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail, resourceVersion=[version]): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istio-validator-asm-[version-n]-istio-system": the object has been modified; please apply your changes to the latest version and try again. Ein deinstalliertes Validierungs-Webhook aus einer alten Version von Istio oder Cloud Service Mesh kann ein Upgrade oder eine Installation beeinträchtigen. Prüfen Sie, ob noch alle Webhooks im Cluster vorhanden sind, und entfernen Sie alle Webhooks, die auf nicht mehr installierte Versionen verweisen.
Error from server (InternalError): Internal error occurred: failed calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded Bei privaten Clustern muss Port 15017 geöffnet sein. Diese Fehlermeldung weist darauf hin, dass Port 15017 möglicherweise nicht geöffnet ist. Achten Sie darauf, dass Ihre Firewallregeln an Port 15017 eine Verbindung zu Istiod ermöglichen. Weitere Informationen finden Sie unter Port in einem privaten Cluster öffnen