Einschränkungen für proxyloses gRPC
In diesem Dokument werden Einschränkungen für Cloud Service Mesh mit proxylosen gRPC-Anwendungen beschrieben. Informationen zu Limits finden Sie unter Kontingente und Limits.
Die Einschränkungen bei Weiterleitungsregeln, URL-Zuordnungen und Zielproxys gelten nur für Cloud Service Mesh mit den Google Cloud Load Balancing APIs.
Allgemeine Beschränkungen
Zu den Einschränkungen von Cloud Service Mesh mit proxylosen gRPC-Anwendungen gehören:
Sie können in der Google Cloud Console mit dem gRPC-Protokoll keine Backend-Dienste und Routingregelzuordnungen konfigurieren. Für diese Ressourcen ist die Google Cloud Console schreibgeschützt.
Proxyloses gRPC unterstützt die Endpunkterkennung, Routing, Load-Balancing, Lastberichte und viele erweiterte Features zur Trafficverwaltung.
Die erforderliche gRPC-Version zur Unterstützung einiger Features der erweiterten Trafficverwaltung finden Sie unter Unterstützte gRPC-Versionen und -Sprachen.
Verwenden Sie für Ihre gRPC-Anwendungen, die nicht unterstützte Features zur erweiterten Trafficverwaltung benötigen, den DNS-Namens-Resolver anstelle des xDS-Resolvers und stellen Sie die Anwendungen mit Sidecar-Proxys bereit, die von Cloud Service Mesh unterstützt werden. Setzen Sie in Ihrem gRPC-Zielproxy das Feld
validateForProxyless
aufFALSE
, damit Sie Features konfigurieren können, die noch nicht von gRPC unterstützt, aber in Cloud Service Mesh verfügbar sind, indem Sie Sidecar-Proxys verwenden.
Proxyloses gRPC unterstützt nur Richtlinien für das Load-Balancing von Round Robin und Ring-Hash. Andere Load-Balancing-Algorithmen werden nicht unterstützt.
- Cloud Service Mesh stellt dem gRPC-Client eine priorisierte gewichtete Liste von Orten – einer Instanzgruppe oder einer Netzwerk-Endpunktgruppe (NEG) – zur Verfügung. Cloud Service Mesh berechnet diese Liste basierend auf der nächstgelegenen verfügbaren Zone, ihrer Kapazität und dem Balancing-Modus des Back-End-Dienstes.
- Für eine bestimmte Anfrage wählt der gRPC-Client anhand von Priorität und Gewichtung eine oder mehrere Lokalitäten aus und führt ein Round-Robin- oder Ring-Hash-basiertes Load-Balancing für die Back-Ends innerhalb dieser Lokalitäten durch.
Das Failover von einer Zone (Ort) zu einer anderen beginnt, wenn die aktuelle Zonenkapazität unter 50 % fällt. Sie können diesen Schwellenwert nicht konfigurieren.
In einigen Fällen können die Konfigurationsbefehle, die sich auf einen gRPC-Zielproxy und eine Weiterleitungsregel beziehen, die auf einen gRPC-Zielproxy verweist, bis zu eine Minute dauern.
Hybridkonnektivitäts-NEGs (
NON_GCP_PRIVATE_IP_PORT
-NEGs) werden mit proxylosen gRPC-Clients nicht unterstützt.
Einschränkungen für URL-Zuordnungen
Die folgenden URL-Zuordnungsfeatures für Trafficverwaltung werden bei proxylosen gRPC-Diensten unterstützt.
Im pathMatcher
von hostRules
unterstützte Features:
pathMatcher
name
description
defaultService
defaultRouteAction
weightedBackendServices
backendService
weight
retryPolicy
retryConditions
numRetries
faultInjectionPolicy
maxStreamDuration
pathRules
service
routeAction
weightedBackendServices
backendService
weight
retryPolicy
retryConditions
numRetries
faultInjectionPolicy
maxStreamDuration
paths
routeRules
priority
description
matchRules
prefixMatch
fullPathMatch
headerMatches
metadataFilters
service
routeAction
weightedBackendServices
backendService
weight
retryPolicy
retryConditions
numRetries
faultInjectionPolicy
maxStreamDuration
Die folgenden URL-Zuordnungslimits gelten bei Verwendung von proxylosen gRPC-Diensten:
Platzhalterzeichen in Hostregeln und Standardregeln einer URL-Zuordnung, einschließlich der implizit erstellten
*
-Hostregel einer URL-Zuordnung, werden nicht unterstützt. Solche Einträge werden übersprungen, wenn der Hostabgleich abgeschlossen ist.Folgende Features werden nicht unterstützt:
queryParameterMatches
inrouteRules
- Routingaktionen
headerAction
,urlRewrite
,requestMirrorPolicy
,corsPolicy
undurlRedirect
. - Routingaktion
timeout
;maxStreamDuration
anstelle vontimeout
verwenden perTryTimeout
inretryPolicy
retryConditions
inretryPolicy
mit Ausnahme einer oder mehrerer Bedingungen voncancelled
,deadline-exceeded
,internal
,resource-exhausted
undunavailable
- Die Parameter
defaultService
,defaultRouteAction
,defaultUrlRedirect
undheaderAction
der URL-Zuordnung werden von keinen proxylosen gRPC-Diensten verwendet. Wenn eine übereinstimmende Hostregel nicht gefunden wird, wenn ein proxyloser gRPC-Client nach einem Dienstnamen sucht, gibt Cloud Service Mesh einen Fehler bei der Namenssuche zurück, anstatt den Standarddienst oder die Standardaktion der URL-Zuordnung zu verwenden. - „
headerAction
“ in „weightedBackendServices
“
In Übereinstimmungsregeln für den Header der URL-Zuordnung werden nur nicht binäre benutzerdefinierte Metadaten und der Header
content-type
unterstützt. Die folgenden Header auf Transportebene können in Header-Übereinstimmungsregeln nicht verwendet werden::authority
,:method
,:path
,:scheme
,user-agent
,accept-encoding
,content-encoding
,grpc-accept-encoding
,grpc-encoding
,grpc-previous-rpc-attempts
,grpc-tags-bin
,grpc-timeout
undgrpc-trace-bin
.Wenn Sie die Hostregel einer URL-Zuordnung aktualisieren, um von einem Back-End-Dienst zu einem anderen zu wechseln, wird der Traffic möglicherweise unterbrochen, während die neue Konfiguration an die Clients übertragen wird. Konfigurieren Sie die Trafficaufteilung mit gewichteten Back-End-Diensten, um diese Einschränkung zu vermeiden. Nachdem Sie die Trafficaufteilung konfiguriert haben, verschieben Sie den Traffic langsam vom alten Back-End-Dienst zum neuen Back-End-Dienst.
Einschränkungen für gRPC-Zielproxys
Wenn ein Ziel-gRPC-Proxy auf eine URL-Zuordnung verweist, können Sie die folgenden URL-Zuordnungsfeatures nicht konfigurieren. Dies gilt unabhängig davon, ob Sie einen Sidecar-Proxy oder einen proxylosen gRPC-Dienst verwenden, da diese HTTP-Protokoll-spezifischen Features nicht für das gRPC-Protokoll gelten:
queryParameterMatches
Übereinstimmungsregel- Routingaktion
urlRewrite
- Routingaktion
urlRedirect
- Aktion
corsPolicy
Einschränkungen für Back-End-Dienste
Die folgenden Back-End-Dienstfeatures werden für proxylose gRPC-Dienste mit einem Sidecar-Proxy nicht unterstützt:
localityLbPolicy
außerLEAST_REQUEST
(nur mit Java-Clients),ROUND_ROBIN
undRING_HASH
sessionAffinity
außerHEADER_FIELD
undNONE
consistentHash
außer den FeldernhttpHeaderName
undminimumRingSize
affinityCookieTtlSec
timeoutSec
; verwenden Sie stattdessenmaxStreamDuration
.circuitBreakers
außer dem FeldmaxRequests
Beachten Sie, dass ein gRPC-Client die Konfiguration aus dem Cloud Service Mesh mit einem Stick bestätigt, wenn nicht unterstützte Werte konfiguriert werden. Dies führt dazu, dass die Konfiguration für alle Back-End-Dienste vom Client abgelehnt wird, da das xDS-Protokoll alle Ressourcen in einer bestimmten Antwort ablehnen muss, anstatt nur eine einzelne Ressource aus der Antwort ablehnen zu können. Dies führt dazu, dass der Client-Kanal vorübergehend in einen Fehlerzustand versetzt wird, bis die Konfiguration korrigiert wurde. Aufgrund dieser Einschränkung müssen Sie dafür sorgen, dass alle Clients den erforderlichen Wert unterstützen, bevor Sie ein Feature für einen Dienst konfigurieren. Wenn Sie beispielsweise die Richtlinie ROUND_ROBIN
in RING_HASH
ändern, müssen Sie dafür sorgen, dass alle Clients auf eine Version aktualisiert werden, die RING_HASH
unterstützt.
Einschränkungen für die erweiterte Trafficverwaltung
Sie können einige Features der erweiterten Traffic-Verwaltung für proxylose gRPC-Dienste mit Cloud Service Mesh nicht konfigurieren. Unterstützte Funktionen findest du hier:
- Unterstützte gRPC-Versionen und -Sprachen
- Cloud Service Mesh-Features, einschließlich Load-Balancing
Einschränkungen bei Service Directory
- Service Directory und Cloud Service Mesh garantieren keine Netzwerkerreichbarkeit für Clients.
Ein Backend-Dienst kann nur auf einen der folgenden Werte verweisen:
- Verwaltete Instanzgruppe oder nicht verwaltete Instanzgruppe
- Netzwerk-Endpunktgruppe
- Dienstbindungen
Service Directory-Dienste können nur mit globalen Backend-Diensten mit
load-balancing-scheme=INTERNAL_SELF_MANAGED
verwendet werden.Ein Service Directory-Dienst, auf den von einer Dienstbindung verwiesen wird, kann gelöscht werden. Wenn der zugrunde liegende Service Directory-Dienst, an den der Back-End-Dienst angehängt ist, gelöscht wird, können Anwendungen, die Cloud Service Mesh verwenden, keinen Traffic an diesen Dienst senden. Daher schlagen Anfragen fehl. Best Practices finden Sie unter Beobachtbarkeit und Fehlerbehebung.
Wenn Sie einen Service Directory-Dienst an einen Back-End-Dienst binden, können Sie keine Systemdiagnose für diesen Back-End-Dienst konfigurieren.
Nächste Schritte
- Informationen zu den Einschränkungen für Cloud Service Mesh, einschließlich der erweiterten Traffic-Verwaltungseinschränkungen, finden Sie unter Einschränkungen von Cloud Service Mesh.
- Informationen zu Anwendungsfällen und Architekturmustern für proxylose gRPC-Dienste finden Sie in der Proxylose gRPC-Dienste – Übersicht.