Fehlerbehebung bei proxylosen gRPC-Bereitstellungen

Dieses Dokument enthält Informationen zur Behebung von Konfigurationsproblemen, wenn Sie proxylose gRPC-Dienste mit Traffic Director bereitstellen. 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.

RPC-Fehler in einer gRPC-Anwendung beheben

Es gibt zwei gängige Methoden, um RPC-Fehler (Remote Procedure Calls, Remote-Prozeduraufrufe) in einer gRPC-Anwendung zu beheben:

  1. Prüfen Sie den Status, der zurückgegeben wird, wenn ein RPC fehlschlägt. In der Regel enthält der Status genügend Informationen, damit Sie die Ursache eines RPC-Fehlers besser verstehen.

  2. Aktivieren Sie das Logging in der gRPC-Laufzeit. Manchmal müssen Sie die gRPC-Laufzeitlogs prüfen, wenn die Ursache eines Fehlers gesucht wird, der nicht in einem RPC-Rückgabestatus aufgeführt ist. Wenn beispielsweise ein RPC mit dem Status fehlschlägt, dass die Frist überschritten wurde, können Sie in den Logs den Fehler ermitteln, der zur Fristüberschreitung geführt hat.

    Die unterschiedlichen Sprachimplementierungen von gRPC bieten verschiedene Möglichkeiten, um das Logging in der gRPC-Laufzeit zu aktivieren.

    • gRPC in Java: gRPC nutzt java.util.logging für das Logging. Legen Sie für io.grpc.level den Wert FINE fest, um ein ausreichend ausführliches Logging in der gRPC-Laufzeit zu ermöglichen. Eine typische Methode zur Aktivierung des Loggings in Java besteht darin, die Logging-Konfiguration aus einer Datei zu laden und den Speicherort der Datei mithilfe eines Befehlszeilen-Flags an die JVM zu übergeben. Beispiel:

      # Create a file called logging.properties with the following contents:
handlers=java.util.logging.ConsoleHandler
io.grpc.level=FINE
io.grpc.xds.level=FINEST
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

# Pass the location of the file to JVM by using this command-line flag:
-Djava.util.logging.config.file=logging.properties

      Um das Logging speziell für xDS-Module zu aktivieren, legen Sie für io.grpc.xds.level den Wert FINE fest. Für ein detaillierteres Logging können Sie als Ebene FINER oder FINEST festlegen.

    • gRPC in Go: Aktivieren Sie das Logging durch Festlegung von Umgebungsvariablen.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • gRPC in C++: Wie Sie Logging mit gRPC in C++ aktivieren, erfahren Sie unter gRPC Fehler beheben. Wenn Sie das Logging speziell für xDS-Module aktivieren möchten, aktivieren Sie die folgenden Tracer. Verwenden Sie dazu die Umgebungsvariable GRPC_TRACE für xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb, und lrs_lb.

    • gRPC in Node.js: Informationen zum Aktivieren des Loggings mit gRPC in Node.js finden Sie unter Fehlerbehebung für gRPC-JS. Wenn Sie das Logging speziell für xDS-Module aktivieren möchten, aktivieren Sie die folgenden Tracer. Verwenden Sie dazu die Umgebungsvariable GRPC_TRACE für xds_client, xds_resolver, cds_balancer, eds_balancer, priority und weighted_target.

Je nach dem Fehler, der im RPC-Status oder in den Laufzeitlogs angezeigt wird, kann das Problem in eine der folgenden Kategorien fallen.

Verbindung zu Traffic Director ist nicht möglich

Um Verbindungsprobleme zu beheben, führen Sie Folgendes aus:

  • Prüfen Sie, ob der Wert von „server_uri“ in der Bootstrap-Datei trafficdirector.googleapis.com:443 lautet.
  • Achten Sie darauf, dass die Umgebungsvariable GRPC_XDS_BOOTSTRAP definiert ist und auf die Bootstrap-Datei verweist.
  • Verwenden Sie unbedingt das Schema xds im URI, wenn Sie einen gRPC-Kanal erstellen.
  • Achten Sie darauf, dass Sie die erforderlichen IAM-Berechtigungen zum Erstellen von Compute-Instanzen und zum Ändern eines Netzwerks in einem Projekt haben.
  • Prüfen Sie, ob die Traffic Director API für das Projekt aktiviert ist. Prüfen Sie unter Google Cloud Console APIs und -Dienste für Ihr Projekt auf Fehler für die Traffic Director API.
  • Prüfen Sie, ob das Dienstkonto die richtigen Berechtigungen hat. Die in der VM oder im Pod ausgeführten gRPC-Anwendungen verwenden das Dienstkonto des Compute Engine-VM-Hosts oder der GKE-Knoteninstanz (Google Kubernetes Engine).

  • Prüfen Sie, ob der API-Zugriffsbereich der Compute Engine-VMs oder GKE-Cluster vollständigen Zugriff auf die Compute Engine APIs gewährt. Geben Sie dazu beim Erstellen der VMs oder des Clusters Folgendes an:

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • Prüfen Sie, ob Sie von der VM auf trafficdirector.googleapis.com:443 zugreifen können. Wenn Zugriffsprobleme auftreten, kann dies daran liegen, dass eine Firewall den Zugriff auf trafficdirector.googleapis.com über TCP-Port 443 verhindert oder dass es Probleme mit der DNS-Auflösung für den Hostnamen trafficdirector.googleapis.com gibt.

