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

Este documento descreve as atualizações de configuração que pode ter de fazer à sua malha de serviços na nuvem gerida antes de modernizar a malha para o plano de controlo TRAFFIC_DIRECTOR a partir do plano de controlo ISTIOD.

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

Migre de segredos do Istio para multicluster_mode

Os segredos de vários clusters não são suportados quando um cluster está a usar o plano de controlo TRAFFIC_DIRECTOR. Este documento descreve como pode modernizar a utilização de segredos de vários clusters do Istio para a utilização de multicluster_mode.

Vista geral da API declarativa versus segredos do Istio

A descoberta de pontos finais multi-cluster istio de código aberto funciona através da utilização de istioctl ou outras ferramentas para criar um segredo do Kubernetes num cluster. Este segredo permite que um cluster equilibre a carga do tráfego para outro cluster na malha. Em seguida, o plano de controlo ISTIOD lê este segredo 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 diretamente segredos do Istio. Esta API trata os segredos do Istio como um detalhe de implementação e é mais fiável do que criar segredos do Istio manualmente. As funcionalidades futuras da Cloud Service Mesh vão depender da API declarativa, e não vai poder usar essas novas funcionalidades diretamente com os segredos do Istio. A API declarativa é o único caminho suportado.

Se estiver a usar segredos do Istio, migre para a API declarativa assim que possível. Tenha em atenção que a definição multicluster_mode direciona cada cluster para direcionar o tráfego para todos os outros clusters na malha. A utilização de segredos permite uma configuração mais flexível, o que lhe permite configurar para cada cluster para que outro cluster deve direcionar o tráfego na malha. Para ver uma lista completa das diferenças entre as funcionalidades suportadas da API declarativa e os segredos do Istio, consulte o artigo Funcionalidades suportadas através das APIs Istio.

Migre de segredos do Istio para a API declarativa

Se aprovisionou a malha de serviços na nuvem através da gestão automática com a API de funcionalidades da frota, não tem de seguir estas instruções. Estes passos só se aplicam se tiver feito a integração através do asmcli --managed.

Tenha em atenção que este processo altera os segredos que apontam para um cluster. Durante este processo, os pontos finais são removidos e, em seguida, adicionados novamente. Entre os pontos finais removidos e adicionados, o tráfego reverte brevemente para o encaminhamento local em vez do equilíbrio de carga para outros clusters. Para mais informações, consulte o problema do GitHub.

Para mudar da utilização de segredos do Istio para a API declarativa, siga estes passos. Execute estes passos ao mesmo tempo ou em sucessão rápida:

Ative a API declarativa para cada cluster na frota onde quer ativar a deteção de pontos finais de vários clusters definindo multicluster_mode=connected. Tenha em atenção que tem de definir explicitamente multicluster_mode=disconnected se não quiser que o cluster seja detetável.

Use o seguinte comando para ativar um cluster para a deteção de pontos finais de vários clusters:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Use o seguinte comando para desativar a deteção de pontos finais num cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Elimine segredos antigos.

Depois de definir multicluster_mode=connected nos seus clusters, cada cluster tem um novo segredo gerado para todos os outros clusters que também têm multicluster_mode=connected definido. O segredo é colocado no espaço de nomes istio-system e tem o seguinte formato:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Cada segredo também tem a etiqueta istio.io/owned-by: mesh.googleapis.com aplicada.

Depois de criar os novos segredos, pode eliminar manualmente os segredos criados com istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Após a migração, verifique as métricas de pedidos para se certificar de que são encaminhadas conforme esperado.