Fehlerbehebung bei Envoy-Bereitstellungen

Diese Anleitung enthält Informationen zur Behebung von Konfigurationsproblemen in Traffic Director. Informationen zur Verwendung der Client Status Discovery Service (CSDS) API für die Untersuchung von Problemen mit Traffic Director finden Sie unter Informationen zum Traffic Director-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.

Version mit automatischer Envoy-Bereitstellung ermitteln

So können Sie die Envoy-Version mit automatischer Bereitstellung prüfen:

  • 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 ZONE --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",
...
}

Version mit manueller Envoy-Bereitstellung ermitteln

So können Sie die Envoy-Version durch manuelle Bereitstellung prüfen:

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

In Google Kubernetes Engine (GKE) werden die Envoy-Proxys mit den Anwendungs-Pods ausgeführt. In den Anwendungs-Pod-Logs, die nach dem Container envoy gefiltert sind, werden Fehler angezeigt.

  • Wenn für den Cluster das Logging der Arbeitslasten aktiviert ist, können Sie die Fehler in Cloud Logging sehen. Dies ist ein möglicher Filter:

    resource.type="K8S_CONTAINER"
resource.labels.project_id="PROJECT_NAME"
resource.labels.location="CLUSTER_ZONE"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="WORKLOAD_NAMESPACE"
labels.k8s-pod/app="WORKLOAD_NAME"
resource.labels.container_name="envoy"

  • Wenn das Arbeitslast-Logging auf dem Cluster nicht aktiviert ist, können Sie die Fehler mit einem Befehl wie diesem sehen:

    kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.

  • Mit dem folgenden Filter können Sie auch die Logs für alle Envoy-Cluster abrufen, die in allen Clustern und allen Arbeitslasten ausgeführt werden:

    resource.type="K8S_CONTAINER"
resource.labels.container_name="envoy"

Definieren Sie bei Compute Engine und manueller Bereitstellung das LOG_DIR, bevor Sie das Skript run.sh aus der Einrichtungsanleitung ausführen.

  • Beispiel:

    LOG_DIR='/var/log/envoy/'

  • Standardmäßig werden die Fehler im folgenden Log angezeigt:

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

Wenn der Nutzer keine zusätzliche Konfiguration für den Export in Logging vorgenommen hat, sind die Fehler nur dann sichtbar, wenn Sie eine SSH-Verbindung zur Instanz herstellen und diese Datei abrufen.

Wenn Sie die automatische Envoy-Bereitstellung verwenden, können Sie eine SSH-Verbindung zur Instanz herstellen, um die Logdatei abzurufen. Der Pfad entspricht wahrscheinlich dem zuvor genannten Pfad.

Proxys stellen keine Verbindung zu Traffic Director her

Wenn Ihre Proxys keine Verbindung zu Traffic Director herstellen, 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 der Traffic Director 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, achten Sie darauf, dass es sich bei der Envoy-Version um 1.9.1 oder höher handelt.

Der mit Traffic Director konfigurierte Dienst ist nicht erreichbar

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

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

  1. Prüfen Sie in der Befehlszeile, ob der Envoy-Prozess ausgeführt wird:

    ps aux | grep envoy

  2. Prüfen Sie die Laufzeitkonfiguration von Envoy, um zu bestätigen, dass Traffic Director dynamische Ressourcen konfiguriert hat. Führen Sie den folgenden Befehl aus, um die Konfiguration aufzurufen:

    curl http://localhost:15000/config_dump

  3. 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 mit TRAFFICDIRECTOR_ACCESS_LOG_PATH ein Envoy-Zugriffslog konfiguriert haben, wie unter Envoy-Bootstrap-Attribute für Traffic Director konfigurieren beschrieben, achten Sie darauf, dass der Systemnutzer, der den Envoy-Proxy ausführt, Schreibzugriff auf den angegebenen Speicherort des Zugriffslogs hat.

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.