Der im URI angegebene Hostname kann nicht aufgelöst werden

In Ihren Logs wird möglicherweise eine Fehlermeldung wie die folgende angezeigt:

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

Um Probleme mit der Auflösung von Hostnamen zu beheben, führen Sie Folgendes aus:

  • Prüfen Sie, ob Sie eine unterstützte gRPC-Version und Sprache verwenden.
  • Achten Sie darauf, dass der im URI verwendete Port zum Erstellen eines gRPC-Kanals mit dem Portwert in der Weiterleitungsregel übereinstimmt, die Sie in Ihrer Konfiguration verwenden. Wenn im URI kein Port angegeben ist, wird der Wert 80 zum Abgleichen einer Weiterleitungsregel verwendet.
  • Achten Sie darauf, dass der Hostname und der Port, die zum Erstellen eines gRPC-Kanals in der URI verwendet werden, genau mit einer Hostregel in der URL-Zuordnung Ihrer Konfiguration übereinstimmen.
  • Diese Hostregel darf nur in einer URL-Zuordnung konfiguriert sein.
  • Achten Sie darauf, dass keine Platzhalter verwendet werden. Hostregeln mit dem Platzhalterzeichen * werden ignoriert.

RPC schlägt fehl, weil der Dienst nicht verfügbar ist

So können Sie RPC-Fehler beheben, wenn ein Dienst nicht verfügbar ist:

  • Prüfen Sie den Gesamtstatus von Traffic Director und den Status Ihrer Backend-Dienste in der Google Cloud Console:

    • Prüfen Sie in der Spalte Verknüpfte Routingregelzuordnungen, ob die richtigen URL-Zuordnungen auf die Backend-Dienste verweisen. Klicken Sie auf die Spalte, um zu prüfen, ob die in den Hostabgleichsregeln angegebenen Backend-Dienste korrekt sind.
    • Prüfen Sie in der Spalte Backends, ob die mit Ihren Backend-Diensten verknüpften Backends fehlerfrei sind.
    • Wenn die Back-Ends fehlerhaft sind, klicken Sie auf den entsprechenden Back-End-Dienst und prüfen Sie, ob die richtige Systemdiagnose konfiguriert ist. Systemdiagnosen schlagen häufig durch falsche oder fehlende Firewallregeln oder aufgrund einer Nichtübereinstimmung zwischen Tags fehl, die in der VM und in den Firewallregeln angegeben sind. Weitere Informationen finden Sie unter Systemdiagnosen erstellen.

  • Damit gRPC-Systemdiagnosen richtig funktionieren, müssen die gRPC-Back-Ends das gRPC-Systemdiagnoseprotokoll implementieren. Ist dieses Protokoll nicht implementiert, verwenden Sie stattdessen eine TCP-Systemdiagnose. Verwenden Sie eine gRPC-, HTTPS- oder HTTP/2-Systemdiagnose nicht mit gRPC-Diensten.

  • Achten Sie bei der Verwendung von Instanzgruppen darauf, dass der in der Instanzgruppe angegebene benannte Port mit dem in der Systemdiagnose verwendeten Port übereinstimmt. Bei der Verwendung von NEGs (Netzwerk-Endpunktgruppen) müssen Sie auch darauf achten, dass die GKE-Dienstspezifikation die richtige NEG-Annotation enthält und die Systemdiagnose für die Nutzung des NEG-Bereitstellungsports konfiguriert ist.

  • Prüfen Sie, ob das Endpunktprotokoll als GRPC konfiguriert ist.

RPC schlägt fehl, da die Load-Balancing-Richtlinie nicht unterstützt wird.

Möglicherweise wird in Ihren Logs eine Fehlermeldung wie diese angezeigt:

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response

error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."

WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

Dies liegt daran, dass RING_HASH von der jeweiligen Sprache und Version des verwendeten Clients nicht unterstützt wird. Um das Problem zu beheben, aktualisieren Sie die Konfiguration des Backend-Dienstes, um nur unterstützte Load-Balancing-Richtlinien zu verwenden, oder aktualisieren Sie den Client auf eine unterstützte Version. Informationen zu unterstützten Clientversionen finden Sie unter xDS-Features in gRPC.

Die Sicherheitskonfiguration wurde nicht wie erwartet generiert

Wenn Sie die Dienstsicherheit konfigurieren und die Sicherheitskonfiguration nicht wie erwartet generiert wird, prüfen Sie die Endpunktrichtlinien in Ihrer Bereitstellung.

Traffic Director unterstützt keine Szenarien, bei denen zwei oder mehr Endpunktrichtlinienressourcen vorhanden sind, die mit einem Endpunkt übereinstimmen, z. B. zwei Richtlinien mit den gleichen Labels und Ports oder zwei oder mehr Richtlinien mit unterschiedlichen Labels, die mit den Labels eines Endpunkts übereinstimmen. Weitere Informationen zum Abgleichen von Endpunktrichtlinien mit den Labels eines Endpunkts finden Sie unter APIs für EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. In solchen Situationen generiert Traffic Director keine Sicherheitskonfiguration über die in Konflikt stehenden Richtlinien.

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