Probleme bei der Trafficverwaltung in Anthos Service Mesh beheben

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

  • Übermäßig restriktive Pod-Sicherheitsrichtlinie (PSP)
  • Unvollständige Installation von istio-cni
  • Unzureichende Arbeitslast-Pod-Berechtigungen (fehlende CAP_NET_ADMIN-Berechtigung)

Wenn Sie eine Pod-Sicherheitsrichtlinie mit der Berechtigung CAP_NET_ADMIN verwenden, wechseln Sie stattdessen zum Istio CNI-Plug-in.

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 oder eine Pod-Sicherheitsrichtlinie 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

Problem: Wenn Sie Gateways mithilfe von kubectl get gateway --all-namespaces auflisten, nachdem Sie ein Anthos 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:

  1. 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

  2. Wenn in der Liste andere Einträge als Gateways mit dem apiVersion networking.istio.io/v1beta1 angezeigt werden, verwenden Sie im Befehl kubectl den vollständigen Ressourcennamen oder die erkennbaren Kurznamen. Führen Sie beispielsweise kubectl get gw oder kubectl get gateways.networking.istio.io anstelle von kubectl get gateway aus, damit die Istio-Gateways aufgelistet werden.

Weitere Informationen zu diesem Problem finden Sie unter Kubernetes-Gateways und Istio-Gateways.