Limitações do gRPC sem proxy

Este documento descreve as limitações que se aplicam à malha de serviço do Cloud com aplicativos gRPC sem proxy. Para mais informações sobre limites, consulte Cotas e limites.

As limitações em regras de encaminhamento, mapas de URL e proxies de destino se aplicam apenas ao Cloud Service Mesh com as APIs de balanceamento de carga do Google Cloud.

Limitações gerais

As limitações da Cloud Service Mesh com aplicativos gRPC sem proxy incluem:

  • Não é possível configurar serviços de back-end e mapas de regras de roteamento com o protocolo gRPC no Console do Google Cloud. Para esses recursos, o Console do Google Cloud é somente leitura.

  • O gRPC sem proxy é compatível com descoberta de endpoints, roteamento, balanceamento de carga, relatórios de carga e muitos recursos avançados de gerenciamento de tráfego.

    • Para saber a versão mínima do gRPC necessária para compatibilidade com alguns recursos de gerenciamento de tráfego avançado, consulte Versões e linguagens compatíveis do gRPC.

    • Para seus aplicativos gRPC que precisam de recursos avançados de gerenciamento de tráfego, use o resolvedor de nomes DNS em vez do resolvedor xDS e implante com proxies sidecar que sejam compatíveis com o Cloud Service Mesh. No proxy gRPC de destino, defina o campo validateForProxyless como FALSE. para configurar recursos que ainda não são compatíveis com o gRPC, que estão disponíveis no Cloud Service Mesh com o uso de proxies sidecar.

  • O gRPC sem proxy é compatível apenas com políticas de balanceamento de carga de rodízio e anel de hash. Não há suporte para outras políticas de balanceamento de carga.

    • O Cloud Service Mesh oferece uma lista ponderada priorizada de localidades: um grupo de instâncias ou um grupo de endpoints de rede (NEG) para o cliente gRPC. O Cloud Service Mesh calcula essa lista com base na zona disponível mais próxima, na capacidade dela e no modo de balanceamento do serviço de back-end.
    • Para uma solicitação específica, o cliente gRPC seleciona uma ou mais localidades com base na prioridade e ponderação e faz o balanceamento de carga round-robin ou anel de hash em back-ends nessas localidades.

  • O failover de uma zona (localidade) para outra começa quando a capacidade da zona atual fica abaixo de 50%. Não é possível configurar esse limite.

  • Em alguns casos, os comandos de configuração relacionados a um proxy gRPC de destino e uma regra de encaminhamento que referenciam um proxy de destino do gRPC podem levar até um minuto.

  • Os NEGs de conectividade híbrida (NEGs NON_GCP_PRIVATE_IP_PORT) não são compatíveis com clientes gRPC sem proxy.

Limitações do mapa de URLs

Os seguintes recursos de gerenciamento de tráfego do mapa de URLs são compatíveis com serviços gRPC sem proxy.

Recursos compatíveis com o pathMatcher de 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 limitações do mapa de URL a seguir se aplicam quando você usa serviços gRPC sem proxy:

  • Não há compatibilidade para caracteres curinga nas regras de host e regras padrão de um mapa de URL, incluindo a regra de host * criada implicitamente de um mapa de URL. Essas entradas são ignoradas quando a correspondência do host é feita.

  • Os recursos a seguir não são compatíveis:

    • queryParameterMatches em routeRules
    • headerAction, urlRewrite, requestMirrorPolicy, corsPolicy, e urlRedirect ações de rota
    • Ação de rota 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
    • O defaultService, defaultRouteAction, defaultUrlRedirect e headerAction do mapa de URLs não são usados por serviços gRPC sem proxy. Se um regra de host correspondente não for encontrada quando um cliente gRPC sem proxy procurar um nome do serviço, o Cloud Service Mesh retorna um erro de pesquisa de nome em vez de usando o serviço ou a ação padrão do mapa de URL.
    • headerAction em weightedBackendServices

  • Nas regras de correspondência de cabeçalho do mapa de URLs, somente os metadados personalizados não especificados pelo usuário e o cabeçalho content-type são compatíveis. Os seguintes cabeçalhos no nível de transporte não podem ser usados em regras de correspondência de cabeçalho: :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 você atualiza uma regra de host do mapa de URLs para mudar de um serviço de back-end para outro, o tráfego pode ficar inativo momentaneamente enquanto a nova configuração é enviada aos clientes. Para evitar essa limitação, configure a divisão de tráfego com serviços de back-end ponderado. Depois de configurar a divisão de tráfego, transfira lentamente o tráfego do serviço de back-end antigo para o novo.