Anwendungen können keine Verbindung zu Diensten herstellen, die nicht in Traffic Director konfiguriert sind

Achten Sie darauf, dass Sie das Abfangen von Traffic nur für die IP-Adressen von Diensten eingerichtet haben, die in Traffic Director konfiguriert sind. Wenn der gesamte Traffic abgefangen wird, werden Verbindungen zu den Diensten, die nicht in Traffic Director konfiguriert sind, vom Sidecar-Proxy automatisch verworfen.

Der Traffic befindet sich in einem Knoten oder ein Knoten stürzt ab

Wenn netfilter (iptables) so eingerichtet ist, dass der gesamte Traffic abgefangen wird, muss der Nutzer (UID), der zum Ausführen des Sidecar-Proxys verwendet wird, vom Abfangen des Traffics ausgeschlossen werden. Andernfalls wird der vom Sidecar-Proxy gesendete Traffic auf unbestimmte Zeit an den Proxy zurückgesendet. Dies kann zu einem Absturz des Sidecar-Proxy-Prozesses führen. In der Referenzkonfiguration fangen die netfilter-Regeln keinen Traffic vom Proxy-Nutzer ab.

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

Wenn Probleme mit der Traffic Director-Konfiguration auftreten, werden in den Envoy-Logs möglicherweise folgende Fehlermeldungen angezeigt:

  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Traffic Director configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Traffic Director 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.
  • Traffic Director configuration was not found.

Die letzte Fehlermeldung (Traffic Director configuration was not found) zeigt im Allgemeinen an, dass Envoy eine Konfiguration von Traffic Director anfordert, aber keine passende Konfiguration gefunden wird. Wenn Envoy eine Verbindung zu Traffic Director herstellt, wird der Name eines VPC-Netzwerks angezeigt (z. B. my-network). Traffic Director sucht dann nach Weiterleitungsregeln, die das Load-Balancing-Schema INTERNAL_SELF_MANAGED haben und auf denselben VPC-Netzwerknamen verweisen.

So beheben Sie diesen Fehler:

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

  2. Wenn Sie Traffic Director mit automatisierten Envoy-Bereitstellungen in Compute Engine verwenden, achten Sie darauf, dass der für das Flag --service-proxy:network angegebene Wert mit dem VPC-Netzwerknamen der Weiterleitungsregel übereinstimmt.

  3. Wenn Sie Traffic Director 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.

  4. Wenn Sie in GKE bereitstellen und den Auto-Injector verwenden, achten Sie darauf, dass die Projektnummer und der VPC-Netzwerkname richtig konfiguriert sind. Folgen Sie dazu der Anleitung unter Traffic Director-Einrichtung für GKE-Pods mit automatischer Envoy-Injection.

Fehlerbehebung bei automatischen Bereitstellungen für Compute Engine

In diesem Abschnitt finden Sie Anleitungen zur Fehlerbehebung bei automatischen 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.

Der VM-Agent erstellt Logs zum Envoy-Prozessstatus, zu neu erkannten Traffic Director-Diensten und anderen Informationen, die bei der Untersuchung von Problemen mit VMs nützlich sein könnten.

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 Traffic Director-Dienst kann nicht über eine VM erreicht werden, die aus einer Instanzvorlage mit aktiviertem Dienst-Proxy erstellt wurde

So beheben Sie dieses Problem:

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

  2. Das Abfangen von Traffic auf der VM ist für Traffic Director-basierte Dienste 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_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 kein Eintrag für die virtuelle IP-Adresse (VIP) vorhanden ist, gibt es ein Problem beim Einfügen der Envoy-Proxy-Konfiguration aus Traffic Director oder der VM-Agent ist fehlgeschlagen.

  3. Die Envoy-Proxys haben noch keine Konfiguration von Traffic Director 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 Listener-Konfiguration, die von Traffic Director empfangen wurde. 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"
  ...
]

    Das address_prefix ist die virtuelle IP-Adresse (VIP) eines Traffic Director-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.

  4. Der VM-Agent wird nicht ausgeführt. Der VM-Agent konfiguriert automatisch das Abfangen von Traffic, wenn neue Traffic Director-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 Traffic Director 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:

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

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

  3. Die Envoy-Proxys wurden von Traffic Director noch nicht für den eingehenden Port konfiguriert. 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 Listener-Konfiguration für inbound, die Traffic Director empfangen hat:

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

