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.

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.
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: Die enthält istio-sidecar-injector-asm-1232-2, 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-1232-2 -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.
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.
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.

istiod sendet keine Konfiguration an die Envoy-Proxys, wenn Probleme auftreten, z. B. durch ein RBAC-Problem, das das Lesen der Konfigurationsressource verhindert.
Falsche Discovery-Adresse (nicht fehlerfreie vorgelagerte Fehler)
Die für den Sidecar-Injektor angegebene Discovery-Adresse ist falsch. Wenn sehen Sie Logs, in denen gRPC config stream closed, no healthy upstream erwähnt wird. Prüfen Sie, ob die Erkennungsadresse im Mesh-Netzwerk ProxyConfig festgelegt ist. ist korrekt und verweist auf Ihren istiod-Dienst.
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.

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`	Für private Cluster muss Port 15017 geöffnet sein. Diese Fehlermeldung gibt an, dass Port 15017 möglicherweise nicht offen ist.	Achten Sie darauf, dass Ihre Firewallregeln eine Verbindung zu Istiod auf dem Port ermöglichen 15017. Weitere Informationen finden Sie unter Port in einem privaten Cluster öffnen.