Atualizações de configuração para modernização

Este documento descreve as atualizações de configuração que talvez você precise fazer no Cloud Service Mesh gerenciado antes de modernizar a malha para o plano de controle TRAFFIC_DIRECTOR do plano de controle ISTIOD.

Para mais informações sobre o fluxo de trabalho de modernização, consulte a página Modernização do plano de controle gerenciado.

Migrar de chaves secretas do Istio para multicluster_mode

Não há suporte para secrets de vários clusters quando um cluster está usando o plano de controle TRAFFIC_DIRECTOR. Este documento descreve como modernizar o uso de segredos de vários clusters do Istio para o uso de multicluster_mode.

Visão geral das chaves secretas do Istio e das APIs declarativas

A descoberta de endpoints de multicluster do Istio de código aberto funciona usando istioctl ou outras ferramentas para criar um secreto do Kubernetes em um cluster. Esse segredo permite que um cluster balanceie o tráfego para outro cluster na malha. O plano de controle ISTIOD lê esse secret e começa a encaminhar o tráfego para esse outro cluster.

O Cloud Service Mesh tem uma API declarativa para controlar o tráfego de vários clusters em vez de criar segredos do Istio diretamente. Essa API considera os segredos do Istio como um detalhe de implementação e é mais confiável do que a criação manual de segredos do Istio. Os recursos futuros do Cloud Service Mesh vão depender da API declarativa, e não será possível usar esses novos recursos com segredos do Istio diretamente. A API declarativa é o único caminho recomendado.

Se você estiver usando o Istio Secrets, migre para a API declarativa o mais rápido possível. A configuração multicluster_mode direciona cada cluster para direcionar o tráfego a todos os outros clusters na malha. O uso de segredos permite uma configuração mais flexível, permitindo que você configure para cada cluster qual outro cluster ele deve direcionar o tráfego na malha. Para uma lista completa das diferenças entre os recursos compatíveis da API declarativa e os segredos do Istio, consulte Recursos compatíveis com as APIs do Istio.

Migrar de chaves secretas do Istio para a API declarativa

Se você provisionou o Cloud Service Mesh usando o gerenciamento automático com a API de recursos da frota, não precisa seguir estas instruções. Estas etapas só se aplicam se você fez a integração usando asmcli --managed.

Esse processo muda os segredos que apontam para um cluster. Durante esse processo, os endpoints são removidos e adicionados novamente. Entre os endpoints que estão sendo removidos e adicionados, o tráfego vai reverter brevemente para o roteamento local em vez de balanceamento de carga para outros clusters. Para mais informações, consulte o problema do GitHub.

Para mudar do uso de segredos do Istio para a API declarativa, siga estas etapas. Siga estas etapas ao mesmo tempo ou em sucessão:

Ative a API declarativa para cada cluster na frota em que você quer ativar a descoberta de endpoints de vários clusters definindo multicluster_mode=connected. É necessário definir explicitamente multicluster_mode=disconnected se você não quiser que o cluster seja detectável.

Use o comando a seguir para ativar um cluster para a descoberta de endpoints de vários clusters:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Use o comando a seguir para desativar a descoberta de endpoints em um cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Exclua secrets antigos.

Depois de definir multicluster_mode=connected nos clusters, cada cluster terá um novo segredo gerado para todos os outros clusters que também tiverem multicluster_mode=connected definido. O secret é colocado no namespace istio-system e tem o seguinte formato:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Cada segredo também terá o rótulo istio.io/owned-by: mesh.googleapis.com.

Depois que os novos secrets forem criados, você poderá excluir os criados manualmente com istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Após a migração, verifique as métricas de solicitação para garantir que elas sejam roteadas corretamente.