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 an den Support.
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 vonkubectl 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 (für Migrationen ohne Ausfallzeiten) ausführen, mehrere Steuerungsebenen usw. haben), prüfen Sie, ob in Ihrem Namespace oder Ihrer Pod-Spezifikation das entsprechende
istio.io/rev=REVISION
-Label, wobei REVISION ist die Überarbeitungsnummer des Cloud Service Mesh füristiod
. der Ihrer ausgewählten Cloud Service Mesh-Version entspricht. Weitere Informationen 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 vonistiod
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-1215-7
, das für diese Version von Cloud Service Mesh spezifisch ist. Achten Sie darauf, dass Sie Ihren tatsächlichen falls sie sich unterscheiden.kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1215-7 -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
ü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.Falsche Discovery-Adresse (nicht fehlerfreie vorgelagerte Fehler)
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 MeshProxyConfig
stimmt und auf Ihrenistiod
-Dienst verweist.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 1 vonistiod
übermittelte Aktualisierung) undlds
ist der Listener Discovery Service. (Dabei wird 1 Update vomistiod
abgelehnt). Häufig sehen Sie eine frühere Fehlermeldung, in der der Grund für die Ablehnung erläutert wird. beginnt normalerweise mit einer Warnung zur Envoy-Konfiguration oder Ähnlichem.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. |
Einen validierenden Webhook aus einer alten Version von Istio oder Das deinstallierte Cloud Service Mesh stört möglicherweise ein ein Upgrade oder eine Installation durchführen. | 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 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 |