Probleme bei der Trafficverwaltung 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.
API-Server-Verbindungsfehler in Istiod-Logs
Istiod kann keine Verbindung zum apiserver
herstellen, wenn Fehler angezeigt werden, die in etwa so aussehen:
error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused
Sie können den regulären Ausdruck /error.*cannot list resource/
verwenden, um diesen Fehler in den Logs zu finden.
Dieser Fehler ist in der Regel nur vorübergehend. Wenn Sie die Proxylogs mit kubectl
erreicht haben, ist das Problem möglicherweise bereits behoben. Dieser Fehler wird normalerweise durch Ereignisse verursacht, die den API-Server vorübergehend nicht verfügbar machen, z. B. wenn ein API-Server, der sich nicht in einer Hochverfügbarkeitskonfiguration befindet, für ein Upgrade oder eine Autoscaling-Änderung neu gestartet wird.
Der istio-init
-Container stürzt ab
Dieses Problem kann auftreten, wenn die Pod-iptables-Regeln nicht auf den Namespace des Pod-Netzwerks angewendet werden. Mögliche Ursachen:
- Unvollständige Installation von istio-cni
- Unzureichende Arbeitslast-Pod-Berechtigungen (fehlende
CAP_NET_ADMIN
-Berechtigung)
Wenn Sie das Istio CNI-Plug-in verwenden, prüfen Sie, ob Sie die Anleitung vollständig befolgt haben.
Prüfen Sie, ob der istio-cni-node
-Container bereit ist, und kontrollieren Sie die Logs. Wenn das Problem weiterhin besteht, stellen Sie eine sichere Shell (SSH) im Hostknoten her und suchen Sie in den Knotenlogs nach nsenter
-Befehlen und prüfen Sie, ob Fehler vorhanden sind.
Wenn Sie nicht das Istio CNI-Plug-in verwenden, achten Sie darauf, dass der Arbeitslast-Pod die Berechtigung CAP_NET_ADMIN
hat, die vom Sidecar-Injektor automatisch festgelegt wird.
Die Verbindung wurde nach dem Start des Pods abgelehnt
Wenn ein Pod gestartet wird und connection refused
für die Verbindung mit einem Endpunkt versucht, könnte das Problem sein, dass der Anwendungscontainer vor dem isto-proxy
-Container gestartet wurde. In diesem Fall sendet der Anwendungscontainer die Anfrage an istio-proxy
, aber die Verbindung wird abgelehnt, da istio-proxy
den Port noch nicht überwacht.
In diesem Fall haben Sie folgende Möglichkeiten:
Ändern Sie den Startcode Ihrer Anwendung so, dass kontinuierlich Anfragen an den
istio-proxy
-Systemdiagnose gesendet werden, bis die Anwendung den Code 200 empfängt. Der Endpunkt "health"istio-proxy
ist:http://localhost:15020/healthz/ready
Fügen Sie Ihrer Anwendungsarbeitslast einen Anfragemechanismus für Wiederholungsversuche hinzu.
Die Ausgabe beim Auflisten von Gateways ist leer
Symptom: Wenn Sie Gateways mit kubectl get gateway --all-namespaces
auflisten
nachdem ein Cloud Service Mesh Gateway erstellt wurde, gibt der Befehl
No resources found
.
Dieses Problem kann unter GKE 1.20 und höher auftreten, da der GKE-Gateway-Controller die GKE-Ressource Gateway.networking.x-k8s.io/v1alpha1
automatisch in Clustern installiert. Problemumgehung:
Prüfen Sie, ob der Cluster mehrere benutzerdefinierte Gateway-Ressourcen enthält:
kubectl api-resources | grep gateway
Beispielausgabe:
gateways gw networking.istio.io/v1beta1 true Gateway gatewayclasses gc networking.x-k8s.io/v1alpha1 false GatewayClass gateways gtw networking.x-k8s.io/v1alpha1 true Gateway
Wenn in der Liste andere Einträge als Gateways mit dem
apiVersion
networking.istio.io/v1beta1
angezeigt werden, verwenden Sie im Befehlkubectl
den vollständigen Ressourcennamen oder die erkennbaren Kurznamen. Führen Sie beispielsweisekubectl get gw
oderkubectl get gateways.networking.istio.io
anstelle vonkubectl get gateway
aus, damit die Istio-Gateways aufgelistet werden.
Weitere Informationen zu diesem Problem finden Sie unter Kubernetes-Gateways und Istio-Gateways.