Anthos Service Mesh und Traffic Director sind jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Übersicht zum Cloud Service Mesh.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Envoy-Bereitstellungen

Dieser Leitfaden enthält Informationen zum Beheben von Konfigurationsproblemen mit Envoy-Clients, wenn Sie Cloud Service Mesh mit Google APIs ausführen. Informationen zur Verwendung der Client Status Discovery Service (CSDS) API zur Untersuchung von Problemen mit Cloud Service Mesh finden Sie unter Informationen zum Cloud Service Mesh-Clientstatus.

Auf einer VM installierte Envoy-Version ermitteln

Anhand dieser Anleitung können Sie prüfen, welche Version von Envoy auf einer VM-Instanz ausgeführt wird.

Zum Prüfen oder Prüfen der Envoy-Version können Sie einen der folgenden Schritte ausführen:

Prüfen Sie die Gastattribute der VM unter dem Pfad gce-service-proxy/proxy-version:

gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME
--zone ZONEc --query-path=gce-service-proxy/proxy-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Prüfen Sie die Cloud Logging-Instanzlogs auf der Seite "Logging" der VM-Instanzdetails in der Google Cloud Console mit einer Abfrage wie dieser:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

Sie erhalten eine Antwort wie die folgende:

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

Stellen Sie eine SSH-Verbindung zu einer VM her und prüfen Sie die Binärversion:

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Stellen Sie eine SSH-Verbindung zu einer VM und der Administratoroberfläche als Root her:

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

Logspeicherorte in Envoy

Zur Behebung einiger Fehler müssen Sie die Proxy-Logs von Envoy prüfen.

Über SSH können Sie eine Verbindung zur VM-Instanz herstellen, um die Logdatei abzurufen. Der Pfad ist wahrscheinlich wie folgt.

  /var/log/envoy/envoy.err.log

Proxys können keine Verbindung zum Cloud Service Mesh herstellen

Wenn Ihre Proxys keine Verbindung zu Cloud Service Mesh herstellen können, gehen Sie so vor:

Prüfen Sie die Proxy-Logs von Envoy auf Fehler der Verbindung mit trafficdirector.googleapis.com.
Wenn Sie netfilter (über iptables) so eingerichtet haben, dass der gesamte Traffic an den Envoy-Proxy weitergeleitet wird, achten Sie darauf, dass der Nutzer (UID), mit dem Sie den Proxy ausführen, von der Weiterleitung ausgeschlossen ist. Andernfalls führt dies dazu, dass der Traffic ständig zum Proxy zurückgeleitet wird.
Prüfen Sie, ob die API für das Projekt aktiviert ist. Suchen Sie unter APIs und Dienste für Ihr Projekt nach Fehlern für die Cloud Service Mesh API.
Prüfen Sie, ob der API-Zugriffsbereich der VM so eingestellt ist, dass uneingeschränkter Zugriff auf die Google Cloud APIs möglich ist. Geben Sie dazu beim Erstellen der VM Folgendes an:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Prüfen Sie, ob das Dienstkonto die richtigen Berechtigungen hat. Weitere Informationen finden Sie unter Dienstkonto für den Zugriff auf die Traffic Director API aktivieren.
Prüfen Sie, ob Sie von der VM auf trafficdirector.googleapis.com:443 zugreifen können. Wenn es Probleme mit diesem Zugriff gibt, könnte dies daran liegen, dass eine Firewall den Zugriff auf trafficdirector.googleapis.com über den TCP-Port 443 verhindert oder Probleme mit der DNS-Auflösung für den Hostnamen trafficdirector.googleapis.com vorliegen.
Wenn Sie Envoy für den Sidecar-Proxy verwenden, prüfen Sie, ob die Envoy-Version 1.24.9 oder höher ist.

Der mit Cloud Service Mesh konfigurierte Dienst ist nicht erreichbar

Wenn ein mit Cloud Service Mesh konfigurierter Dienst nicht erreichbar ist, prüfen Sie, ob der Sidecar-Proxy ausgeführt wird und eine Verbindung zu Cloud Service Mesh hergestellt werden kann.

Wenn Sie Envoy als Sidecar-Proxy verwenden, können Sie dies mit den folgenden Befehlen prüfen:

Prüfen Sie in der Befehlszeile, ob der Envoy-Prozess ausgeführt wird:
```
ps aux | grep envoy
```
Prüfen Sie die Laufzeitkonfiguration von Envoy, um zu bestätigen, dass Cloud Service Mesh dynamische Ressourcen konfiguriert hat. Führen Sie den folgenden Befehl aus, um die Konfiguration aufzurufen:
```
curl http://localhost:15000/config_dump
```
Achten Sie darauf, dass das Abfangen von Traffic für den Sidecar-Proxy korrekt eingerichtet ist. Führen Sie für die Weiterleitungskonfiguration mit iptables den Befehl iptables und dann grep für die Ausgabe aus, um zu prüfen, ob Ihre Regeln vorhanden sind:
```
sudo iptables -t nat -S | grep ISTIO
```
Hier ein Beispiel für die Ausgabe, die Sie erhalten, wenn iptables die virtuelle IP-Adresse (VIP) 10.0.0.1/32 abfängt und an einen Envoy-Proxy weiterleitet, der an Port 15001 als UID1006 ausgeführt wird:
```
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
```

Wenn die VM-Instanz über die Google Cloud Console erstellt wird, sind einige IPv6-bezogene Module nicht installiert und vor einem Neustart verfügbar. Dies führt dazu, dass iptables aufgrund fehlender Abhängigkeiten fehlschlägt. Starten Sie in diesem Fall die VM neu und führen Sie den Einrichtungsprozess noch einmal aus, um das Problem zu beheben. Bei einer Compute Engine-VM, die Sie mithilfe der Google Cloud CLI erstellt haben, wird dieses Problem nicht erwartet.

Der Dienst ist nicht mehr erreichbar, wenn das Zugriffs-Logging von Envoy konfiguriert ist

Wenn Sie TRAFFICDIRECTOR_ACCESS_LOG_PATH zum Konfigurieren eines Envoy-Zugriffslogs verwendet haben, wie unter Envoy-Bootstrap-Attribute für Cloud Service Mesh konfigurieren beschrieben, muss der Systemnutzer, der den Envoy-Proxy ausführt, Berechtigungen zum Schreiben in den angegebenen Speicherort des Zugriffslogs haben.

Ohne die erforderlichen Berechtigungen werden die Listener nicht auf dem Proxy programmiert. Dies erkennen Sie an der folgenden Fehlermeldung im Proxy-Log von Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Ändern Sie zur Behebung des Problems die Berechtigungen für die ausgewählte Datei, damit der Envoy-Nutzer Schreibzugriff auf das Zugriffslog erhält.

Fehlermeldungen in den Envoy-Logs, die auf ein Konfigurationsproblem hinweisen

Dieser Abschnitt gilt für Bereitstellungen, die die Load Balancing APIs verwenden.

Wenn Probleme mit der Cloud Service Mesh-Konfiguration auftreten, wird in den Envoy-Logs möglicherweise eine der folgenden Fehlermeldungen angezeigt:

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.

Cloud Service Mesh configuration was not found.

Die letzte Fehlermeldung (Traffic Director configuration was not found) gibt im Allgemeinen an, dass Envoy eine Konfiguration von Cloud Service Mesh anfordert, aber keine übereinstimmende Konfiguration gefunden wurde. Wenn Envoy eine Verbindung zu Cloud Service Mesh herstellt, wird ein VPC-Netzwerkname angezeigt (z. B. my-network). Cloud Service Mesh sucht dann nach Weiterleitungsregeln mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED und verweisen auf denselben VPC-Netzwerknamen.

So beheben Sie diesen Fehler:

Achten Sie darauf, dass in Ihrem Netzwerk eine Weiterleitungsregel mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED vorhanden ist. Notieren Sie sich den VPC-Netzwerknamen der Weiterleitungsregel.
Wenn Sie Cloud Service Mesh mit automatischen Envoy-Bereitstellungen in Compute Engine verwenden, achten Sie darauf, dass der Wert für das Flag --service-proxy:network mit dem VPC-Netzwerknamen der Weiterleitungsregel übereinstimmt.
Wenn Sie Cloud Service Mesh mit manuellen Envoy-Bereitstellungen in Compute Engine verwenden, prüfen Sie die Bootstrap-Datei von Envoy auf Folgendes:
1. Achten Sie darauf, dass der Wert für die Variable TRAFFICDIRECTOR_NETWORK_NAME mit dem VPC-Netzwerknamen der Weiterleitungsregel übereinstimmt.
2. Achten Sie darauf, dass in der Variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER die Projektnummer festgelegt ist.
Wenn Sie in GKE bereitstellen und den automatischen Injektor verwenden, müssen Sie dafür sorgen, dass die Projektnummer und der VPC-Netzwerkname richtig konfiguriert sind. Folgen Sie dazu der Anleitung unter Cloud Service Mesh-Einrichtung für GKE-Pods mit automatischer Envoy-Injection.