Fehlerbehebung bei automatischen Bereitstellungen für GKE-Pods

In diesem Abschnitt finden Sie Anleitungen zur Fehlerbehebung bei automatischen Envoy-Bereitstellungen für GKE-Pods.

Pods werden nach der Aktivierung der automatischen Envoy-Einfügung nicht gestartet

Unter bestimmten Umständen können Anwendungs-Pods nicht ordnungsgemäß gestartet werden. Dies kann auftreten, wenn Sie einen privaten GKE-Cluster mit restriktiven Firewallregeln verwenden.

Wenn Sie Traffic Director mit einem privaten GKE-Cluster verwenden möchten, müssen Sie eine zusätzliche Firewallregel für den Sidecar-Injektor-Webhook erstellen. Informationen zum Erstellen einer Firewallregel, mit der die GKE-Steuerungsebene die Pods am TCP-Port 9443 erreichen kann, finden Sie unter Firewallregeln für bestimmte Anwendungsfälle hinzufügen.

Dieses Problem kann beim Erstellen eines eigenständigen Pods oder bei dem Versuch einer Bereitstellung auftreten, einen Pod zu erstellen.

Beim Erstellen eines eigenständigen Pods, z. B. mit kubectl apply oder kubectl run, gibt die kubectl-Befehlszeile möglicherweise eine Fehlermeldung wie die folgende zurück:

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Beim Erstellen von Pods aus einer Bereitstellung können folgende Symptome auftreten:

  • kubectl get pods zeigt keine mit der Bereitstellung verknüpften Pods an.

  • kubectl get events --all-namespaces zeigt eine Fehlermeldung wie folgende an:

    Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Wenn Sie den Einrichtungsleitfaden befolgen, tritt möglicherweise dieses Problem während des Schritts Beispielclient bereitstellen und Einfügung prüfen auf. Führen Sie nach der Ausführung von kubectl create -f demo/client_sample.yaml den Befehl kubectl get deploy busybox aus, um 0/1-READY-Pods anzuzeigen. Sie können den Fehler auch finden, indem Sie das mit der Bereitstellung verknüpfte replicaset durch Ausführen des Befehls kubectl describe rs -l run=client beschreiben.

Verbindung wurde nach Verifizierung der Konfiguration abgelehnt

Wenn Sie Traffic Director mit automatischer Envoy-Injection einrichten, erhalten Sie möglicherweise einen Fehler in Bezug auf einen abgelehnten Verbindungsversuch, wenn Sie versuchen, die Konfiguration zu prüfen. Mögliche Ursachen:

  • Der Wert von discoveryAddress in der Datei specs/01-configmap.yaml ist nicht korrekt. Der Wert sollte trafficdirector.googleapis.com:443 sein.
  • Der Wert für das VPC-Netzwerk in der Datei specs/01-configmap.yaml ist nicht korrekt.
  • Der Wert für das Traffic Director-Projekt in der Datei specs/01-configmap.yaml ist nicht korrekt.
  • Der Wert von discoveryAddress ist im Pod falsch.
  • Der Istio-Sidecar-Injector wird anstelle des Traffic Director-Sidecar-Injectors ausgeführt.

Ein Beispiel der Datei specs/01-configmap.yaml finden Sie unter Sidecar-Injector konfigurieren. Wenn die Datei specs/01-configmap.yaml nicht die richtigen Werte enthält, kann Envoy die Korrekturkonfiguration nicht von Traffic Director abrufen. Prüfen Sie zur Behebung des Problems die Datei specs/01-configmap.yaml und prüfen Sie, ob die Werte korrekt sind. Erstellen Sie dann den automatischen Injector neu.

