Limitações do gRPC sem proxy
Este documento descreve as limitações que se aplicam à Cloud Service Mesh com aplicações gRPC sem proxy. Para ver informações sobre os limites, consulte o artigo Quotas e limites.
As limitações nas regras de encaminhamento, nos mapas de URLs e nos proxies de destino aplicam-se apenas ao Cloud Service Mesh com as APIs de balanceamento de carga Google Cloud .
Limitações gerais
As limitações do Cloud Service Mesh com aplicações gRPC sem proxy incluem o seguinte:
Não pode configurar serviços de back-end e mapas de regras de encaminhamento com o protocolo gRPC na Google Cloud consola. Para estes recursos, a consolaGoogle Cloud é só de leitura.
O gRPC sem proxy suporta a deteção de pontos finais, o encaminhamento, o equilíbrio de carga, os relatórios de carga e muitas funcionalidades avançadas de gestão de tráfego.
Para saber a versão mínima do gRPC necessária para suportar algumas funcionalidades de gestão de tráfego avançada, consulte Versões e idiomas do gRPC suportados.
Para as suas aplicações gRPC que precisam de funcionalidades avançadas de gestão de tráfego não suportadas, use o resolvedor de nomes DNS em vez do resolvedor xDS e implemente com proxies sidecar suportados com a Cloud Service Mesh. No proxy gRPC de destino, defina o campo
validateForProxyless
comoFALSE
para poder configurar funcionalidades que ainda não são suportadas pelo gRPC, mas que estão disponíveis na Cloud Service Mesh com a utilização de proxies sidecar.
O gRPC sem proxy só suporta políticas de balanceamento de carga de hash circular e round robin. Não são suportadas outras políticas de equilíbrio de carga.
- A Cloud Service Mesh fornece uma lista ponderada prioritária de localidades, um grupo de instâncias ou um grupo de pontos finais de rede (NEG), ao cliente gRPC. O Cloud Service Mesh calcula esta lista com base na zona disponível mais próxima, na respetiva capacidade e no modo de equilíbrio do serviço de back-end.
- Para um pedido específico, o cliente gRPC seleciona uma ou mais localidades com base na prioridade e na ponderação e faz o equilíbrio de carga baseado em hash circular ou de robin para os back-ends nessas localidades.
A comutação por falha de uma zona (localidade) para outra começa quando a capacidade da zona atual fica abaixo de 50%. Não pode configurar este limite.
Em alguns casos, os comandos de configuração relacionados com um proxy gRPC de destino e uma regra de encaminhamento que faz referência a um proxy gRPC de destino podem demorar até um minuto.
Os NEGs de conetividade híbrida (NEGs
NON_GCP_PRIVATE_IP_PORT
) não são suportados com clientes gRPC sem proxy.
Limitações do mapa de URLs
As seguintes funcionalidades de gestão de tráfego do mapa de URLs são suportadas com serviços gRPC sem proxy.
Funcionalidades suportadas na pathMatcher
do hostRules
:
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
As seguintes limitações do mapa de URLs aplicam-se quando usa serviços gRPC sem proxy:
Os carateres universais nas regras de anfitrião e nas regras predefinidas de um mapa de URLs, incluindo a regra de anfitrião
*
criada implicitamente de um mapa de URLs, não são suportados. Essas entradas são ignoradas quando a correspondência de anfitriões é feita.As seguintes funcionalidades não são suportadas:
queryParameterMatches
emrouteRules
headerAction
,urlRewrite
,requestMirrorPolicy
,corsPolicy
eurlRedirect
ações de trajeto- Ação de trajeto
timeout
; usemaxStreamDuration
em vez detimeout
perTryTimeout
emretryPolicy
retryConditions
emretryPolicy
, exceto uma ou mais condições decancelled
,deadline-exceeded
,internal
,resource-exhausted
eunavailable
- Os campos
defaultService
,defaultRouteAction
,defaultUrlRedirect
eheaderAction
do mapa de URLs não são usados pelos serviços gRPC sem proxy. Se não for encontrada uma regra de anfitrião correspondente quando um cliente gRPC sem proxy procura um nome de serviço, o Cloud Service Mesh devolve um erro de procura de nome em vez de usar o serviço ou a ação predefinidos do mapa de URLs. headerAction
emweightedBackendServices
Nas regras de correspondência de cabeçalhos do mapa de URLs, apenas são suportados metadados personalizados especificados pelo utilizador não binários e o cabeçalho
content-type
. Os seguintes cabeçalhos ao nível do transporte não podem ser usados em regras de correspondência de cabeçalhos::authority
,:method
,:path
,:scheme
,user-agent
,accept-encoding
,content-encoding
,grpc-accept-encoding
,grpc-encoding
,grpc-previous-rpc-attempts
,grpc-tags-bin
,grpc-timeout
egrpc-trace-bin
.Quando atualiza uma regra de anfitrião do mapa de URLs para mudar de um serviço de back-end para outro, o tráfego pode ser interrompido momentaneamente enquanto a nova configuração é enviada para os clientes. Para evitar esta limitação, configure a divisão de tráfego com serviços de back-end ponderados. Após configurar a divisão de tráfego, transfira lentamente o tráfego do serviço de back-end antigo para o novo serviço de back-end.
Limitações do proxy gRPC de destino
Quando um proxy gRPC de destino faz referência a um mapa de URLs, não pode configurar as seguintes funcionalidades do mapa de URLs. Isto é verdade quer esteja a usar um proxy sidecar ou um serviço gRPC sem proxy, porque estas funcionalidades específicas do protocolo HTTP não se aplicam ao protocolo gRPC:
queryParameterMatches
regra de correspondênciaurlRewrite
ação de trajetourlRedirect
ação de trajetocorsPolicy
ação
Limitações do serviço de back-end
As seguintes funcionalidades do serviço de back-end não são suportadas com serviços gRPC sem proxy com um proxy sidecar:
localityLbPolicy
excetoLEAST_REQUEST
(apenas com clientes Java),ROUND_ROBIN
eRING_HASH
sessionAffinity
, excetoHEADER_FIELD
eNONE
consistentHash
, exceto os camposhttpHeaderName
eminimumRingSize
affinityCookieTtlSec
timeoutSec
; usemaxStreamDuration
em alternativacircuitBreakers
exceto o campomaxRequests
Tenha em atenção que um cliente gRPC envia um NACK à configuração do Cloud Service Mesh quando são configurados valores não suportados. Isto fará com que a configuração de todos os serviços de back-end seja rejeitada pelo cliente, porque o protocolo xDS requer a rejeição de todos os recursos numa determinada resposta, em vez de poder rejeitar apenas um recurso individual da resposta. Isto faz com que o canal do cliente entre num estado de erro temporário até que a configuração seja corrigida. Devido a esta limitação, tem de garantir que todos os clientes suportam o valor necessário antes de configurar uma funcionalidade para um serviço. Por exemplo, se alterar a política de ROUND_ROBIN
para RING_HASH
, tem de garantir que todos os clientes são atualizados para uma versão que suporte RING_HASH
.
Limitações da gestão avançada de tráfego
Não pode configurar algumas funcionalidades avançadas de gestão de tráfego para serviços gRPC sem proxy com a Cloud Service Mesh. Para ver as funcionalidades suportadas, consulte o seguinte:
- Versões e idiomas gRPC suportados
- Funcionalidades do Cloud Service Mesh, incluindo equilíbrio de carga
Limitações com o diretório de serviços
- O Service Directory e o Cloud Service Mesh não garantem a acessibilidade de rede para os clientes.
Um serviço de back-end só pode referenciar um dos seguintes elementos:
- Grupo de instâncias geridas ou grupo de instâncias não geridas
- Grupo de pontos finais da rede
- Vínculos de serviços
Os serviços do Service Directory só podem ser usados com serviços de back-end globais com
load-balancing-scheme=INTERNAL_SELF_MANAGED
.Pode eliminar um serviço do Service Directory referenciado por uma associação de serviços. Se o serviço Service Directory subjacente ao qual o serviço de back-end está anexado for eliminado, as aplicações que usam a Cloud Service Mesh não podem enviar tráfego para este serviço e, por isso, os pedidos falham. Consulte o artigo Observabilidade e depuração para ver as práticas recomendadas.
Quando associa um serviço do Service Directory a um serviço de back-end, não pode configurar uma verificação de estado nesse serviço de back-end.
O que se segue?
- Para saber mais sobre as limitações aplicáveis ao Cloud Service Mesh, incluindo limitações avançadas de gestão de tráfego, consulte o artigo Limitações do Cloud Service Mesh.
- Para encontrar exemplos de utilização e padrões de arquitetura para serviços gRPC sem proxy, consulte a vista geral dos serviços gRPC sem proxy.