Probleme bei der Trafficverwaltung in Cloud Service Mesh beheben

In diesem Abschnitt werden häufig auftretende Probleme bei Cloud Service Mesh und deren Behebung beschrieben. Weitere Informationen finden Sie unter Support.

Fehler bei der API-Serververbindung 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 prüfen 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 das Istio CNI-Plug-in nicht 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 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:

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.

Envoy-Proxy hängt bei der Initialisierung

Wenn Debug-Logs darauf hinweisen, dass der Envoy-Proxy während der Initialisierung hängt, können Sie mit dem folgenden Befehl ermitteln, was den Prozess blockiert:

kubectl -n <ns> -c istio-proxy exec -it POD_NAME -- /usr/local/bin/pilot-agent request POST /init_dump

Fehlerbehebung bei HTTP-Antwortfehlern vom Typ 5xx

Beim Zugriff auf Anwendungen über das Istio-Ingress-Gateway können HTTP-Antwortfehler vom Typ 5xx auftreten. Führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren und zu beheben.

1. Steuerungsebene identifizieren
2. Mögliche Fehlkonfigurationen prüfen
3. Pod-Erkennung prüfen
4. Zugriffslogs analysieren

Steuerungsebene identifizieren

Bestimmen Sie die Version und Konfiguration der Steuerungsebene, da sich verschiedene Versionen auf die Diagnoseprozesse auswirken können. Führen Sie den folgenden Befehl aus, um den Status der verwalteten Steuerungsebene zu prüfen:

gcloud container fleet mesh describe --project PROJECT_ID

Der Status ACTIVE gibt an, dass die verwaltete Steuerungsebene normal ausgeführt wird.

Mögliche Fehlkonfigurationen prüfen

Häufige Fehlkonfigurationen können zu Routingfehlern führen:

• Namespace-Konflikt: Der VirtualService muss sich im selben Namespace wie der GKE-Backend-Dienst befinden.
• Konflikt bei der Gateway-Referenz: Der VirtualService muss explizit auf das richtige Gateway verweisen. Wenn der VirtualService beispielsweise auf istio-system/istio-ingressgateway verweist, sich das Gateway aber im Namespace default befindet, wird der Traffic nicht korrekt weitergeleitet.

Pod-Erkennung prüfen

Achten Sie darauf, dass der Anwendungspod vom Mesh-Netzwerk korrekt erkannt wird:

istioctl proxy-config endpoints POD_NAME

Zugriffslogs analysieren

Aktivieren Sie Zugriffslogs, um zu ermitteln, ob Fehler von der Backend-Anwendung oder vom Proxy stammen. Wichtige Felder sind RESPONSE_FLAGS, UPSTREAM_LOCAL_ADDRESS und RESPONSE_CODE.

Wenn Logs Upstream-Fehler anzeigen, führen Sie einen direkten curl-Test für den GKE-Dienst von einem Pod im selben Namespace aus. Wenn die curl-Anfrage denselben 5xx-Fehler zurückgibt, stammt das Problem von der Backend-Anwendung selbst.

Fehlerbehebung bei SSL-Zertifikatproblemen

SSL-Zertifikatfehler am Istio-Ingress-Gateway können durch abgelaufene Zertifikate, Protokollkonflikte oder falsche Secret-Konfigurationen verursacht werden.

SSL-Fehler identifizieren

Prüfen Sie die Logs aus dem Istio-Ingress-Gateway-Pod:

kubectl logs -l app=istio-ingressgateway -n GATEWAY_NAMESPACE

Zertifikate und Schlüssel prüfen

Achten Sie darauf, dass das Zertifikat und der private Schlüssel gültig sind und übereinstimmen. Verwenden Sie dazu MD5-Hashes:

openssl x509 -noout -modulus -in CERTIFICATE.CRT | openssl md5
openssl rsa -noout -modulus -in PRIVATE_KEY | openssl md5

Prüfen Sie, ob das Zertifikat nicht abgelaufen ist und ob der allgemeine Name (Common Name, CN) oder der alternative Antragstellername (Subject Alternative Name, SAN) mit der Domain übereinstimmt.

TLS-Protokoll und Secret-Konfiguration prüfen

Prüfen Sie die TLS-Version und die Chiffresammlungen in der Gateway-CRD. Achten Sie darauf, dass sich das Kubernetes-Secret mit dem Zertifikat und dem Schlüssel im selben Namespace wie das Ingress-Gateway befindet und dass credentialName mit dem Secret-Namen übereinstimmt.

Fehlerbehebung bei zeitweiligen Timeouts für externe Endpunkte

Zeitweilige Timeouts können auftreten, wenn Anfragen an externe Endpunkte (z. B. NLB von Drittanbietern) gestellt werden, die zu mehreren IP-Adressen aufgelöst werden.

Mögliche Ursache: Auflösung von ServiceEntry

Wenn spec.resolution auf DNS gesetzt ist, verwendet Istio „strikte DNS“, die den Lastenausgleich über alle aufgelösten IP-Adressen hinweg durchführt. Einige NLBs unterstützen dies nicht.

Lösung

