Opções de configuração de VMs do Compute Engine com implementação automática do Envoy

Nota: este guia só suporta a Cloud Service Mesh com Google Cloud APIs e não suporta as APIs Istio. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Este guia fornece informações sobre opções e tarefas adicionais para a implementação automatizada do Envoy.

Opções de criação de modelos de instância adicionais

Quando cria um modelo de instância para a implementação automatizada do proxy Envoy, pode usar os seguintes parâmetros para definir alguns aspetos da implementação e o comportamento dos proxies.

Parâmetro	Valor e descrição	Obrigatório ou opcional
--service-proxy	enabled Controla se o proxy de serviço e o agente estão instalados e configurados na VM.	Obrigatório se quiser implementar e configurar automaticamente o proxy de serviço. Se omitir esta definição, o proxy de serviço não é instalado nem configurado.
--service-proxy:serving-ports	Uma lista de portas separadas por pontos e vírgulas. As portas nas quais a sua aplicação/carga de trabalho está a servir. O proxy de serviço interceta o tráfego de entrada e, em seguida, encaminha-o para as portas de publicação especificadas no localhost.	Opcional Se omitir esta flag, o proxy de serviço apenas processa o tráfego de saída da sua carga de trabalho. O tráfego de entrada não é processado pelo proxy de serviço.
--service-proxy:proxy-port	Uma única porta. A porta na qual o proxy de serviço é responsável pela deteção. A VM interceta o tráfego e redireciona-o para esta porta para processamento pelo proxy de serviço.	Opcional. Se omitir esta flag, o valor é predefinido como 15001
--service-proxy:network	O nome de uma rede de VPC válida. A Google Cloud rede VPC usada pelo plano de controlo do proxy de serviço para gerar a configuração dinâmica do proxy de serviço.	Obrigatório se a VM estiver em mais do que uma rede; caso contrário, é opcional. Se omitir esta flag, é usado o valor especificado através do parâmetro --network durante a criação do modelo de instância de VM.
--service-proxy:tracing	ON ou OFF Permite que o proxy de serviço gere informações de rastreio distribuído. Se estiver definido como ON, o plano de controlo do proxy de serviço gera uma configuração que permite a monitorização baseada no ID do pedido. Para mais informações, consulte a documentação do generate_request_id proxy Envoy.	Opcional. Se omitir esta flag, o rastreio não é ativado.
--service-proxy:access-log	O caminho do ficheiro para os registos de acesso enviados para o proxy de serviço pelo plano de controlo. Todos os pedidos recebidos e enviados são registados neste ficheiro. Para mais informações, consulte a documentação do registo de acesso a ficheiros para o proxy Envoy.	Opcional. Não existe um valor predefinido. Se não especificar o caminho do ficheiro, os registos não são criados.
--service-proxy:intercept-all-outbound-traffic (Pré-visualização)	Permite a interceção de todo o tráfego de saída pelo proxy de serviço e, em seguida, o redirecionamento para um anfitrião externo. Use gcloud beta com esta opção.	Opcional.
--service-proxy:exclude-outbound-ip-ranges (Pré-visualização)	Uma lista separada por ponto e vírgula (;) dos endereços IP ou intervalos CIDR, especificados entre aspas ("), que devem ser excluídos do redirecionamento. Aplica-se apenas quando a flag intercept-all-outbound-traffic está definida. Use gcloud beta com esta opção. Por exemplo: exclude-outbound-ip-ranges="8.8.8.8;129.168.10.0/24"	Opcional.
--service-proxy:exclude-outbound-port-ranges (Pré-visualização)	Uma lista separada por pontos e vírgulas (;) das portas ou dos intervalos de portas, especificados entre aspas ("), que devem ser excluídos do redirecionamento. Aplica-se apenas quando a flag intercept-all-outbound-traffic está definida. Use gcloud beta com esta opção. Por exemplo: exclude-outbound-port-ranges="81;8080-8090"	Opcional.
--service-proxy:scope (Pré-visualização)	A opção scope define um limite de configuração lógico para o recurso Gateway. Quando uma VM é iniciada, o proxy de serviço comunica com a Cloud Service Mesh para obter as informações de encaminhamento correspondentes às rotas anexadas ao gateway com este nome de âmbito. Quando scope é especificado, o valor da rede é ignorado. Não pode especificar valores de scope e mesh em simultâneo. Use gcloud beta com esta opção.	Opcional.
--service-proxy:mesh (Pré-visualização)	A opção mesh define um limite de configuração lógico para um recurso Mesh. Quando uma VM é iniciada, o proxy de serviço comunica com a Cloud Service Mesh para obter as informações de encaminhamento correspondentes às rotas anexadas ao Mesh com este nome da malha. Quando mesh é especificado, o valor da rede é ignorado. Não pode especificar valores de scope e mesh em simultâneo. Use gcloud beta com esta opção	Opcional.
--service-proxy:project-number (Pré-visualização)	A opção project-number especifica o projeto onde os recursos Mesh e Gateway são criados. Se não for especificado, é usado o projeto onde a instância existe. Isto aplica-se apenas às novas APIs de encaminhamento de serviços.	Opcional.
--service-proxy-labels	Pares de chaves-valores no formato key=value. Etiquetas que pode aplicar ao seu proxy de serviço. Estes são refletidos nos metadados de arranque do seu proxy Envoy. As etiquetas podem ser quaisquer pares key=value que queira definir como metadados de proxy (por exemplo, para utilização com a filtragem de configuração). Pode usar estas flags para etiquetas de aplicações e versões, por exemplo, app=review ou version=canary. Também pode usá-los em conjunto.	Opcional.

Por exemplo, o seguinte comando gcloud cria um modelo de instância denominado proxy-it. As instâncias criadas a partir deste modelo têm o proxy Envoy e o agente de proxy de serviço instalados.

gcloud compute instance-templates create proxy-it \
    --service-proxy enabled

No exemplo seguinte, o modelo de instância chama-se proxy-it, o proxy Envoy e o agente de proxy de serviço estão instalados, a porta de publicação e a porta de proxy estão definidas, o rastreio está ativado e é definida uma etiqueta.

gcloud compute instance-templates create proxy-it \
  --service-proxy enabled,serving-ports=8080,proxy-port=15001,tracing=ON \
  --service-proxy-labels version=canary

O diagrama seguinte ilustra o fluxo de tráfego quando especifica a porta de publicação como 8080. As ligações TCP de entrada à porta 8080 são intercetadas pelo iptables e redirecionadas para o proxy Envoy, que as passa para a aplicação na sua VM a ouvir na porta TCP 8080. Além disso:

• Todas as ligações de saída aos VIPs de serviços configurados na Cloud Service Mesh são intercetadas pelo iptables, que configura o netfilter. O Netfilter garante que o tráfego correspondente que atravessa a pilha de rede é intercetado e redirecionado para o proxy Envoy. Em seguida, o tráfego é equilibrado com base na forma como configurou o Cloud Service Mesh.
• Todas as outras ligações de entrada não são intercetadas pelo iptables e são transmitidas diretamente aos serviços na VM.
• Todas as ligações a pontos finais externos são transmitidas diretamente a endereços IP externos sem serem intercetadas.
• Todo o tráfego UDP é transmitido diretamente para o destino sem ser intercetado pelo iptables.

Isto é ilustrado no diagrama seguinte.

Distribuição de tráfego com a malha de serviços na nuvem (clique para aumentar)

Os fluxos de tráfego no diagrama são os seguintes:

1. Tráfego de entrada com a porta de destino 80, não intercetado nem encaminhado diretamente para o serviço que está a escutar na porta.
2. Tráfego de entrada com porta de destino 8080, intercetado e redirecionado para a porta do ouvinte do Envoy.
3. O Envoy encaminha o tráfego de (2) para o serviço 2 que está a ouvir na porta localhost 8080.
4. O tráfego de saída destinado ao VIP e à porta da regra de encaminhamento da Cloud Service Mesh é intercetado e redirecionado para a porta do ouvinte do Envoy.
5. O Envoy encaminha o tráfego de (4) para o ponto final do back-end do serviço de back-end do Cloud Service Mesh de destino.
6. Tráfego de saída destinado a VIPs e portas não pertencentes ao Cloud Service Mesh, não intercetado e encaminhado diretamente para o serviço externo.

Usar etiquetas

Se quiser especificar etiquetas para usar com a filtragem de metadados do Cloud Service Mesh ou ativar o registo de acesso para os proxies Envoy, use os parâmetros --service-proxy-labels ou --service-proxy access-log.

Por exemplo:

gcloud compute instance-templates create td-vm-template-auto \
   --service-proxy enabled,access-log=/var/log/envoy/access.log,network=default \
   --service-proxy-labels myapp=review,version=canary

O proxy Envoy pode intercetar as portas de verificação de funcionamento dos serviços nas VMs. Se o fizer, as sondas de verificação de saúde comunicam a sua aplicação e os proxies do Envoy. O tráfego não é direcionado para a VM se o proxy Envoy não estiver a ser executado corretamente. Por exemplo:

gcloud compute instance-templates create td-vm-template-auto \
  --service-proxy=enabled,serving-ports="80;8080"

Usar o processo de atualização do grupo de instâncias gerido

Se usou o processo automático para configurar os proxies Envoy, pode usar o processo de atualização do grupo de instâncias gerido para atualizar o grupo de instâncias gerido. Use este processo para:

• Adicione os componentes do proxy de serviço a um grupo de instâncias gerido existente e inscreva-o numa rede da Cloud Service Mesh.
• Atualize os componentes do proxy de serviço nas VMs.

Antes de fazer a atualização contínua, faça o seguinte.

1. Defina o drenagem de ligações no serviço de back-end para um valor de, pelo menos, 30 segundos.
2. Use o parâmetro --min-ready, definido para um valor de 3 minutos ou mais, quando chamar o atualizador. O parâmetro --min-ready faz com que o grupo de instâncias geridas aguarde após a atualização de uma VM antes de avançar para a atualização da VM seguinte. Sem esta configuração, a VM recém-criada não tem tempo para arrancar totalmente o Envoy e o agente do proxy de serviço, e a atualização prossegue demasiado rapidamente.

Para fazer a atualização contínua no grupo de instâncias gerido, siga estes passos.

1. Crie um novo modelo de instância, conforme descrito acima, com as informações do proxy de serviço. Pode usar a versão original do modelo de instância para a atualização se contiver as informações do proxy de serviço e o seu objetivo for atualizar para a versão estável mais recente do software de proxy.
2. Faça uma atualização contínua do grupo de instâncias geridas. Certifique-se de que define REPLACE como a ação mínima que o atualizador tem de realizar. O grupo de instâncias instala a versão mais recente do software de proxy e configura-o conforme especificado no modelo de instância.

Também pode remover os componentes do proxy de serviço de um grupo de instâncias gerido através do processo de atualização:

1. Crie um novo modelo de instância sem especificar a flag --service-proxy.

2. Faça uma atualização contínua através do processo de atualização do grupo de instâncias gerido.

Esta ação remove o proxy Envoy das suas VMs. Se esse grupo de instâncias gerido foi o único MIG anexado ao serviço de back-end, é recomendável remover a configuração do Cloud Service Mesh que criou quando configurou o Cloud Service Mesh.