O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Opções de configuração da VM do Compute Engine com implantação automática do Envoy

Neste guia, fornecemos informações sobre outras opções e tarefas para implantação automatizada do Envoy.

Outras opções de criação de modelo de instância

Ao criar um modelo de instância para implantação automatizada de proxy do Envoy, é possível usar os parâmetros a seguir para definir alguns aspectos da implantação e o comportamento dos proxies.

Parâmetro	Valor e descrição	Obrigatório ou opcional
`--service-proxy`	`enabled` Controla se o proxy e o agente de serviço estão instalados e configurados na VM.	Obrigatório se você quiser implantar e configurar automaticamente o proxy de serviço. Se você omitir essa configuração, o proxy de serviço não será instalado ou configurado.
`--service-proxy:serving-ports`	Uma lista de portas separadas por ponto e vírgula. As portas em que seu aplicativo/carga de trabalho é exibido. O proxy de serviço intercepta o tráfego de entrada e o encaminha para as portas de exibição especificadas no localhost.	Opcional Se você omitir essa sinalização, o proxy de serviço processará apenas 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 em que o proxy de serviço escuta. A VM intercepta o tráfego e o redireciona para essa porta para processamento pelo proxy de serviço.	Opcional. Se você omitir essa sinalização, o valor padrão será `15001`.
`--service-proxy:network`	O nome de uma rede VPC válida. A rede VPC do Google Cloud usada pelo plano de controle 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 de uma rede. Caso contrário, é opcional. Se você omitir essa sinalização, o valor especificado usando o parâmetro `--network` durante a criação do modelo de instância de VM será usado.
`--service-proxy:tracing`	`ON` ou `OFF` Permite que o proxy de serviço gere informações de rastreamento distribuídas. Se definido como `ON`, o plano de controle do proxy de serviço gera uma configuração que permite o rastreamento baseado em ID de solicitação. Para mais informações, consulte a documentação `generate_request_id` do proxy do Envoy.	Opcional. Se você omitir essa sinalização, o rastreamento não será ativado.
`--service-proxy:access-log`	O caminho do arquivo dos registros de acesso enviados ao proxy de serviço pelo plano de controle. Todas as solicitações recebidas e enviadas são registradas nesse arquivo. Para mais informações, consulte a documentação Registro de acesso a arquivos para o proxy do Envoy.	Opcional. Não há valor padrão. Se você não especificar o caminho do arquivo, os registros não serão criados.
`--service-proxy:intercept-all-outbound-traffic` (Visualização prévia)	Ativa a interceptação de todo o tráfego de saída pelo proxy de serviço e, em seguida, redireciona para um host externo. Use `gcloud beta` com esta opção.	Opcional.
`--service-proxy:exclude-outbound-ip-ranges` (Visualização prévia)	Uma lista separada por ponto e vírgula (;) de endereços IP ou intervalos CIDR, especificados entre aspas ("), que devem ser excluídos do redirecionamento. Só se aplica quando a sinalização `intercept-all-outbound-traffic` é 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` (Visualização prévia)	Uma lista separada por ponto e vírgula (;) de portas ou intervalos de portas, especificada entre aspas ("), que precisa ser excluída do redirecionamento. Só se aplica quando a sinalização `intercept-all-outbound-traffic` é definida. Use `gcloud beta` com esta opção. Por exemplo: `exclude-outbound-port-ranges="81;8080-8090"`	Opcional.
`--service-proxy:scope` (Visualização prévia)	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 se comunica com o Cloud Service Mesh para recuperar as informações de roteamento correspondentes às rotas anexadas ao gateway com esse nome de escopo. Quando `scope` é especificado, o valor da rede é ignorado. Não é possível especificar os valores `scope` e `mesh` ao mesmo tempo. Use `gcloud beta` com esta opção.	Opcional.
`--service-proxy:mesh` (Visualização prévia)	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 se comunica com o Cloud Service Mesh para recuperar as informações de roteamento correspondentes às rotas anexadas ao `Mesh` com esse nome de malha. Quando `mesh` é especificado, o valor da rede é ignorado. Não é possível especificar os valores `scope` e `mesh` ao mesmo tempo. Use `gcloud beta` com esta opção	Opcional.
`--service-proxy:project-number` (Visualização prévia)	A opção `project-number` especifica o projeto em que os recursos `Mesh` e `Gateway` são criados. Se não for especificado, o projeto em que a instância existe será usado. Isso é aplicável apenas às novas APIs de roteamento de serviço.	Opcional.
`--service-proxy-labels`	Pares de chave-valor no formato `key=value`. Rótulos que podem ser aplicados ao seu proxy de serviço. Isso é refletido nos metadados de inicialização do proxy do Envoy. Os rótulos podem ser qualquer par de `key=value` que você queira definir como metadados de proxy (por exemplo, para uso com filtragem de configuração). Você pode usar essas sinalizações para rótulos de aplicativo e versão, por exemplo, `app=review` ou `version=canary`. Também é possível usá-los juntos.	Opcional.

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

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

