Visão geral do gerenciamento de tráfego avançado para APIs de balanceamento de carga

Observação: este guia só oferece suporte ao Cloud Service Mesh com as APIs do Google Cloud e não oferece suporte às APIs do Istio. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Este documento é destinado a administradores de malha ou plataforma e desenvolvedores de serviços que têm um nível intermediário ou avançado de familiaridade com o Cloud Service Mesh e os conceitos da malha de serviço e que determinam e configuram como o tráfego é gerenciado em uma implantação do Cloud Service Mesh. Este documento se aplica somente às APIs de balanceamento de carga, não às APIs de roteamento de serviço. Se a implantação do Cloud Service Mesh usar as APIs de roteamento de serviço, consulte a Visão geral do gerenciamento de tráfego avançado.

O Cloud Service Mesh oferece recursos avançados de gerenciamento de tráfego que dão um controle refinado sobre como o tráfego é processado. O Cloud Service Mesh é compatível com os seguintes casos de uso:

• Roteamento detalhado de solicitações para um ou mais serviços
• Divisão de tráfego baseada no peso para distribuir tráfego em vários serviços
• Políticas de espelhamento de tráfego que enviam solicitações a um serviço de depuração e copiam para outro
• Distribuição de tráfego ajustada entre os back-ends de um serviço para melhor balanceamento de carga

Esses recursos avançados de gerenciamento de tráfego permitem que você alcance seus objetivos de disponibilidade e desempenho. Um dos benefícios de usar Para esses casos de uso, é possível atualizar o modo como o tráfego é gerenciado sem precisar modificar o código do aplicativo.

• Quando você usa o proxy HTTP de destino na configuração dos proxies do Envoy para enviar solicitações HTTP, todos os recursos neste documento estão disponíveis.

• Quando você usa serviços ou aplicativos gRPC sem proxy com o Cloud Service Mesh, alguns recursos não estão disponíveis.

• Quando você usa o proxy TCP de destino na configuração dos proxies do Envoy para enviar solicitações TCP, nenhum dos recursos está disponível porque não há mapa de URL nas configurações com um proxy TCP de destino.

Para mais detalhes, consulte a página Recursos.

Para configurar o gerenciamento de tráfego avançado, use os mesmos recursos de mapa de regra de roteamento e serviços de back-end usados na configuração do Cloud Service Mesh. A Cloud Service Mesh, por sua vez, configura seus proxies Envoy e aplicativos gRPC sem proxy para aplicar as políticas avançadas de gerenciamento de tráfego que você configurou.

Em geral, você faz o seguinte:

1. Configure o mapa de regras de roteamento para fazer o seguinte, com base nas características da solicitação de saída:

   1. Selecione o serviço de back-end para onde as solicitações são roteadas.

   2. Opcionalmente, realize outras ações.

2. Configure o serviço (back-end) para controlar como o tráfego é distribuído para back-ends e endpoints depois que um serviço de destino é selecionado.

Configuração de filtragem

Uma das principais responsabilidades do Cloud Service Mesh é gerar configurações da regra de encaminhamento, do proxy de destino e do mapa de URL e envie esse para clientes do Cloud Service Mesh, por exemplo, proxies Envoy e gRPC aplicativos conteinerizados. O Cloud Service Mesh controla a malha de serviço enviando informações de configuração para seus clientes que informam como eles devem se comportar e como para rotear tráfego: o Cloud Service Mesh é o plano de controle.

Quando você cria ou atualiza informações de configuração no Cloud Service Mesh, ele traduz essa configuração em uma linguagem que os clientes possam entender. Por padrão, o Cloud Service Mesh compartilha isso do Terraform com todos os clientes. Em alguns casos, você pode querer adaptar quais clientes do Cloud Service Mesh recebem informações de configuração específicas, em em outras palavras, filtrar a configuração para clientes específicos.

Embora esse seja um recurso avançado, os exemplos a seguir ilustram quando configuração de filtragem pode ajudar você a:

