Configure o gerenciamento avançado de tráfego com o Envoy
A configuração é compatível com clientes de pré-lançamento, mas não recomendamos para novos usuários do Cloud Service Mesh. Para mais informações, consulte a Visão geral do roteamento de serviço do Cloud Service Mesh.
Este documento fornece informações sobre como configurar o gerenciamento de tráfego avançado para implantações do Cloud Service Mesh que usam o Envoy.
Antes de começar
Antes de configurar o gerenciamento de tráfego avançado, siga as instruções em Prepare-se para configurar o Cloud Service Mesh com o Envoy, incluindo a configuração do Cloud Service Mesh e de qualquer host de máquina virtual (VM) ou clusters do Google Kubernetes Engine (GKE) de que você precisa. Crie os recursos necessários do Google Cloud.
A disponibilidade do recurso avançado de gerenciamento de tráfego é diferente de acordo com o protocolo de solicitação escolhido. Este protocolo é configurado quando você configura o roteamento usando os recursos de proxy HTTP ou HTTPS de destino, proxy gRPC de destino ou proxy TCP de destino:
- Com os proxies HTTP e HTTPS de destino, todos os recursos descritos neste documento estão disponíveis.
- Com o proxy gRPC de destino, alguns recursos estão disponíveis.
- Com o proxy TCP de destino, nenhum recurso avançado de gerenciamento de tráfego está disponível.
Para mais informações, consulte recursos do Cloud Service Mesh e Gerenciamento de tráfego avançado. Para um guia completo de configuração, consulte Configurar o gerenciamento avançado de tráfego com serviços gRPC sem proxy.
Configurar a divisão de tráfego
Os pressupostos destas instruções são os seguintes:
- Sua implantação do Cloud Service Mesh tem um mapa de URLs chamado
review-url-map
. - O mapa de URLs envia todo o tráfego para um serviço de back-end, chamado
review1
, que serve como serviço de back-end padrão. - Você planeja rotear 5% do tráfego para uma nova versão de um serviço. Esse serviço
está sendo executado em uma VM de back-end ou em um endpoint em um grupo de endpoints de rede (NEG, na sigla em inglês)
associado ao serviço de back-end
review2
. - Nenhuma regra de host ou correspondência de caminho é usada.
Se você estiver dividindo o tráfego para um novo serviço que não foi referenciado pelo mapa de URL antes, primeiro adicione o novo serviço a weightedBackendServices
e atribua um peso de 0
a ele. Em seguida, aumente gradualmente o peso atribuído a esse serviço.
Para configurar a divisão de tráfego, siga estas etapas:
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique em Mapas de regra de roteamento.
Clique em
Criar mapa de regras de roteamento.Na página Criar um mapa de regras de roteamento, digite um Nome.
No menu Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento atual.
Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
Em Correspondências de hosts e caminho, clique em
Adicionar correspondência de hosts e caminho. Isso adiciona uma nova correspondência de caminhos que pode ser configurada para dividir o tráfego.Adicione as configurações a seguir ao campo Correspondência de caminhos:
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
Clique em Concluído.
Clique em Save.
Quando estiver satisfeito com a nova versão, será possível ajustar gradualmente os
pesos dos dois serviços e, por fim, enviar todo o tráfego para review2
.
gcloud
Use o comando
gcloud export
para ver a configuração do mapa de URLs:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
Adicione a seção a seguir ao arquivo
review-url-map-config.yaml
:hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
Atualize o mapa de URLs:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Quando estiver satisfeito com a nova versão, será possível ajustar gradualmente os
pesos dos dois serviços e, por fim, enviar todo o tráfego para review2
.
Configurar uma versão parcial
Use um processo de implantação parcial, também chamado de canário, para liberar uma nova versão do software para uma pequena fração dos servidores antes de liberar a nova versão para o equilíbrio dos servidores de produção.
Uma versão parcial usa weightedBackendServices
. Para ativar uma versão parcial,
designe um serviço de back-end como de teste, ou canário, e dê a ele um peso
baixo, por exemplo, 2 ou 5. Implante a nova versão do software apenas nesses
servidores. Quando você achar que a nova versão não tem problemas, implante-a
no restante dos serviços.
- Para ativar uma versão parcial, use o seguinte exemplo de código de YAML:
pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_PARTIAL_URL weight: 2 - backendService: BACKEND_SERVICE_URL weight: 98
DEFAULT_SERVICE_URL
é o URL padrão do serviço.BACKEND_SERVICE_PARTIAL_URL
é o URL do serviço de back-end que recebe 2% do tráfego.BACKEND_SERVICE_URL
é o URL do serviço de back-end que recebe 98% do tráfego.
Configurar implantações azul-verde
As implantações azul-verde são modelos de versão que reduzem o tempo necessário para alternar o tráfego de produção para uma nova versão de um serviço ou para uma reversão de uma versão anterior do serviço. Essas implantações mantêm as duas versões do serviço disponíveis na produção e mudam o tráfego de uma para a outra.
Implantações azul-verde usam weightedBackendServices
. No exemplo YAML
a seguir, os back-ends para SERVICE_BLUE_URL
estão totalmente implantados com a versão de produção
atual. Os back-ends para SERVICE_GREEN_URL
estão totalmente implantados
com a nova versão. Na configuração do exemplo, a implantação GREEN
recebe
100% do tráfego de produção. Se você encontrar problemas, é possível reverter os
pesos das duas implantações, o que reverte de maneira eficaz a
versão GREEN
com defeito e restaura a versão BLUE
conhecida. Nos dois casos,
a alteração do tráfego pode ser feita rapidamente porque as duas versões estão disponíveis para receber
tráfego.
- Para ativar uma implantação azul-verde, use o seguinte exemplo de código de YAML:
pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_BLUE_URL weight: 0 - backendService: BACKEND_SERVICE_GREEN_URL weight: 100
DEFAULT_SERVICE_URL
é o URL padrão do serviço.BACKEND_SERVICE_BLUE_URL
é o URL do serviço de back-end que não recebe nenhum tráfego.BACKEND_SERVICE_GREEN_URL
é o URL do serviço de back-end que recebe 100% do tráfego.
Configure o espelhamento de tráfego
Use o espelhamento de tráfego quando quiser que o tráfego seja direcionado para dois serviços de back-end diferentes para fins de depuração ou teste de novos serviços.
No exemplo a seguir, todas as solicitações são enviadas para SERVICE_URL
e
MIRROR_SERVICE_URL
. Somente as respostas de SERVICE_URL
são enviadas de volta
ao cliente. MIRROR_SERVICE_URL
não tem impacto sobre o cliente.
Para configurar o espelhamento, siga estas etapas:
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique em Mapas de regra de roteamento.
Clique em
Criar mapa de regras de roteamento.Na página Criar um mapa de regras de roteamento, digite um Nome.
Na lista Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento atual.
Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
Em Correspondências de hosts e caminho, clique em
Adicionar correspondência de hosts e caminho. Isso adiciona uma nova correspondência de caminhos que pode ser configurada para espelhar o tráfego.Adicione as configurações a seguir ao campo Correspondência de caminhos:
- defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URL
DEFAULT_SERVICE_URL
é o URL padrão do serviço.BACKEND_SERVICE_URL
é o URL do back-end espelhado.BACKEND_SERVICE_MIRROR_URL
é o URL do serviço de back-end em que você espelha.
Clique em Concluído.
Clique em Salvar.
gcloud
Use o comando
gcloud export
para ver a configuração do mapa de URLs:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
Adicione a seção a seguir ao arquivo
review-url-map-config.yaml
:hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URL
DEFAULT_SERVICE_URL
é o URL padrão do serviço.BACKEND_SERVICE_URL
é o URL do back-end espelhado.BACKEND_SERVICE_MIRROR_URL
é o URL do serviço de back-end em que você espelha.
Atualize o mapa de URLs:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Configurar a quebra de circuito
A quebra de circuito permite definir limites de falha para impedir que as solicitações do cliente sobrecarreguem os back-ends. Depois que as solicitações atingem um limite que você definiu, o cliente para de permitir novas conexões ou o envio de outras solicitações, proporcionando tempo para os back-ends se recuperarem.
Como resultado, a quebra de circuitos evita falhas em cascata retornando um erro ao cliente em vez de sobrecarregar um back-end. Isso permite que pouco tráfego seja veiculado enquanto fornece tempo para gerenciar a situação de sobrecarga, como lidar com um pico de tráfego aumentando a capacidade com escalonamento automático.
No exemplo a seguir, você define os disjuntores desta maneira:
- Solicitações máximas por conexão: 100
- Número máximo de conexões: 1.000
- Máximo de solicitações pendentes: 200
- Máximo de solicitações: 1.000
- Máximo de novas tentativas: 3
Para configurar o disjuntor, siga estas etapas:
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique no nome do serviço de back-end que você quer atualizar.
Clique em
Editar.Clique em Configurações avançadas.
Em Disjuntores, marque a caixa de seleção Ativar.
Clique em
Editar.- Em Número máximo de solicitações por conexão, insira
100
. - Em Máximo de conexões, insira
1000
. - Em Máximo de solicitações pendentes, insira
200
. - Em Número máximo de solicitações, insira
1000
. - Em Máximo de tentativas, insira
3
.
- Em Número máximo de solicitações por conexão, insira
Clique em Salvar e, depois, em Salvar novamente.
gcloud
Execute o comando
gcloud export
para exportar a configuração do serviço de back-end. SubstituaBACKEND_SERVICE_NAME
pelo nome do serviço de back-end.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Atualize o arquivo
BACKEND_SERVICE_NAME
.yaml da seguinte maneira:affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME maxUtilization: 0.8 circuitBreakers: maxConnections: 1000 maxPendingRequests: 200 maxRequests: 1000 maxRequestsPerConnection: 100 maxRetries: 3 connectionDraining: drainingTimeoutSec: 300 healthChecks: - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: BACKEND_SERVICE_NAME port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30
Atualize o arquivo de configuração do serviço de back-end:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Configurar a afinidade de sessão com base em HTTP_COOKIE
O gerenciamento de tráfego avançado permite que você configure a afinidade de sessão com base em um cookie fornecido.
Para configurar a afinidade de sessão usando HTTP_COOKIE
, siga estas etapas:
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique no nome do serviço de back-end que você quer atualizar.
Clique em
Editar.Clique em Configurações avançadas.
Em Afinidade da sessão, selecione Cookie HTTP.
Em Política de balanceamento de carga local, selecione Anel de hash.
- No campo Nome do cookie HTTP, insira
http_cookie
. - No campo Caminho do cookie HTTP, insira
/cookie_path
. - No campo TTL do cookie HTTP, digite
100
. - No campo Tamanho mínimo do anel, insira
10000
.
- No campo Nome do cookie HTTP, insira
Clique em Save.
gcloud
Execute o comando
gcloud export
para exportar a configuração do serviço de back-end. SubstituaBACKEND_SERVICE_NAME
pelo nome do serviço de back-end.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Atualize o arquivo
YAML
da seguinte forma:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 30 minimumRingSize: 10000
Importe o arquivo de configuração do serviço de back-end:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Configurar a detecção de outliers
A detecção de outlier controla a remoção de hosts não íntegros do pool de balanceamento de carga. O Cloud Service Mesh faz isso usando um conjunto de políticas que especificar os critérios para a remoção de VMs ou endpoints de back-end não íntegros em NEGs, junto com os critérios que definem quando um back-end ou endpoint é considerado saudável o suficiente para receber o tráfego novamente.
No exemplo a seguir, o serviço de back-end tem um grupo de instâncias como
back-end. A configuração de detecção de outliers especifica que a análise de detecção
de outliers é executada a cada segundo. Se um endpoint retornar cinco erros 5xx
consecutivos, ele será removido da consideração de balanceamento de carga por 30 segundos pela
primeira vez. O tempo real de remoção do mesmo endpoint é de 30 segundos vezes o
número de vezes que ele é removido.
Para configurar a detecção de outliers no recurso do serviço de back-end, siga estas etapas.
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique no nome de um serviço.
Clique em
Editar.Clique em Configurações avançadas.
Marque a caixa de seleção Detecção de outliers.
Clique em
Editar.- Defina Erros consecutivos como
5
. - Defina Intervalo como
1000
milissegundos. - Defina o Tempo de expulsão base para
30000
milissegundos.
- Defina Erros consecutivos como
Clique em Salvar e, depois, em Salvar novamente.
gcloud
Execute o comando
gcloud export
para exportar a configuração do serviço de back-end. SubstituaBACKEND_SERVICE_NAME
pelo nome do serviço de back-end.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Atualize o arquivo
YAML
da seguinte maneira, substituindo o nome do serviço de back-end porBACKEND_SERVICE_NAME
:name: BACKEND_SERVICE_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP outlierDetection: consecutiveErrors: 5, interval: seconds: 1, nanos: 0 baseEjectionTime: seconds: 30, nanos: 0
Importe o arquivo de configuração do serviço de back-end:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Definir a política de balanceamento de carga de localidade
Usar a política de balanceamento de carga de localidade para escolher um algoritmo de balanceamento de carga com base no peso da localidade e na prioridade fornecida pelo Cloud Service Mesh. Por exemplo, é possível executar um round-robin ponderado entre endpoints íntegros ou gerar hash consistente.
No exemplo a seguir, o serviço de back-end tem um grupo de instâncias como
back-end. A política de balanceamento de carga da localidade está definida como RING_HASH
.
Para definir a política de balanceamento de carga de localidade, siga estas etapas:
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique no nome de um serviço.
Clique em
Editar.Clique em Configurações avançadas.
Em Política de tráfego, no menu Política de balanceamento de carga de localidade, selecione Anel de hash.
Clique em Save.
gcloud
Execute o comando
gcloud export
para exportar a configuração do serviço de back-end. SubstituaBACKEND_SERVICE_NAME
pelo nome do serviço de back-end.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Atualize o arquivo
BACKEND_SERVICE_NAME
.yaml da seguinte maneira:name: shopping-cart-service loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP localityLbPolicy: RING_HASH
Importe o arquivo de configuração do serviço de back-end:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Para mais informações sobre como funciona a política de balanceamento de carga de localidade, consulte a documentação do recurso backendService.
Configurar o redirecionamento de URL
Os pressupostos destas instruções são os seguintes:
- Sua implantação do Cloud Service Mesh tem um mapa de URLs chamado
review-url-map
. - O mapa de URLs envia todo o tráfego para um serviço de back-end, chamado
review1
, que serve como serviço de back-end padrão. - Você quer redirecionar o tráfego de um host para outro.
Para configurar o redirecionamento de URL, siga estas etapas:
Console
No console do Google Cloud, acesse a página Cloud Service Mesh.
Clique em Mapas de regra de roteamento.
Clique em
Criar mapa de regras de roteamento.Na página Criar um mapa de regras de roteamento, digite um Nome.
No menu Protocolo, selecione HTTP.
Selecione uma regra de encaminhamento atual.
Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
Em Correspondências de hosts e caminho, clique em
Adicionar correspondência de hosts e caminho. Isso adiciona uma nova correspondência de caminho que redireciona o tráfego.Adicione as configurações a seguir ao campo Correspondência de caminhos:
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True
Clique em Concluído.
Clique em Salvar.
gcloud
Use o comando
gcloud export
para ver a configuração do mapa de URLs:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
Adicione a seção a seguir ao arquivo
review-url-map-config.yaml
:hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True
Atualize o mapa de URLs:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Configurar o direcionamento de tráfego com a substituição de URL
O direcionamento de tráfego possibilita direcionar o tráfego para diferentes serviços de back-end com base nos atributos da solicitação, como valores de cabeçalho. Além disso, é possível configurar ações como reescrever o URL na solicitação antes que ela seja direcionada para o serviço de back-end.
No exemplo a seguir, a solicitação será direcionada para SERVICE_ANDROID_URL
se
o caminho da solicitação estiver prefixado com /mobile/
e o User-Agent
da solicitação
contiver Android
. Antes de enviar a solicitação ao serviço de back-end, o prefixo de
URL pode ser alterado para REWRITE_PATH_ANDROID
, por exemplo, /android/
. No entanto,
se o caminho for prefixado com /mobile/
e tiver uma User-Agent
contendo
iPhone
, o tráfego será direcionado para SERVICE_IPHONE_URL
e o prefixo do URL
será alterado para REWRITE_PATH_IPHONE
Todas as outras solicitações prefixadas com
/mobile/
que tiverem um User-Agent
com um valor diferente de Android ou iPhone serão
direcionadas a SERVICE_GENERIC_DEVICE_URL
.
pathMatchers: - defaultService: [DEFAULT_SERVICE_URL] name: matcher1 routeRules: - matchRules: - prefixMatch: /mobile/ headerMatches: - headerName: User-Agent regexMatch: .*Android.* service: $[SERVICE_ANDROID_URL] routeAction: urlRewrite: pathPrefixRewrite: [REWRITE_PATH_ANDROID] - matchRules: - prefixMatch: /mobile/ headerMatches: - headerName: User-Agent regexMatch: .*iPhone.* service: [SERVICE_IPHONE_URL] routeAction: urlRewrite: pathPrefixRewrite: [REWRITE_PATH_IPHONE] - matchRules: - prefixMatch: /mobile/ service: [SERVICE_GENERIC_DEVICE_URL]
Configurar a injeção de falhas
A injeção da falha permite injetar um atraso fixo e/ou uma parada forçada, chamada de cancelamento, em uma rota específica para testar a resiliência de um aplicativo.
No exemplo a seguir, todas as solicitações são enviadas para SERVICE_URL
, com um
tempo de atraso fixo de 10 segundos adicionado a 100% das solicitações. O cliente que está enviando as
solicitações vê que todas as respostas têm um atraso de 10 segundos. Além disso, uma falha de
parada com uma resposta Service Unavailable
503 é aplicada a 50% das
solicitações. O cliente vê que 50% das solicitações recebem uma resposta 503.
Essas solicitações não atingem o serviço de back-end.
pathMatchers: - defaultService: [DEFAULT_SERVICE_URL] name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: [SERVICE_URL] weight: 100 faultInjectionPolicy: delay: fixedDelay: seconds: 10 nanos: 0 percentage: 100 abort: httpStatus: 503 percentage: 50
Como configurar a filtragem de configuração com base na correspondência de MetadataFilters
MetadataFilters
estão ativados com regras de encaminhamento e HttpRouteRuleMatch
.
Use esse recurso para controlar uma regra de encaminhamento ou de rota específica para que
o plano de controle envie a regra de encaminhamento ou de rota apenas para proxies em que
os metadados do nó correspondem à configuração de filtro de metadados. Se você não especificar nenhum
MetadataFilters
, a regra será enviada para todos os proxies Envoy.
Esse recurso facilita a operação de uma implantação organizada de uma configuração.
Por exemplo, crie uma regra de encaminhamento chamada forwarding-rule1
, que você quer
enviar somente para o Envoys cujos metadados de nó contenham app: review
e
version: canary
.
Para adicionar MetadataFilters
a uma regra de encaminhamento, siga estas etapas:
gcloud
Use o comando
gcloud export
para conseguir a configuração da regra de encaminhamento.gcloud compute forwarding-rules export forwarding-rule1 \ --destination=forwarding-rule1-config.yaml \ --global
Exclua a regra de encaminhamento:
gcloud compute forwarding-rules delete forwarding-rule1 \ --global
Atualize o arquivo
forwarding-rule1-config.yaml
.No exemplo a seguir, criamos um filtro de metadados
MATCH_ALL
:metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'
No exemplo a seguir, criamos um filtro de metadados
MATCH_ANY
:metadataFilters: - filterMatchCriteria: 'MATCH_ANY' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'production'
Remova todos os campos somente saída do arquivo
forwarding-rule1-config.yaml
. Para mais informações, consulte a documentação degcloud compute forwarding-rules import
.Use o comando
gcloud import
para atualizar o arquivoforwarding-rule1-config.yaml
.gcloud compute forwarding-rules import forwarding-rule1 \ --source=forwarding-rule1-config.yaml \ --global
Use estas instruções para adicionar metadados de nó ao Envoy antes de iniciar o Envoy. Apenas um valor de string é aceito.
a. Para uma implantação baseada em VM, em
bootstrap_template.yaml
, adicione o seguinte na seçãometadata
:app: 'review' version: 'canary'
b. Para uma implantação baseada no Google Kubernetes Engine ou no Kubernetes, em
trafficdirector_istio_sidecar.yaml
, adicione o seguinte na seçãoenv
:- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
Exemplos de filtragem de metadados
Use as instruções a seguir para um cenário em que vários projetos estão na mesma rede VPC compartilhada e você quer que o serviço Os recursos do Cloud Service Mesh ficam visíveis para os proxies no mesmo projeto.
A configuração da VPC compartilhada é a seguinte:
- Nome do projeto de host:
vpc-host-project
- Projetos de serviço:
project1
,project2
- Serviços de back-end com instâncias ou endpoints de back-end que executam um proxy compatível
com xDS em
project1
eproject2
.
Para configurar o Cloud Service Mesh para isolar project1
, siga estas etapas:
gcloud
Crie todas as regras de encaminhamento em
project1
com o filtro de metadados a seguir:metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels - name: 'project_name' value: 'project1' - name: 'version' value: 'production'
Ao configurar os proxies implantados em instâncias ou endpoints em
project1
, inclua os metadados a seguir na seção de metadados do nó do arquivo de inicialização:project_name: 'project1' version: 'production'
Verifique se os proxies já implantados em
project2
não receberam a regra de encaminhamento criada na primeira etapa. Para fazer isso, tente acessar serviços emproject1
de um sistema que executa um proxy emproject2
. Para informações sobre como verificar se uma configuração do Cloud Service Mesh funcionando corretamente, consulte Como verificar a configuração.
Para testar uma nova configuração em um subconjunto de proxies antes de disponibilizá-la para todos os proxies, siga estas etapas:
gcloud
Inicie os proxies que você está usando para testar com os metadados de nó a seguir. Não inclua esses metadados de nó para proxies que você não está usando para teste.
version: 'test'
Para cada nova regra de encaminhamento que você quer testar, inclua o filtro de metadados a seguir:
metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'version' value: 'test'
Teste a nova configuração enviando tráfego para os proxies de teste e faça as alterações necessárias. Se a nova configuração estiver funcionando corretamente, somente os proxies que você testar receberão a nova configuração. Os proxies restantes não recebem a nova configuração e não podem usá-la.
Quando você confirmar que a nova configuração funciona corretamente, remova o filtro de metadados associado a ela. Isso permite que todos os proxies recebam a nova configuração.
Solução de problemas
Use estas informações para solucionar problemas quando o tráfego não estiver sendo roteado de acordo com as regras de roteamento e as políticas de tráfego que você tiver configurado.
Sintomas:
- Aumento do tráfego para serviços em regras acima da regra em questão.
- Aumento inesperado nas respostas HTTP
4xx
e5xx
de uma determinada regra de rota.
Solução: como as regras de rota são interpretadas em ordem de prioridade, revise a prioridade atribuída a cada regra.
Ao definir regras de rota, verifique se as regras com maior prioridade (ou seja, com números de prioridade mais baixa) não encaminham inadvertidamente o tráfego que, de outra forma, seria roteado por outra regra de rota. Veja o exemplo a seguir.
Primeira regra de rota
- Caminho de correspondência da regra de rota =
/shopping/
- Ação de redirecionamento: enviar tráfego para o serviço de back-end
service-1
- Prioridade da regra:
4
- Caminho de correspondência da regra de rota =
Segunda regra de rota
- regexMatch da correspondência de regra de rota =
/shopping/cart/ordering/.*
- Ação de redirecionamento: enviar tráfego para o serviço de back-end
service-2
- Prioridade da regra:
8
- regexMatch da correspondência de regra de rota =
Nesse caso, uma solicitação com o caminho /shopping/cart/ordering/cart.html
é roteada para service-1
. Mesmo que a segunda regra tenha correspondência, ela é
ignorada porque a primeira regra tinha prioridade.
Bloquear tráfego entre os serviços
Caso você queira bloquear o tráfego entre os Serviços A e B, e a implantação estiver no GKE, configure a segurança do serviço e use uma política de autorização para bloquear o tráfego entre eles. Para instruções completas, consulte Segurança do serviço do Cloud Service Mesh e as instruções de configuração com o Envoy e o gRPC sem proxy.
A seguir
- Para ajudar você a resolver problemas de configuração do Cloud Service Mesh, consulte Solução de problemas de implantações que usam o Envoy.