Fehlerbehebung bei Compute Engine

Dieser Abschnitt enthält Anleitungen zur Fehlerbehebung bei Envoy-Bereitstellungen für Compute Engine.

Die Bootstrapping-Prozesse von Envoy und den VMs sowie weitere Vorgänge des Lebenszyklusmanagements können aus verschiedensten Gründen fehlschlagen. Zu diesen Gründen zählen vorübergehende Verbindungsprobleme, fehlerhafte Repositories, Programmfehler in Bootstrapping-Skripts und VM-Agents sowie unerwartete Nutzeraktionen.

Kommunikationskanäle zur Fehlerbehebung

Google Cloud bietet Kommunikationskanäle, dank derer Sie den Bootstrapping-Prozess und den aktuellen Status der Komponenten, die auf Ihren VMs existieren, besser verstehen können.

Logging der Ausgabe des virtuellen seriellen Ports

Das Betriebssystem, das BIOS und andere Entitäten auf Systemebene einer VM schreiben die Ausgaben normalerweise an die seriellen Ports. Diese Ausgabe ist nützlich, um Systemabstürze, fehlgeschlagene Start- und Startprobleme sowie Probleme beim Herunterfahren zu beheben.

Compute Engine-Bootstrapping-Agents protokollieren alle ausgeführten Aktionen im seriellen Port 1. Dies umfasst Systemereignisse, beginnend mit der einfachen Paketinstallation bis zum Abrufen von Daten vom Metadatenserver einer Instanz, der iptables-Konfiguration und dem Envoy-Installationsstatus.

VM-Agents protokollieren den Envoy-Prozessstatus, neu erkannte Cloud Service Mesh-Dienste und alle anderen Informationen, die bei der Untersuchung von Problemen mit VMs hilfreich sein können.

Logging mit Cloud Monitoring

Daten, die über den seriellen Port ausgegeben werden, werden auch in Monitoring protokolliert. Monitoring nutzt die Golang-Bibliothek und exportiert die Logs in ein separates Log, um Störungen zu reduzieren. Dieses Log wird auf Instanzebene erstellt. Daher finden sich Dienstproxy-Logs möglicherweise auf derselben Seite wie die anderen Instanzlogs.

VM-Gastattribute

Gastattribute sind ein spezieller Typ benutzerdefinierter Metadaten, in die Anwendungen Daten schreiben können, während sie auf der Instanz ausgeführt werden. Jede Anwendung und jeder Nutzer auf der Instanz kann Daten aus den Metadaten der Gastattribute lesen und in diese schreiben.

Bootstrap-Skripts von Envoy in Compute Engine und VM-Agents stellen Attribute mit Informationen zum Bootstrapping-Prozess und dem aktuellen Status von Envoy bereit. Alle Gastattribute werden im Namespace gce-service-proxy bereitgestellt:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Wenn Probleme auftreten, empfehlen wir, den Wert der Gastattribute bootstrap-status und bootstrap-last-failure zu prüfen. Alle bootstrap-status-Werte außer FINISHED zeigen an, dass die Envoy-Umgebung noch nicht konfiguriert wurde. Der Wert von bookstrap-last-failure kann auf die Ursache des Problems hinweisen.

Der Cloud Service Mesh-Dienst kann nicht über eine VM erreicht werden, die mit einer für einen Dienst-Proxy aktivierten Instanzvorlage erstellt wurde

So beheben Sie dieses Problem:

