Probleme bei der Trafficverwaltung 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.
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 der Anleitung gefolgt sind
vollständig. Prüfen Sie, ob der istio-cni-node-Container bereit ist, und prüfen Sie den
Logs. Wenn das Problem weiterhin besteht, richten Sie eine Secure Shell (SSH) im Hostknoten ein
und suchen Sie in den Knotenlogs nach nsenter-Befehlen, um festzustellen, ob Fehler aufgetreten sind.
präsent sind.
Wenn Sie das Istio CNI-Plug-in nicht verwenden, prüfen Sie, ob der Arbeitslast-Pod
Die Berechtigung CAP_NET_ADMIN, die automatisch vom Sidecar-Injektor 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-proxyist:http://localhost:15020/healthz/readyFügen Sie Ihrer Anwendungsarbeitslast einen Anfragemechanismus für Wiederholungsversuche hinzu.
Die Ausgabe beim Auflisten von Gateways ist leer
Problem: Wenn Sie Gateways mithilfe von kubectl get gateway --all-namespaces auflisten, nachdem Sie ein Cloud Service Mesh-Gateway erfolgreich erstellt haben, gibt der Befehl No resources found zurück.
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 gatewayBeispielausgabe:
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
apiVersionnetworking.istio.io/v1beta1angezeigt werden, verwenden Sie im Befehlkubectlden vollständigen Ressourcennamen oder die erkennbaren Kurznamen. Führen Sie beispielsweisekubectl get gwoderkubectl get gateways.networking.istio.ioanstelle vonkubectl get gatewayaus, damit die Istio-Gateways aufgelistet werden.
Weitere Informationen zu diesem Problem finden Sie unter Kubernetes-Gateways und Istio-Gateways.