Fehlerbehebung bei Traffic Director-Bereitstellungen

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

Logspeicherorte in Envoy

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

In Google Kubernetes Engine werden die Envoy-Proxys mit den Anwendungs-Pods ausgeführt. Daher können Sie alle Fehler in den Logs der Anwendungs-Pods anzeigen lassen, wenn Sie nach dem Container istio-proxy filtern. Wenn für den Cluster das Logging der Arbeitslasten aktiviert ist, werden diese in Cloud Logging angezeigt.

Hier 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="istio-proxy"

Ist das Logging der Arbeitslasten auf dem Cluster nicht aktiviert, 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 istio-proxy --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="istio-proxy"

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 in /var/log/envoy/envoy.err.log angezeigt.

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 Dateipfad ist wahrscheinlich derselbe wie oben.

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 Traffic Director API für das Projekt aktiviert ist. Suchen Sie unter „APIs und Dienste“ für Ihr Projekt nach Fehlern der Traffic Director API.
    Zur Seite „API-Bibliothek“
  • Prüfen Sie, ob der API-Zugriffsbereich der VM so eingestellt ist, dass uneingeschränkter Zugriff auf die GCP APIs möglich ist. Geben Sie dazu bei der VM-Erstellung „--scopes=https://www.googleapis.com/auth/cloud-platform“ an.
  • 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 aus auf „trafficdirector.googleapis.com:443“ zugreifen können. Wenn es Probleme mit diesem Zugriff gibt, könnte dies daran liegen, dass die Firewall den Zugriff auf trafficdirector.googleapis.com über TCP-Port 443 verhindert oder Probleme mit der DNS-Auflösung für den Hostnamen „trafficdirector.googleapis.com“ auftreten.
  • 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 dynamische Ressourcen von Traffic Director konfiguriert wurden. Sie können die Konfiguration mit folgendem Befehl aufrufen:

    curl http://localhost:15000/config_dump
    
  3. Achten Sie darauf, dass das Abfangen von Traffic-für den Sidecare-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

Das folgende Beispiel zeigt eine Ausgabe, die Sie erhalten, wenn iptables die VIP 10.0.0.1/32 abfängt und an einen Envoy-Proxy weiterleitet, der auf Port 15001 als UID 1006 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 GCP 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 mit gcloud-Befehlen erstellt haben, wird dieses Problem nicht erwartet.

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

Wenn Sie das Envoy-Zugriffslog mit TRAFFICDIRECTOR_ACCESS_LOG_PATH konfiguriert haben, wie unter Zusätzliche Attribute für Sidecar-Proxys 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_LISTENER:
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 einer Knotenschleife 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. Der Sidecar-Proxy-Prozess kann dadurch abstürzen. In der Referenzkonfiguration fangen die Netfilter-Regeln keinen Traffic vom Proxy-Nutzer ab.

Traffic Director-Verhalten, wenn die meisten Endpunkte fehlerhaft sind

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

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.

Diese Fehlermeldung 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 ein VPC-Netzwerkname (z. B. my-network) angezeigt. Traffic Director sucht dann nach Weiterleitungsregeln, die (1) das Load-Balancing-Schema INTERNAL_SELF_MANAGED haben und (2) auf denselben Netzwerknamen verweisen (z. B. my-network).

  1. Achten Sie darauf, dass in Ihrem Netzwerk eine Weiterleitungsregel mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED vorhanden ist. Notieren Sie das VPC-Netzwerk dieser 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 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:

    1. Prüfen Sie, ob der Wert der Variable TRAFFICDIRECTOR_NETWORK_NAME mit dem Netzwerknamen der Weiterleitungsregel übereinstimmt.
    2. Achten Sie darauf, dass in der Bootstrap-Datei von Envoy 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 Netzwerkname richtig konfiguriert sind. Folgen Sie dazu der Anleitung unter Traffic Director-Einrichtung für Google Kubernetes Engine-Pods mit automatischer Envoy-Injection.

Fehlerbehebung bei automatisierten Envoy-Bereitstellungen

In diesem Abschnitt finden Sie Anleitungen zur Fehlerbehebung bei automatisierten Envoy-Bereitstellungen.

Kommunikationskanäle zur Fehlerbehebung

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.

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 in der Regel eine Ausgabe an die seriellen Ports. Diese Ausgabe ist nützlich, um Systemabstürze, fehlgeschlagene Boot-Vorgänge sowie Probleme beim Starten und Herunterfahren zu beheben.

Bootstrapping-Agents von Compute Engine protokollieren alle ausgeführten Vorgänge im seriellen Port 1 zusammen mit Systemereignissen, angefangen von der grundlegenden Paketinstallation über den Datenabruf vom Metadatenserver einer Instanz bis hin zur 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 eventuell 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

Folgen Sie dieser Anleitung, um das Problem zu beheben.

  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-failure1.
    • FINISHED gibt an, dass der Installations- und Konfigurationsvorgang fehlerfrei abgeschlossen wurde. 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. Ist kein Eintrag für die VIP vorhanden, besteht 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"
      ...
    ]
    

    address_prefix ist die VIP eines Traffic Director-Dienstes. Sie 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.

    Führen Sie folgenden Befehl aus, um den Status des VM-Agents zu prüfen:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ --zone=ZONE
    
  5. Sie können die Attribute des VM-Agents untersuchen. 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 in diesem Fall die VM mit dem Befehl gcloud compute instance-groups managed recreate-instance neu.

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

Folgen Sie dieser Anleitung, um das Problem zu beheben.

  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-failure1.
    • FINISHED gibt an, dass der Installations- und Konfigurationsvorgang fehlerfrei abgeschlossen wurde. 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 eingehenden Traffic, 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.

Nächste Schritte