Die Installation der Dienstproxykomponenten auf der VM ist möglicherweise noch nicht abgeschlossen oder fehlgeschlagen. Mit dem folgenden Befehl können Sie feststellen, ob alle Komponenten ordnungsgemäß installiert wurden:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
Das Gastattribut bootstrap-status hat einen der folgenden Werte:
- [none] zeigt an, dass die Installation noch nicht gestartet wurde. Die VM wird möglicherweise noch gebootet. Prüfen Sie den Status in einigen Minuten noch einmal.
- IN PROGRESS gibt an, dass die Installation und Konfiguration der Dienstproxykomponenten noch nicht vollständig ist. Prüfen Sie den Status wiederholt auf Aktualisierungen.
- FAILED gibt an, dass die Installation oder Konfiguration einer Komponente fehlgeschlagen ist. Prüfen Sie die Fehlermeldung durch Abfrage des Attributs gce-service-proxy/bootstrap-last-failure1.
- FINISHED gibt an, dass die Installations- und Konfigurationsprozesse fehlerfrei abgeschlossen wurden. Folgen Sie der nachstehenden Anleitung, um zu prüfen, ob das Abfangen von Traffic und der Envoy-Proxy richtig konfiguriert sind.
Das Abfangen von Traffic auf der VM ist für Cloud Service Mesh-basierte Dienste nicht richtig konfiguriert. Melden Sie sich bei der VM an und prüfen Sie die iptables-Konfiguration:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Untersuchen Sie die Kette SERVICE_PROXY_SERVICE_CIDRS auf SERVICE_PROXY_REDIRECT-Einträge wie diese:
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
Für jeden Dienst muss in der Spalte destination eine entsprechende IP-Adresse oder ein CIDR-Bereich vorhanden sein. Wenn für die virtuelle IP-Adresse (VIP) kein Eintrag vorhanden ist, liegt ein Problem beim Ausfüllen der Envoy-Proxy-Konfiguration über Cloud Service Mesh vor oder der VM-Agent ist fehlgeschlagen.
Die Envoy-Proxys haben ihre Konfiguration noch nicht von Cloud Service Mesh erhalten. Melden Sie sich bei der VM an, um die Envoy-Proxy-Konfiguration zu prüfen:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Prüfen Sie die von Cloud Service Mesh erhaltene Listener-Konfiguration. Beispiel:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]
```
Die address_prefix ist die virtuelle IP-Adresse (VIP) eines Cloud Service Mesh-Dienstes. Es verweist auf die URL-Zuordnung mit dem Namen td-routing-rule-1. Prüfen Sie, ob der Dienst, zu dem Sie eine Verbindung herstellen möchten, bereits in der Listener-Konfiguration enthalten ist.
Der VM-Agent wird nicht ausgeführt. Der VM-Agent konfiguriert automatisch das Abfangen von Traffic, wenn neue Cloud Service Mesh-Dienste erstellt werden. Wenn der Agent nicht ausgeführt wird, wird der gesamte Traffic zu neuen Diensten direkt an VIPs weitergeleitet. Dadurch wird der Envoy-Proxy umgangen und das Zeitlimit überschritten.
1. Prüfen Sie mit dem folgenden Befehl den Status des VM-Agents:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Prüfen Sie die Attribute des VM-Agents. Der Wert des Attributs agent-heartbeat gibt an, wann der Agent zuletzt eine Aktion oder Prüfung ausgeführt hat. Wenn der Wert älter als fünf Minuten ist, ist der Agent blockiert. Erstellen Sie die VM dann mit dem folgenden Befehl neu:
```
gcloud compute instance-groups managed recreate-instance
```
3. Das Attribut agent-last-failure zeigt den letzten Fehler im Agent an. Dies kann ein vorübergehendes Problem sein, das durch die nächste Prüfung des Agents behoben wird, z. B. wenn der Fehler Cannot reach the Cloud Service Mesh API server lautet, oder es handelt sich um einen permanenten Fehler. Warten Sie einige Minuten und prüfen Sie den Fehler noch einmal.

Das Abfangen eingehenden Traffics ist für den Arbeitslastport konfiguriert. Sie können jedoch keine Verbindung zum Port von außerhalb der VM herstellen.

So beheben Sie dieses Problem:

Die Installation der Dienstproxykomponenten auf der VM ist möglicherweise noch nicht abgeschlossen oder fehlgeschlagen. Mit dem folgenden Befehl können Sie feststellen, ob alle Komponenten ordnungsgemäß installiert wurden:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
Das Gastattribut bootstrap-status hat einen der folgenden Werte:
- [none] zeigt an, dass die Installation noch nicht gestartet wurde. Die VM wird möglicherweise noch gebootet. Prüfen Sie den Status in einigen Minuten noch einmal.
- IN PROGRESS gibt an, dass die Installation und Konfiguration der Dienstproxykomponenten noch nicht vollständig ist. Prüfen Sie den Status wiederholt auf Aktualisierungen.
- FAILED gibt an, dass die Installation oder Konfiguration einer Komponente fehlgeschlagen ist. Prüfen Sie die Fehlermeldung durch Abfrage des Attributs gce-service-proxy/bootstrap-last-failure1.
- FINISHED gibt an, dass die Installations- und Konfigurationsprozesse fehlerfrei abgeschlossen wurden. Folgen Sie der nachstehenden Anleitung, um zu prüfen, ob das Abfangen von Traffic und der Envoy-Proxy richtig konfiguriert sind.
Das Abfangen von Traffic auf der VM ist für eingehenden Traffic nicht korrekt konfiguriert. Melden Sie sich bei der VM an und prüfen Sie die iptables-Konfiguration:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Untersuchen Sie die Kette SERVICE_PROXY_INBOUND auf SERVICE_PROXY_IN_REDIRECT-Einträge wie diese:
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Für jeden in service-proxy:serving-ports definierten Port muss in der Spalte destination ein entsprechender Port vorhanden sein. Ist kein Eintrag für den Port vorhanden, wird der gesamte eingehende Traffic direkt an diesen Port weitergeleitet. Dadurch wird der Envoy-Proxy umgangen.

Achten Sie darauf, dass es keine anderen Regeln gibt, die Traffic an diesen Port oder alle Ports mit Ausnahme eines bestimmten Ports leiten.
Die Envoy-Proxys haben noch keine Konfiguration für den eingehenden Port von Cloud Service Mesh erhalten. Melden Sie sich bei der VM an, um die Envoy-Proxy-Konfiguration zu prüfen:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Suchen Sie nach der von Cloud Service Mesh erhaltenen Listener-Konfiguration für inbound:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]
```
Der route_config_name, beginnend mit inbound, gibt einen speziellen Dienst an, der für das Abfangen von eingehendem Traffic erstellt wurde. Prüfen Sie, ob der Port, zu dem Sie eine Verbindung herstellen möchten, bereits in der Listener-Konfiguration unter destination_port enthalten ist.