Prüfen Sie den Wert von discoveryAddress in der Datei specs/01-configmap.yaml und im Pod. Im Pod legt der Sidecar-Injector den Wert fest. Führen Sie den folgenden Befehl aus, um den Wert von discoveryAddress im Pod zu prüfen:

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

Die Ausgabe sollte in etwa so aussehen:

"discoveryAddress":"trafficdirector.googleapis.com:443"

Verbindung mit manueller Envoy-Einfügung und GKE-Pods abgelehnt

Wenn Sie eine Nachricht über eine abgelehnte Verbindung erhalten, sehen Sie in den busybox-Logs nach, ob die Traffic Director API aktiviert ist oder die Berechtigungen für die Envoy-Logs nicht korrekt sind.

Verbindungszeitlimit mit manueller Envoy-Einfügung und GKE-Pods

Wenn Sie über eine Überschreitung der Verbindungszeit benachrichtigt werden, ist das Problem wahrscheinlich eine falsche Konfiguration der URL-Zuordnung, eine Weiterleitungsregel oder der Backend-Dienst Ihrer Bereitstellung. Prüfen Sie, ob diese Ressourcen ordnungsgemäß konfiguriert wurden.

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 Traffic Director nicht unterstützt.

Fehlerbehebung für den Zustand Ihres Service Mesh

Diese Anleitung enthält Informationen zur Behebung von Konfigurationsproblemen in Traffic Director.

Traffic Director-Verhalten, wenn die meisten Endpunkte fehlerhaft sind

Wenn 99 % der Endpunkte fehlerhaft sind, konfiguriert Traffic Director für eine bessere Zuverlässigkeit die Datenebene so, dass der Systemstatus der Endpunkte ignoriert wird. Stattdessen verteilt die Datenebene den Traffic unter allen Endpunkten, da der Bereitstellungsport möglicherweise noch funktioniert.

Fehlerhafte Back-Ends verursachen eine suboptimale Verteilung des Traffic

Traffic Director verwendet die Informationen in der HealthCheck-Ressource, die an einen Backend-Dienst angehängt sind, um den Status Ihrer Backends zu bewerten. Traffic Director verwendet diesen Status, um den Traffic an das nächstgelegene fehlerfreie Backend weiterzuleiten. Wenn einige Ihrer Back-Ends fehlerhaft sind, wird der Traffic möglicherweise mit suboptimaler Verteilung weiterhin verarbeitet. Beispiel: Traffic kann in eine Region fließen, in der fehlerfreie Back-Ends vorhanden sind, die aber sehr weit vom Client entfernt sind, was Latenz verursacht. Führen Sie folgende 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 Traffic Director-Diensten
  • Achten Sie darauf, dass für die HealthCheck-Ressource des Logging aktiviert ist.
  • Wenn es zu fehlgeschlagenen Systemdiagnosen kommt, prüfen Sie anhand von Cloud-Audit-Logs, ob Ihre HealthCheck-Konfiguration kürzlich geändert wurde.

Back-Ends lehnen Traffic unerwartet ab

Wenn Sie die Sicherheitseinstellungen des Traffic Director-Dienstes konfiguriert haben, können Sie mit der EndpointPolicy-Ressource Sicherheitsrichtlinien auf die Back-Ends anwenden. Eine falsche EndpointPolicy-Konfiguration kann dazu führen, dass Ihr Backend Traffic ablehnt. Verwenden Sie folgende Logs, um dieses Szenario zu beheben:

  • Prüfen Sie auf von Traffic Director gemeldete Endpunktrichtlinienkonflikte.
  • Prüfen Sie über die Cloud-Audit-Logs, ob die Nutzerkonfiguration (insbesondere EndpointPolicy, ServerTlsPolicy oder AuthorizationPolicy) kürzlich geändert wurde.

Nächste Schritte