No exemplo a seguir, o modelo de instância é chamado proxy-it, o proxy Envoy e o agente de serviço do proxy estão instalados, a porta de exibição e a porta de proxy estão definidas, o rastreamento está ativado e um rótulo é definido.

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 a seguir ilustra o fluxo de tráfego quando você especifica a porta de exibição como 8080. As conexões TCP de entrada para a porta 8080 são interceptadas pelo iptables e redirecionadas para o proxy do Envoy, que as passa para o aplicativo na VM que escuta na porta TCP 8080. Além disso:

Todas as conexões de saída para os VIPs de serviços configurados no Cloud Service Mesh são interceptadas pelo iptables, que configura o netfilter. O Netfilter garante que o tráfego correspondente que passa pela pilha de rede seja interceptado e redirecionado para o proxy do Envoy. O tráfego é balanceado com base na configuração do Cloud Service Mesh.
Todas as outras conexões de entrada não são interceptadas pelo iptables e são transmitidas diretamente a serviços na VM.
Todas as conexões com endpoints externos são transmitidas diretamente aos endereços IP externos sem serem interceptadas.
Todo o tráfego UDP é transmitido diretamente para o destino sem ser interceptado pelo iptables.

Isso é ilustrado no diagrama a seguir.

Distribuição de tráfego com a Cloud Service Mesh (clique para ampliar)

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

Tráfego de entrada com a porta de destino 80, não interceptado e roteado diretamente para o serviço que escuta na porta.
Tráfego de entrada com a porta de destino 8080, interceptada e redirecionada para a porta do listener Envoy.
O Envoy encaminha o tráfego de (2) para o serviço 2 que escuta na porta localhost 8080.
Tráfego de saída destinado à porta e VIP da regra de encaminhamento do Cloud Service Mesh, interceptado e redirecionado para a porta do listener do Envoy.
O Envoy encaminha o tráfego de (4) para o endpoint do back-end do destino serviço de back-end do Cloud Service Mesh.
Tráfego de saída destinado a portas e VIPs que não sejam do Cloud Service Mesh, e não interceptados e roteados diretamente para serviços externos.

Como usar marcadores

Se você quiser especificar rótulos para usar com a filtragem de metadados do Cloud Service Mesh ou ativar a geração de registros de acesso para os proxies do Envoy, use os parâmetros --service-proxy-labels ou --service-proxy access-log.

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 do Envoy pode interceptar as portas de verificação de integridade dos serviços nas VMs. Se você fizer isso, as sondagens de verificação de integridade serão relatadas no seu aplicativo e nos proxies do Envoy. O tráfego não será direcionado para a VM se o proxy do Envoy não estiver sendo executado corretamente. Por exemplo:

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

Como usar o processo de atualização do grupo de instâncias gerenciadas

Se você usou o processo automatizado para configurar os proxies do Envoy, é possível usar o processo de atualização de grupo de instâncias gerenciadas para atualizar seu grupo de instâncias gerenciadas. Use esse processo para:

Adicione os componentes do proxy de serviço a um grupo de instâncias gerenciadas atual e inscreva-o em uma rede do Cloud Service Mesh.
Atualize os componentes do proxy de serviço nas VMs.

Antes de executar a atualização gradual, faça o seguinte.

Defina a diminuição de conexão no serviço de back-end como um valor de pelo menos 30 segundos.
Use o parâmetro --min-ready, definido como um valor de três minutos ou mais, quando chamar o atualizador. O parâmetro --min-ready faz o grupo de instâncias gerenciadas aguardar após a atualização de uma VM para prosseguir com a atualização da próxima. Sem isso, a VM recém-criada não tem tempo para inicializar completamente o Envoy e o agente proxy de serviço, e a atualização continua muito rapidamente.

Para executar a atualização gradual no grupo de instâncias gerenciadas, siga estas etapas.

Crie um novo modelo de instância, conforme descrito acima, com as informações do proxy de serviço. A versão original do modelo de instância pode ser usada para atualização se contiver as informações de proxy de serviço e seu objetivo é atualizar para a versão estável mais recente do software proxy.
Execute uma atualização contínua do grupo de instâncias gerenciadas. Defina REPLACE como a ação mínima que o Updater precisa executar. O grupo de instâncias instala a versão mais recente do software proxy e a configura conforme especificado no modelo de instância.

Também é possível remover os componentes de proxy de serviço de um grupo de instâncias gerenciadas usando o processo de atualização:

Crie um novo modelo de instância sem especificar a sinalização --service-proxy.
Execute uma atualização gradual usando o processo de atualização do grupo de instâncias gerenciadas.

Isso remove o proxy do Envoy das VMs. Se esse grupo de instâncias gerenciadas era o único MIG anexado ao serviço de back-end, convém remover a configuração do Cloud Service Mesh criada durante a configuração.