Probleme bei der Verwendung serverbezogener Protokolle

Einige Anwendungen wie MySQL verwenden Protokolle, an die der Server das erste Paket sendet. Bei der ersten Verbindung sendet der Server also die ersten Byte. Diese Protokolle und Anwendungen werden von Cloud Service Mesh nicht unterstützt.

Fehlerbehebung für den Zustand Ihres Service Mesh

Dieser Leitfaden enthält Informationen zur Behebung von Konfigurationsproblemen mit dem Cloud Service Mesh.

Cloud Service Mesh-Verhalten, wenn die meisten Endpunkte fehlerhaft sind

Für eine höhere Zuverlässigkeit konfiguriert Cloud Service Mesh, wenn 99% der Endpunkte fehlerhaft sind, die Datenebene so, dass der Systemstatus der Endpunkte ignoriert wird. Stattdessen verteilt die Datenebene den Traffic auf alle Endpunkte, da der Bereitstellungsport möglicherweise noch funktioniert.

Fehlerhafte Back-Ends verursachen eine suboptimale Verteilung des Traffic

Cloud Service Mesh verwendet die Informationen in der Ressource HealthCheck, die an einen Back-End-Dienst angehängt ist, um den Zustand Ihrer Back-Ends zu bewerten. Cloud Service Mesh verwendet diesen Systemstatus, um Traffic an das nächstgelegene fehlerfreie Back-End weiterzuleiten. Wenn einige Ihrer Back-Ends fehlerhaft sind, wird der Traffic möglicherweise weiterhin verarbeitet, allerdings mit suboptimaler Verteilung. Beispielsweise kann Traffic in eine Region fließen, in der noch fehlerfreie Back-Ends vorhanden sind, die jedoch viel weiter vom Client entfernt ist, was die Latenz mit sich bringt. Führen Sie die folgenden Schritte aus, um den Systemstatus Ihrer Back-Ends zu ermitteln und zu überwachen:

Prüfen Sie den Systemstatus Ihres Backend-Dienstes in der Google Cloud Console.
Zu den Cloud Service Mesh-Diensten
Achten Sie darauf, dass für die HealthCheck-Ressource des Logging aktiviert ist.
Wenn die Systemdiagnosen vor Kurzem fehlgeschlagen sind, prüfen Sie in den Cloud-Audit-Logs, ob sich Ihre HealthCheck-Konfiguration in letzter Zeit geändert hat.

Nächste Schritte

Informationen zum Beheben von Konfigurationsproblemen bei der Bereitstellung proxyloser gRPC-Dienste finden Sie unter Fehlerbehebung bei Bereitstellungen, die proxyloses gRPC verwenden.
Weitere Unterstützung bei der Verwendung von Cloud Service Mesh finden Sie unter Support.