• Sua organização usa o modelo de rede VPC compartilhada e várias as equipes usam o Cloud Service Mesh em diferentes projetos de serviço. Se você isolar sua configuração de outros projetos de serviço, é possível filtrar a configuração para que clientes específicos do Cloud Service Mesh recebem apenas um subconjunto da configuração.
• Há um grande número de regras de rota e serviços configurados em o Cloud Service Mesh e quiser evitar o envio de uma quantidade excepcionalmente grande de configuração a cada cliente do Cloud Service Mesh. Lembre-se de que um cliente que precisa avaliar uma solicitação de saída usando uma configuração grande e complexa pode ter um desempenho inferior ao de um cliente que só precisa avaliar uma solicitação usando uma configuração simplificada.

O filtro de configuração é baseado no conceito de filtros de metadados:

1. Quando um cliente do Cloud Service Mesh se conecta, ele apresenta informações do arquivo de inicialização para o Cloud Service Mesh.
2. Essas informações têm o conteúdo dos campos de metadados, na forma de pares de chave-valor, especificados no arquivo de bootstrap quando você implanta os proxies Envoy e/ou aplicativos gRPC.
3. É possível adicionar filtros de metadados à regra de encaminhamento. Toda a configuração vinculada à regra de encaminhamento é filtrada.
4. Você pode adicionar filtros de metadados no mapa de URL. O filtro de metadados é aplicado a cada roteamento de caminho.
5. A Cloud Service Mesh compartilha a configuração apenas com clientes que apresentam metadados que correspondem às condições do filtro de metadados.

Para informações sobre como configurar filtros de metadados para o Envoy, consulte Configurar filtro de configuração com base na correspondência MetadataFilter.

Roteamento de tráfego e ações

No Cloud Service Mesh, o mapa de regras de roteamento se refere à combinação dos recursos de regra de encaminhamento, proxy de destino e mapa de URL. Todos os recursos de gerenciamento de tráfego avançado relacionados ao roteamento e às ações são configurados usando o mapa de URL.

As seções a seguir descrevem os recursos avançados de gerenciamento de tráfego que podem ser configurados no mapa de regras de roteamento.

Processamento de solicitações

Quando um cliente envia uma solicitação, ela é tratada conforme descrito nas etapas a seguir:

