Migrar do Istio para o Anthos Service Mesh exige planejamento. Nesta página, você encontra informações para se preparar para a migração.
Como analisar os perfis
Os perfis de configuração fornecidos pelo Anthos Service Mesh são diferentes dos do Istio de código aberto. Ao instalar o Anthos Service Mesh, você usa um perfil de configuração adequado para o ambiente:
asm-gcp
: use esse perfil para instalações no GKE em uma malha que contenha um único cluster ou vários clusters que estejam no mesmo projeto do Google Cloud.asm-gcp-multiproject
Beta: use esse perfil para instalações no GKE com clusters em diferentes projetos do Google Cloud.asm-multicloud
: use este perfil para instalações nos ambientes a seguir:- GKE no VMware
- GKE na AWS
- Amazon Elastic Kubernetes Service (Amazon EKS)
- Microsoft Azure Kubernetes Service (Microsoft AKS)
Os recursos compatíveis do Anthos Service Mesh são diferentes entre os perfis. Revise os Recursos compatíveis para o perfil certo para sua configuração.
Comparar perfis
É possível comparar o perfil de configuração usado para instalar o Istio com o perfil do Anthos Service Mesh que você planeja usar:
Siga as etapas em Como fazer o download do arquivo de instalação para fazer o download dos arquivos de instalação e assinatura, extrair o conteúdo e definir o caminho para usar a versão de
istioctl
de do arquivo de download.Gere um manifesto para o perfil do Anthos Service Mesh que você planeja usar:
istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
Localize o perfil usado para instalar o Istio. Como os perfis podem mudar entre as versões do Istio, você precisa do perfil no pacote de instalação que corresponde à sua versão do Istio.
Gere um manifesto para o perfil usado para instalar o Istio:
istioctl manifest generate -f ISTIO_PROFILE > b.yaml
Compare os manifestos:
istioctl manifest diff a.yaml b.yaml
Como preparar arquivos de configuração
Se você
personalizar a instalação do Istio
(em inglês), precisará das mesmas personalizações ao migrar para o Anthos Service Mesh. Se você
tiver personalizado a instalação adicionando a sinalização --set values
, recomendamos
que adicione essas configurações a um
arquivo de configuração
IstioOperator
. Especifique o arquivo de configuração usando a sinalização -f
com o arquivo de configuração ao executar o comando istioctl install
.
Como escolher uma autoridade de certificação
É possível continuar usando o
Citadel
(agora incorporado em istiod
) como a autoridade de certificação (CA, na sigla em inglês) para emitir
TLS mútuo (mTLS) certificados, ou
é possível migrar para a autoridade de certificação do Anthos Service Mesh (Mesh CA).
Recomendamos que você use a Mesh CA pelos seguintes motivos:
- A Mesh CA é um serviço altamente confiável e escalonável, otimizado para cargas de trabalho escalonadas dinamicamente no Google Cloud.
- Com ela, o Google gerencia a segurança e a disponibilidade do back-end da CA.
- Esta autoridade de certificação possibilita confiar em uma única raiz de confiança entre os clusters.
No entanto, há casos em que é recomendável usar o Citadel, como os seguintes:
- Se você tiver uma CA personalizada.
- Não é possível programar um tempo de inatividade para a migração para Mesh CA. Recomendamos o uso da CA de malha, mas é necessário agendar o tempo de inatividade para a migração porque o tráfego mTLS falha até que todos os pods sejam reiniciados em todos os namespaces.
Como revisar o processo de migração
Para migrar do Istio, siga o
processo de upgrade do plano de controle duplo,
chamado de upgrades canário na documentação do Istio. Com um upgrade do plano
de controle duplo, você instala uma nova versão do plano de controle junto com o plano
atual. Ao instalar a nova versão, inclua uma
etiqueta revision
que identifique a versão do novo plano de controle. Cada
revisão é uma implementação completa do plano de controle do Anthos Service Mesh com implantação e
serviço próprios.
Em seguida, você migra para a nova versão definindo a mesma etiqueta revision
em suas
cargas de trabalho para apontar para o novo plano de controle e realizando uma reinicialização gradual para
reinjetar os proxies com a nova versão do Anthos Service Mesh. Com essa abordagem,
é possível monitorar o efeito do upgrade em uma pequena porcentagem das
cargas de trabalho. Depois de testar o aplicativo, é possível migrar todo o tráfego para a
nova versão. Essa abordagem é muito mais segura do que realizar um upgrade no local em que um novo plano de controle substitui imediatamente a versão anterior do plano de controle.
A menos que você tenha um balanceador de carga ou uma configuração de roteador para implantações azul-verde, recomendamos que você teste a migração e reinicie os pods em um ambiente de preparação para verificar se seus serviços pode lidar com qualquer possível interrupção do tráfego.