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 como FALSE 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 em routeRules
    • headerAction, urlRewrite, requestMirrorPolicy, corsPolicy e urlRedirect ações de trajeto
    • Ação de trajeto timeout; use maxStreamDuration em vez de timeout
    • perTryTimeout em retryPolicy
    • retryConditions em retryPolicy, exceto uma ou mais condições de cancelled, deadline-exceeded, internal, resource-exhausted e unavailable
    • Os campos defaultService, defaultRouteAction, defaultUrlRedirect e headerAction 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 em weightedBackendServices
  • 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 e grpc-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ência
  • urlRewrite ação de trajeto
  • urlRedirect ação de trajeto
  • corsPolicy 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 exceto LEAST_REQUEST (apenas com clientes Java), ROUND_ROBIN e RING_HASH
  • sessionAffinity, exceto HEADER_FIELD e NONE
  • consistentHash, exceto os campos httpHeaderName e minimumRingSize
  • affinityCookieTtlSec
  • timeoutSec; use maxStreamDuration em alternativa
  • circuitBreakers exceto o campo maxRequests

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:

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?