1. A solicitação corresponde a um mapa de regras de roteamento específico, da seguinte maneira:

   • Se você estiver usando o Envoy:

     • O endereço IP e a porta de destino da solicitação são comparados com o endereço IP e a porta das regras de encaminhamento em todos os mapas de regras de roteamento. São considerados apenas os mapas de regras de roteamento com regras de encaminhamento que tenham o esquema de balanceamento de carga INTERNAL_SELF_MANAGED.
     • A regra de encaminhamento que corresponde à solicitação se refere a um proxy HTTP ou gRPC de destino, que se refere a um mapa de URL. Esse mapa de URL contém informações usadas para criar roteamento e ações.

   • Se você estiver usando o gRPC sem proxy:

     • Um cliente gRPC que usa o esquema de resolução de nome xds não executa uma busca DNS para resolver o nome do host no URI do canal. Em vez disso, esse cliente resolve o hostname[:port] no URI de destino enviando uma solicitação LDS para o Cloud Service Mesh.
     • Somente a porta de uma regra de encaminhamento com o esquema de balanceamento de carga INTERNAL_SELF_MANAGED é comparada à porta no URI de destino (por exemplo, xds:///example.hostname:8080). O endereço IP da regra de encaminhamento não é usado. O valor padrão da porta será 80 se nenhuma porta for especificada no URI de destino.
     • A regra de encaminhamento que corresponde à solicitação se refere a um proxy gRPC de destino, que referencia um mapa de URL. Esse mapa de URL contém informações usadas para criar roteamento e ações.
     • Se mais de uma regra de encaminhamento corresponder à solicitação, o mapa de URL que contém a regra de host que corresponde a hostname[:port] no URI de destino será usado para roteamento e ações.

2. Quando o mapa de URL apropriado é determinado, o mapa de URL é avaliado para determinar o serviço de back-end de destino e, opcionalmente, aplicar ações.

3. Depois que o serviço de back-end de destino é selecionado, o tráfego é distribuído entre os back-ends ou endpoints desse serviço de back-end, de acordo com a configuração do recurso do serviço de back-end.

A segunda etapa é descrita na seção a seguir, Roteamento simples com base no host e no caminho. A terceira etapa é discutida em Roteamento e ações avançados.

Roteamento simples com base no host e no caminho

O Cloud Service Mesh oferece suporte a esquemas de roteamento simplificados e mais avançados. No esquema simples, você especifica um host e, opcionalmente, um caminho. O host e o caminho da solicitação são avaliados para determinar o serviço a que uma solicitação será roteada.

• O host da solicitação é a parte do nome de domínio de um URL. Por exemplo, a parte do host do URL http://example.com/video/ é example.com.
• O caminho da solicitação é a parte do URL que segue o nome do host. Por exemplo, a parte do caminho do URL http://example.com/video/ é /video.

Você configura o roteamento simples com base no host e no caminho no mapa de regras de roteamento, que consiste no seguinte:

• uma regra de encaminhamento global;
• Um proxy HTTP de destino, um proxy HTTPS de destino ou um proxy gRPC de destino
• Um mapa de URL

A maior parte da configuração é feita no mapa de URL. Depois de criar o mapa de regras de roteamento inicial, é preciso modificar apenas a parte do mapa de URL do mapa de regras de roteamento. No diagrama a seguir, as regras de caminho têm ações semelhantes às do próximo diagrama.

Roteamento com base em recursos de host e caminho (clique para ampliar)

A regra mais simples é uma regra padrão, em que você especifica apenas uma regra de host curinga (*) e uma correspondência de caminho com um serviço padrão. Depois de criar a regra padrão, é possível adicionar outras regras para especificar diferentes hosts e caminhos. As solicitações de saída são avaliadas de acordo com essas regras, da seguinte maneira:

• Se o host de uma solicitação (como example.com) corresponder a uma regra de host:

  1. A correspondência de caminho é avaliada a seguir.
  2. Cada correspondência de caminho contém uma ou mais regras de caminho que são avaliadas em relação ao caminho da solicitação.
  3. Se for encontrada uma correspondência, a solicitação será roteada para o serviço especificado na regra de caminho.
  4. Se houver correspondência apenas da regra de host e de nenhuma de caminho, as solicitações serão roteadas para um serviço padrão contido em cada correspondência de caminho.

• Se a solicitação não corresponder a nenhuma das regras de host especificadas, ela será roteada para o serviço especificado na regra padrão.

Para mais informações sobre os campos de recursos do mapa de URL e como eles funcionam, consulte a página da API REST urlMaps.

Roteamento avançado e ações

Se você quiser fazer mais do que encaminhar uma solicitação com base no host e no caminho dela, poderá configurar regras avançadas para rotear solicitações e realizar ações.

Roteamento avançado (clique para ampliar)

De modo geral, o roteamento avançado e as ações funcionam da seguinte maneira:

1. Assim como no roteamento simples, o host da solicitação é comparado às regras de host que você configura no mapa de URL. Se o host de uma solicitação corresponder a uma regra de host, a correspondência de caminho da regra de host será avaliada.
2. A correspondência de caminho contém uma ou mais regras de rota que são avaliadas em relação à solicitação. Essas regras de rota são avaliadas em ordem de prioridade, combinando os atributos da solicitação (host, caminho, cabeçalho e parâmetros de consulta) de acordo com as condições de correspondência específicas, por exemplo, correspondência de prefixo.
3. É possível aplicar ações após a seleção de uma regra de rota. A ação padrão é encaminhar a solicitação para um único serviço de destino, mas também é possível configurar outras ações.

Roteamento avançado

O roteamento avançado é semelhante ao roteamento simples descrito anteriormente, exceto que é possível especificar a prioridade da regra e outras condições de correspondência.

Com o roteamento avançado, você precisa especificar uma prioridade exclusiva para cada regra. Essa prioridade determina a ordem em que as regras de rota são avaliadas. Os valores de prioridade mais baixa são priorizados em relação aos valores de prioridade mais alta. Quando uma solicitação corresponde a uma das regras, ela é aplicada e as outras são ignoradas.

O roteamento avançado também é compatível com outras condições de correspondência. Por exemplo, é possível especificar que uma regra corresponderá ao cabeçalho de uma solicitação se o nome do cabeçalho corresponder exatamente ou apenas parcialmente, por exemplo, com base no prefixo ou no sufixo. A correspondência pode ser feita com base na avaliação do nome do cabeçalho com uma expressão regular ou em outros critérios, como a verificação da presença de um cabeçalho.

Para mais condições de correspondência e detalhes para headerMatches e queryParameterMatches, consulte a página API REST urlMaps.

Ao combinar os parâmetros de host, caminho, cabeçalho e consulta com prioridades e condições de correspondência, é possível criar regras altamente expressivas que atendam exatamente aos seus requisitos de gerenciamento de tráfego. Veja mais detalhes na tabela a seguir.

	Aplicativo baseado em HTTP	Aplicativo baseado em gRPC
Hosts HTTP versus hosts gRPC	O host é a parte do nome de domínio do URL que o aplicativo chama. Por exemplo, a parte do host do URL http://example.com/video/ é example.com.	O host é o nome que um cliente usa no URI do canal para se conectar a um serviço específico. Por exemplo, a parte do host do URI do canal xds:///example.com é example.com.
Caminhos HTTP versus caminhos gRPC	O caminho é a parte do URL que segue o nome do host. Por exemplo, a parte do caminho do URL http://example.com/video é /video.	O caminho está no cabeçalho :path da solicitação HTTP/2 e é semelhante a /SERVICE_NAME/METHOD_NAME. Por exemplo, se você chamar o método Download no serviço gRPC Example, o conteúdo do cabeçalho :path será semelhante a /Example/Download.
Outros cabeçalhos gRPC (metadados)		O gRPC é compatível com o envio de metadados entre o cliente gRPC e o servidor gRPC para fornecer outras informações sobre uma chamada RPC. Esses metadados estão na forma de pares de chave-valor, transferidos como cabeçalhos na solicitação HTTP/2.

Ações

O Cloud Service Mesh permite especificar ações que o Envoy envia proxies ou que os aplicativos gRPC sem proxy realizam ao processar uma solicitação. As ações a seguir pode ser configurado com o Cloud Service Mesh.

Observação :todos os recursos a seguir estão disponíveis ao usar Envoy com o Cloud Service Mesh. Alguns dos recursos ainda não estão disponíveis quando você usa aplicativos gRPC sem proxy com o Cloud Service Mesh. Para mais detalhes, consulte as páginas Recursos e Limitações com o gRPC sem proxy.

Ação	Nome do campo da API	Descrição
Redirecionamentos	urlRedirect	Retorna um código de resposta 3xx configurável. Ele também define o cabeçalho de resposta Location com o URI apropriado, substituindo o host e o caminho, conforme especificado na ação de redirecionamento.
Regravações de URL	urlRewrite	Regrava a parte do nome do host e do caminho do URL ou ambas, antes de enviar uma solicitação ao serviço de back-end seleccionado.
Transformações de cabeçalho	headerAction	Adiciona e remove cabeçalhos antes de enviar uma solicitação ao serviço de back-end. Também é possível adicionar ou remover cabeçalhos de resposta depois de receber uma resposta do serviço de back-end.
Espelhamento do tráfego	requestMirrorPolicy	Além de encaminhar a solicitação ao serviço de back-end selecionado, envia outra idêntica ao serviço de back-end de espelhamento configurado, de forma autônoma. O balanceador de carga não espera uma resposta do back-end a que envia a solicitação espelhada. O espelhamento é útil para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não em uma versão de produção.
Divisão de tráfego baseada no peso	weightedBackendServices	Permite que o tráfego de uma regra correspondente seja distribuído a vários serviços de back-end, de maneira proporcional a um peso definido pelo usuário e atribuído ao serviço de back-end individual. Esse recurso é útil para configurar implantações em estágios ou testes A/B. Por exemplo, a ação de rota pode ser configurada para que 99% do tráfego seja enviado a um serviço que executa uma versão estável de umaplicativo. Já 1% do tráfego é enviado a um serviço separado que executa uma versão mais recente desse aplicativo.
Novas tentativas	retryPolicy	Configura as condições em que o balanceador de carga faz novas tentativas das solicitações com falha, quanto tempo o balanceador aguarda antes de tentar novamente e o número máximo de novas tentativas permitidas.
Tempo limite	timeout	Especifica o tempo limite da rota selecionada. Ele é calculado com base no momento entre o processamento total da solicitação e da resposta. O tempo limite inclui todas as novas tentativas.
Injeção de falha	faultInjectionPolicy	Insere erros ao atender às solicitações para simular falhas, incluindo alta latência, sobrecarga, de serviço, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas.
Políticas de segurança	corsPolicy	As políticas de compartilhamento de recursos entre origens (CORS, na sigla em inglês) processam as configurações para aplicar solicitações CORS.

Para mais informações sobre ações e como elas funcionam, consulte a página API REST urlMaps.

Em cada regra de rota, é possível especificar uma das ações de rota a seguir, chamadas de Ações primárias no Console do Google Cloud:

• Encaminhar o tráfego para um único serviço (service)
• Dividir o tráfego entre vários serviços (weightedBackendServices)
• URLs de redirecionamento (urlRedirect)

Além disso, é possível combinar qualquer uma das ações de rota mencionadas anteriormente a uma ou mais destas, chamadas de ações de complemento no Console do Cloud:

• Gerenciar cabeçalhos de solicitação/resposta (headerAction).
• Espelhar tráfego (requestMirrorPolicy)
• Reescrever host, caminho ou ambos do URL (urlRewrite).
• Tentar novamente solicitações com falha (retryPolicy)
• Definir tempo limite (timeout).
• Inserir falhas em um percentual do tráfego (faultInjectionPolicy).
• Adicionar política de CORS (corsPolicy).

Como as ações estão associadas a regras de rota específicas, o proxy Envoy ou o aplicativo gRPC sem proxy podem aplicar ações diferentes com base na solicitação em processamento.

Como distribuir tráfego entre os back-ends de um serviço

Conforme mencionado em Processamento de solicitações, quando um cliente gerencia uma solicitação de saída, primeiro ele seleciona um serviço de destino. Depois disso, ele precisa descobrir qual back-end ou endpoint deve receber a solicitação.

Como distribuir tráfego entre back-ends (clique para ampliar)

No diagrama anterior, Regra foi simplificada. Em geral, Regra é uma regra de host, uma correspondência de caminho e uma ou mais regras de caminho ou rota. O serviço de destino é o Serviço de back-end. Backend 1, …, e Backend n recebem e processam a solicitação. Esses back-ends podem ser, por exemplo, instâncias de máquina virtual (VM) do Compute Engine que hospedam o código do aplicativo do servidor.

Por padrão, o cliente que gerencia a solicitação envia solicitações para o back-end íntegro mais próximo que tenha capacidade. Para evitar a sobrecarga de um back-end específico, ele usa o algoritmo de balanceamento de carga round-robin para balancear solicitações subsequentes em outros back-ends do serviço de destino. Em alguns casos, convém ter um controle mais refinado sobre esse comportamento.

Balanceamento de carga, afinidade da sessão e proteção de back-ends

É possível definir as seguintes políticas de distribuição de tráfego em cada serviço.

Política	Nome do campo da API	Descrição
Modo de balanceamento de carga	balancingMode	Controla como um grupo de endpoints de rede (NEG, na sigla em inglês) ou um grupo de instâncias gerenciadas (MIG, na sigla em inglês) é selecionado após a seleção de um serviço de destino. É possível configurar o modo de balanceamento para distribuir a carga com base em conexões simultâneas e taxa de solicitação.
Política de balanceamento de carga	localityLbPolicy	Define o algoritmo de balanceamento de carga usado para distribuir o tráfego entre back-ends em um NEG ou MIG. Para otimizar o desempenho, é possível escolher entre vários algoritmos, como "round robin" ou "menor solicitação".
Afinidade da sessão	sessionAffinity	Fornece uma tentativa de melhor esforço para enviar solicitações de um cliente específico ao mesmo back-end enquanto ele estiver íntegro e tiver capacidade. O Cloud Service Mesh é compatível com quatro opções de afinidade de sessão: endereço IP do cliente, baseado em cookie HTTP, baseado em cabeçalho HTTP e afinidade de cookie gerada (que é gerada pelo próprio Cloud Service Mesh).
Hash consistente	consistentHash	Fornece afinidade de sessão suave com base em cabeçalhos HTTP, cookies ou outras propriedades.
Disjuntores	circuitBreakers	Define limites máximos no volume de conexões e solicitações por conexão para um serviço de back-end.
Detecção de outlier	outlierDetection	Especifica os critérios para (1) remover back-ends não íntegros ou endpoints de MIGs ou NEGs e (2) adicionar um back-end ou endpoint de volta quando ele é considerado íntegro o suficiente para receber tráfego novamente. A verificação de integridade associada ao serviço determina se um back-end ou endpoint é considerado íntegro.

Para mais informações sobre diferentes opções de distribuição de tráfego e como elas funcionam, consulte a página API REST backendServices.

Exemplos de casos de uso

O gerenciamento de tráfego avançado atende a muitos casos de uso. Nesta seção, você verá alguns exemplos detalhados.

Veja mais exemplos, incluindo código de amostra, nos guias Como configurar o gerenciamento de tráfego avançado e Como configurar serviços gRPC sem proxy com gerenciamento de tráfego avançado.

Roteamento de tráfego detalhado para personalização

Você pode rotear o tráfego para um serviço com base nos parâmetros da solicitação. Por exemplo, é possível usar esse serviço para fornecer uma experiência mais personalizada para usuários do Android. No diagrama a seguir, o Cloud Service Mesh configura sua malha de serviço para enviar solicitações com o cabeçalho user-agent:Android para sua Android em vez de ao serviço genérico.

Roteamento baseado no cabeçalho user-agent definido como Android (clique para ampliar)

Divisão de tráfego baseada em peso para implantações mais seguras

A implantação de uma nova versão de um serviço de produção atual pode ser arriscada. Mesmo depois que os testes forem aprovados em um ambiente de teste, talvez você não queira encaminhar imediatamente todos os usuários para a nova versão.

O Cloud Service Mesh permite definir divisões de tráfego baseadas em peso para distribuir o tráfego entre vários serviços. Por exemplo, é possível enviar 1% do tráfego para a nova versão do seu serviço, monitorar se tudo funciona e aumentar gradualmente a proporção de tráfego para o novo serviço.

Divisão de tráfego com base em peso do Cloud Service Mesh (clique para ampliar)

Espelhamento de tráfego para depuração

Ao depurar um problema, pode ser útil enviar cópias do tráfego de produção para um serviço de depuração. O Cloud Service Mesh permite que você configure solicitações políticas de espelhamento para que as solicitações sejam enviadas a um serviço e cópias desses as solicitações são enviadas para outro serviço.

Espelhamento de tráfego da Cloud Service Mesh (clique para ampliar)

Balanceamento de carga ajustado para desempenho

Dependendo das características do seu aplicativo, você pode melhorar o desempenho e a disponibilidade ajustando o modo como o tráfego é distribuído entre os back-ends de um serviço. Com o Cloud Service Mesh, é possível aplicar algoritmos avançados de balanceamento de carga para que o tráfego seja distribuído de acordo com suas necessidades.

O diagrama a seguir, em contraste com os diagramas anteriores, mostra um serviço de backend de destino (Serviço de produção) e os back-ends dele (Máquina virtual 1, Máquina virtual 2, Máquina Virtual 3). Com o gerenciamento de tráfego avançado, é possível configurar como um serviço de back-end de destino é selecionado e como o tráfego é distribuído entre os back-ends desse serviço de destino.

Balanceamento de carga do Cloud Service Mesh(clique para ampliar)

A seguir

• Para ler mais sobre mapas de URLs, consulte Visão geral de mapas de URL e Usar mapas de URL.
• Para direcionar o tráfego de fora da malha para a malha, consulte Tráfego de entrada para a malha.
• Para configurar recursos com implantações de proxy de arquivo secundário, consulte Configurar o gerenciamento de tráfego avançado com o Envoy.
• Para configurar recursos com implantações do gRPC sem proxy, consulte Configurar o gerenciamento de tráfego avançado com serviços do gRPC sem proxy.