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

In diesem Abschnitt werden häufig auftretende 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

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

• Pods, die ohne Sidecars planen
• Pods, in die Sidecars eingefügt werden sollten, werden bei Verwendung von kubectl get pods nie angezeigt, aber das entsprechende Replikatset von 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 (für Migrationen ohne Ausfallzeiten, Steuerungsebenen usw.), 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 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 istiod in 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: Der Befehl enthält istio-sidecar-injector-asm-1157-23, das für diese Version von Cloud Service Mesh spezifisch ist. Verwenden Sie die tatsächliche Version, falls sie sich unterscheidet.

   kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1157-23 -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 sendet keine Konfiguration an die Envoy-Proxys, wenn Probleme auftreten, z. B. durch ein RBAC-Problem, das das Lesen der Konfigurationsressource verhindert.

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-Dienst ist, 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.