Limitações do proxy gRPC de destino

Quando um proxy gRPC de destino faz referência a um mapa de URL, não é possível configurar os recursos do mapa de URL a seguir. Isso ocorre independentemente de você estar usando um proxy sidecar ou um serviço gRPC sem proxy, porque esses recursos específicos do protocolo HTTP não se aplicam ao protocolo gRPC:

  • queryParameterMatches regra de correspondência
  • Ação de rota urlRewrite
  • Ação de rota urlRedirect
  • Ação corsPolicy

Limitações do serviço de back-end

Os seguintes recursos do serviço de back-end não são compatíveis com os serviços gRPC sem proxy com um proxy sidecar:

  • localityLbPolicy, exceto LEAST_REQUEST (somente para clientes Java), ROUND_ROBIN e RING_HASH
  • sessionAffinity, exceto HEADER_FIELD e NONE
  • consistentHash, exceto os campos httpHeaderName e minimumRingSize
  • affinityCookieTtlSec
  • timeoutSec, use maxStreamDuration.
  • circuitBreakers exceto o campo maxRequests

Um cliente gRPC NACK fará a configuração do Cloud Service Mesh quando valores não compatíveis forem configurados. Isso fará com que a configuração de todos os serviços de back-end seja rejeitada pelo cliente porque o protocolo xDS exige atualmente a rejeição de todos os recursos em uma determinada resposta, em vez de poder rejeitar apenas um recurso individual da resposta de dados. Isso fará com que o canal do cliente entre em um estado de erro temporário até que a configuração seja corrigida. Devido a essa limitação, você precisa garantir que todos os clientes sejam compatíveis com o valor necessário antes de configurar um recurso para um serviço. Por exemplo, se você mudar a política ROUND_ROBIN para RING_HASH, será necessário garantir que todos os clientes sejam atualizados para uma versão compatível com RING_HASH.

Limitações avançadas de gerenciamento de tráfego

Não é possível configurar alguns recursos avançados de gerenciamento de tráfego para serviços gRPC sem proxy com a Cloud Service Mesh. Para recursos compatíveis, consulte a seguintes:

Limitações com o Diretório de serviços

  • O Diretório de serviços e a Cloud Service Mesh não garantem a acessibilidade da rede para clientes.

  • Um serviço de back-end só pode referir-se a um dos seguintes itens:

    • Grupo de instâncias gerenciadas ou não gerenciada
    • Grupo de endpoints de rede
    • Vinculações de serviço

  • Os serviços do Diretório de serviços só podem ser usados com serviços de back-end globais com load-balancing-scheme=INTERNAL_SELF_MANAGED.

  • Um serviço do Diretório de serviços referenciado por uma vinculação de serviço pode ser excluído. Se o serviço do Diretório de serviços subjacente ao serviço de back-end for excluído, os aplicativos que usam o Cloud Service Mesh não poderão enviar tráfego para esse serviço. Portanto, as solicitações falharão. Para ver as práticas recomendadas, consulte Observabilidade e depuração.

  • Quando você vincula um serviço do Diretório de serviços a um serviço de back-end, não é possível configurar uma verificação de integridade nesse serviço de back-end.

A seguir