Setzen Sie die Auflösung für den ServiceEntry auf DNS_ROUND_ROBIN, um dieses Problem zu beheben.

Fehlerbehebung bei ungleichmäßiger Trafficverteilung

Wenn der Traffic nicht gleichmäßig auf die Anwendungspods verteilt ist, prüfen Sie Folgendes:

• Pod-Status: Achten Sie darauf, dass alle Anwendungspods während des Ungleichgewichts fehlerfrei waren.
• Load-Balancing-Algorithmus: Prüfen Sie die DestinationRule Konfiguration für die loadBalancer Einstellung (z.B. consistentHash oder ROUND_ROBIN).
• Ort-Load-Balancing: Prüfen Sie, ob localityLbSetting aktiviert ist. Diese Einstellung wird nicht von der TRAFFIC_DIRECTOR-Steuerungsebene unterstützt.

Fehlerbehebung bei der Dienstweitergabe und Kontingentproblemen

Hinweis: Dies gilt nur für Cloud Service Mesh mit Traffic Director Implementierung.

Wenn neue Dienste oder Netzwerkkonfigurationen nicht im Mesh-Netzwerk berücksichtigt werden, kann dies daran liegen, dass die Ressourcenkontingente im Flottenprojekt erreicht wurden.

Symptome

• Netzwerkkonfigurationen wie VirtualService oder DestinationRule werden nicht an Sidecar-Proxys übertragen.
• Neue Dienste sind für das Mesh-Netzwerk „unsichtbar“, obwohl sie korrekt definiert sind.

Schritte zur Identifizierung und Behebung

1. Ressourcenkontingente prüfen: Prüfen Sie, ob das Flottenprojekt sein Kontingent für BackendService Ressourcen erreicht hat. Prüfen Sie dazu das Kontingent Globale interne Traffic Director-Backend-Dienste im Flottenprojekt. Cloud Service Mesh erstellt in der Regel einen BackendService pro Kubernetes-Dienstport.
2. Skalierungsgrenzen prüfen: Achten Sie darauf, dass Ihre Konfiguration die unterstützten Skalierungsgrenzen für Cloud Service Mesh nicht überschreitet.
3. Kontingente erhöhen: Wenn Kontingente erreicht wurden, fordern Sie eine Erhöhung für die betroffene Ressource im Flottenprojekt an, um die normale Dienst weitergabe wiederherzustellen.

Fehlerbehebung bei der Auswertung von VirtualService

Wenn sich ein VirtualService nicht wie erwartet verhält, denken Sie daran, dass Routen in der Reihenfolge ausgewertet werden, in der sie aufgeführt sind. Wenn Sie mehrere Virtual Services für denselben Host haben, werden ihre Routen zusammengeführt. Die Routen aus „älteren“ Virtual Services haben eine höhere Priorität und werden daher in der zusammengeführten Liste vor Routen aus „neueren“ Virtual Services platziert. Dadurch wird die Regel „Erste Übereinstimmung“ verstärkt.

Fehlerbehebung beim Ort-Load-Balancing

Standardmäßig leitet das Ort-Load-Balancing den Client-Traffic an Endpunkte in derselben Zone weiter (die primäre Zone oder Priorität 0). Envoy leitet den Traffic nur an Failover-Zonen (Priorität 1 oder höher) weiter, wenn Endpunkte in der primären Zone fehlerhaft oder nicht verfügbar sind.

Wenn Sie Ihre Endpunkte nicht so skalieren, dass sie die gesamte zonale Last bewältigen können, oder wenn Sie den Traffic auf mehrere Zonen aufteilen möchten, haben Sie folgende Möglichkeiten:

• Skalieren Sie die Pods in den jeweiligen Zonen, um die lokale Trafficlast zu bewältigen.
• Deaktivieren Sie die Einstellung für das Ort-Load-Balancing.

Einstellungen für das Ort-Load-Balancing identifizieren

Das Ort-Load-Balancing verwendet Knoten-Topologie-Labels, um Endpunkte zu gruppieren. Verwenden Sie die folgenden Befehle, um Knotenlabels zu prüfen und Einstellungen zu prüfen:

• Knoten-Topologie-Labels prüfen:

  kubectl get nodes -o custom-columns=NAME:.metadata.name,\
      REGION:.metadata.labels."topology\\.kubernetes\\.io/region",\
      ZONE:.metadata.labels."topology\\.kubernetes\\.io/zone"
  

• Prüfen Sie für GKE-DestinationRules die Ortseinstellungen:

  kubectl get destinationrule DESTINATION_RULE_NAME -o yaml
  

  Suchen Sie in der Ausgabe nach localityLbSetting: enabled: true.

• So prüfen Sie Envoy-Proxy-Endpunkte, ‑Prioritäten und ‑Status:

  istioctl proxy-config endpoints POD_NAME.NAMESPACE \
      --cluster "outbound|PORT||SERVICE_FQDN" -o json
  

  Suchen Sie in der Endpunktkonfiguration nach dem Feld priority.

• So rufen Sie die detaillierte Konfiguration der aktiven Cluster auf:

  istioctl proxy-config cluster POD_NAME.NAMESPACE \
      --fqdn SERVICE_FQDN -o json