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)
Distribuição de tráfego com a Cloud Service Mesh (clique para ampliar)

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

  1. Tráfego de entrada com a porta de destino 80, não interceptado e roteado diretamente para o serviço que escuta na porta.
  2. Tráfego de entrada com a porta de destino 8080, interceptada e redirecionada para a porta do listener Envoy.
  3. O Envoy encaminha o tráfego de (2) para o serviço 2 que escuta na porta localhost 8080.
  4. 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.
  5. 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.
  6. 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.

  1. Defina a diminuição de conexão no serviço de back-end como um valor de pelo menos 30 segundos.
  2. 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.

  1. 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.
  2. 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:

  1. Crie um novo modelo de instância sem especificar a sinalização --service-proxy.

  2. 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.