O Anthos Service Mesh 1.7 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

Versões disponíveis

Como migrar do Istio para o Anthos Service Mesh

Esta página faz parte de um guia de várias páginas que explica como migrar do Istio 1.7.8para a versão do Anthos Service Mesh em um cluster do GKE para uma malha que contém vários clusters que estão em diferentes projetos do Cloud. Para migrações em uma malha de cluster único ou para uma malha que contém vários clusters no mesmo projeto do Cloud, consulte Instalação, migração e upgrade para o GKE.

< Anterior

Antes de começar

Antes de instalar o Anthos Service Mesh, verifique se você tem:

Configure o ambiente para instalar as ferramentas necessárias.
Configure o projeto para ativar as APIs necessárias e definir permissões.
Configure o cluster para ativar as opções obrigatórias.
Leia Como se preparar para migrar do Istio.

Como configurar credenciais e permissões

Inicialize seu projeto para prepará-lo para instalação. Entre outras coisas, este comando cria uma conta de serviço para permitir componentes de plano de controle, como o proxy sidecar, para acessar com segurança os dados e os recursos do seu projeto:
```
curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"
```
A resposta do comando mostra chaves vazias: {}
Consiga as credenciais de autenticação para interagir com o cluster: Esse comando também define o contexto atual para kubectl no cluster.
```
gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --project=${PROJECT_ID}
```
Observação: a menos que você tenha definido uma zona ou região padrão, é necessário fornecer a região (--region=REGION) ou zona (--zone=ZONE) no comando.
Conceda permissões de administrador de cluster ao usuário atual. Você precisa dessas permissões para criar as regras necessárias de controle de acesso baseado em papéis (RBAC, na sigla em inglês) para o Anthos Service Mesh.
```
kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user="$(gcloud config get-value core/account)"
```

Se você observar o erro "cluster-admin-binding" already exists, poderá ignorá-lo com segurança e continuar com o cluster-admin-binding atual.

Como fazer o download do arquivo de instalação

Linux

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig istio-1.7.8-asm.10-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

tar xzf istio-1.7.8-asm.10-linux-amd64.tar.gz

O comando cria um diretório de instalação no seu diretório de trabalho atual chamado istio-1.7.8-asm.10, que contém:

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl usada para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

macOS

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.7.8-asm.10-osx.tar.gz.1.sig istio-1.7.8-asm.10-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

tar xzf istio-1.7.8-asm.10-osx.tar.gz

O comando cria um diretório de instalação no seu diretório de trabalho atual chamado istio-1.7.8-asm.10, que contém:

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl usada para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

Windows

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip.1.sig
openssl dgst -verify - -signature istio-1.7.8-asm.10-win.zip.1.sig istio-1.7.8-asm.10-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

tar xzf istio-1.7.8-asm.10-win.zip

O comando cria um diretório de instalação no seu diretório de trabalho atual chamado istio-1.7.8-asm.10, que contém:

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl usada para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.
```
cd istio-1.7.8-asm.10
```
Para facilitar, adicione as ferramentas ao diretório /bin/bin do seu PATH.
```
export PATH=$PWD/bin:$PATH
```

Como preparar arquivos de configuração de recursos

Ao executar o comando istioctl install, especifique -f istio-operator.yaml na linha de comando. Esse arquivo contém informações sobre o projeto e o cluster exigidos pelo Anthos Service Mesh. Faça o download de um pacote que contenha istio-operator.yaml e outros arquivos de configuração de recursos para que seja possível definir as informações do projeto e do cluster.

Para preparar os arquivos de configuração de recursos, siga estas etapas:

CA da malha

Crie um novo diretório para os arquivos de configuração do recurso do pacote Anthos Service Mesh. Recomendamos que você use o nome do cluster como o nome do diretório.
Altere para o diretório em que você quer fazer o download do pacote do Anthos Service Mesh.

Faça o download do pacote:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm

Defina o ID do projeto em que o cluster foi criado:

kpt cfg set asm gcloud.core.project ${PROJECT_ID}

Defina o número do projeto host da frota:

kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

Defina o nome do cluster:

kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

Defina a zona ou a região padrão:

kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

Defina a tag para a versão do Anthos Service Mesh que você está instalando:
```
kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
```
Defina o webhook de validação para usar um rótulo de revisão:
```
kpt cfg set asm anthos.servicemesh.rev asm-178-10
```
Ao instalar o Anthos Service Mesh, você define um rótulo de revisão em istiod. Você precisa definir a mesma revisão no webhook de validação.
Como os clusters da sua configuração de vários clusters estão em projetos diferentes, você precisa configurar os aliases de domínio de confiança para os outros projetos que formarão a malha de serviço de vários clusters/vários projetos.
1. Encontre o ID do projeto de todos os clusters que estarão na malha de vários clusters/vários projetos.
2. Para o ID do projeto de cada cluster, defina os aliases do domínio de confiança. Por exemplo, se você tiver clusters em três projetos, execute o seguinte comando e substitua PROJECT_ID_1, PROJECT_ID_2 e PROJECT_ID_3 pelo ID do projeto de cada cluster.
```
kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog
```
  Ao configurar os clusters nos outros projetos, é possível usar o mesmo comando.
  
  Os aliases de domínio de confiança permitem que a CA da malha autentique cargas de trabalho em clusters em outros projetos. Além de definir os aliases de domínio de confiança, depois de instalar o Anthos Service Mesh, você precisa ativar o balanceamento de carga entre clusters.

Gere os valores dos setters kpt:

kpt cfg list-setters asm

A saída deste comando é semelhante a:

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gcr.io/gke-release/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.7.8-asm.10
anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

Verifique se os valores dos seguintes setters estão corretos:

anthos.servicemesh.rev
anthos.servicemesh.tag
anthos.servicemesh.trustDomainAliases
gcloud.compute.location
gcloud.container.cluster
gcloud.core.project
gcloud.project.environProjectNumber

Você pode ignorar os valores dos outros setters.

Citadel

Crie um novo diretório para os arquivos de configuração do recurso do pacote Anthos Service Mesh. Recomendamos que você use o nome do cluster como o nome do diretório.
Altere para o diretório em que você quer fazer o download do pacote do Anthos Service Mesh.

Faça o download do pacote:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm

Defina o ID do projeto em que o cluster foi criado:

kpt cfg set asm gcloud.core.project ${PROJECT_ID}

Defina o número do projeto host da frota:

kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

Defina o nome do cluster:

kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

Defina a zona ou a região padrão:

kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

Defina a tag para a versão do Anthos Service Mesh que você está instalando:
```
kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
```
Defina o webhook de validação para usar um rótulo de revisão:
```
kpt cfg set asm anthos.servicemesh.rev asm-178-10
```

Gere os valores dos setters kpt:

kpt cfg list-setters asm

A saída deste comando é semelhante a:

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gcr.io/gke-release/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.7.8-asm.10
anthos.servicemesh.trustDomainAliases
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

Verifique se os valores dos seguintes setters estão corretos:

anthos.servicemesh.rev
anthos.servicemesh.tag
gcloud.compute.location
gcloud.container.cluster
gcloud.core.project
gcloud.project.environProjectNumber

Você pode ignorar os valores dos outros setters.

Como migrar para o Anthos Service Mesh

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.

Como atualizar o plano de controle

CA da malha

Verifique se o contexto kubeconfig atual está apontando para o cluster em que você quer instalar o Anthos Service Mesh:
```
kubectl config current-context
```
A saída está no seguinte formato:
```
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
```
O contexto kubeconfig e os valores dos setters kpt precisam ser correspondentes. Se necessário, execute o comando gcloud container clusters get-credentials para definir o contexto kubeconfig atual.
Execute o seguinte comando para implantar o novo plano de controle com o perfil asm-gcp-multiproject. Se você quiser ativar um recurso opcional compatível, inclua -f e o nome de arquivo YAML na linha de comando a seguir. Para ver mais informações, consulte Como ativar recursos opcionais.

Importante: se você estiver instalando no GKE 1.15, adicione o arquivo de sobreposição -f asm/istio/options/v1beta1-crds.yaml, além dos arquivos de sobreposição especificados no comando a seguir.
```
istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml\
  --revision=asm-178-10
```
O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-178-10 a istiod. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Para ativar a injeção automática de sidecar em um namespace, você precisa rotulá-lo com uma revisão correspondente a uma implantação istiod.

Os arquivos a seguir modificam as configurações no arquivo istio-operator.yaml:
- O arquivo multiproject.yaml define o perfil asm-gcp-multiproject.
- O arquivo multicluster.yaml define as configurações que o Anthos Service Mesh precisa para uma configuração de vários clusters.

Verifique se os pods do plano de controle em istio-system estão ativos:

kubectl get pods -n istio-system

Exemplo de saída:

NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-178-10-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

Você tem duas implantações e serviços de plano de controle em execução lado a lado.

Implante o controlador de serviços canônicos no cluster:
```
kubectl apply -f asm/canonical-service/controller.yaml
```
O controlador de serviços canônicos agrupa cargas de trabalho que pertencem ao mesmo serviço lógico. Para mais informações sobre os serviços canônicos, consulte a visão geral dos serviços canônicos.

Citadel

Verifique se o contexto kubeconfig atual está apontando para o cluster em que você quer instalar o Anthos Service Mesh:
```
kubectl config current-context
```
A saída está no seguinte formato:
```
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
```
O contexto kubeconfig e os valores dos setters kpt precisam ser correspondentes. Se necessário, execute o comando gcloud container clusters get-credentials para definir o contexto kubeconfig atual.
Execute o seguinte comando para implantar o novo plano de controle com o perfil asm-gcp-multiproject. Se você quiser ativar um recurso opcional compatível, inclua -f e o nome de arquivo YAML na linha de comando a seguir. Para ver mais informações, consulte Como ativar recursos opcionais.

Importante: se você estiver instalando no GKE 1.15, adicione o arquivo de sobreposição -f asm/istio/options/v1beta1-crds.yaml, além dos arquivos de sobreposição especificados no comando a seguir.
```
istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/citadel-ca.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml\
  --revision=asm-178-10
```
O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-178-10 a istiod. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Para ativar a injeção automática de sidecar em um namespace, você precisa rotulá-lo com uma revisão correspondente a uma implantação istiod.

Os arquivos a seguir modificam as configurações no arquivo istio-operator.yaml:
- O arquivo citadel-ca.yaml configura o Citadel como a CA.
- O arquivo multiproject.yaml define o perfil asm-gcp-multiproject.
- O arquivo multicluster.yaml define as configurações que o Anthos Service Mesh precisa para uma configuração de vários clusters.

Verifique se os pods do plano de controle em istio-system estão ativos:

kubectl get pods -n istio-system

Exemplo de saída:

NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-178-10-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

Você tem duas implantações e serviços de plano de controle em execução lado a lado.

Implante o controlador de serviços canônicos no cluster:
```
kubectl apply -f asm/canonical-service/controller.yaml
```
O controlador de serviços canônicos agrupa cargas de trabalho que pertencem ao mesmo serviço lógico. Para mais informações sobre os serviços canônicos, consulte a visão geral dos serviços canônicos.

Como reimplantar cargas de trabalho

A instalação da nova revisão não afeta os proxies sidecar atuais. Para fazer upgrade, configure-os para que direcionem para o novo plano de controle. Isso é controlado durante a injeção do sidecar com base no rótulo de namespace istio.io/rev.

Atualize as cargas de trabalho que serão injetadas com a nova versão do Anthos Service Mesh:
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-178-10 --overwrite
```
O rótulo istio-injection precisa ser removido porque tem precedência sobre o rótulo istio.io/rev.

Reinicie os pods para acionar a nova injeção:

kubectl rollout restart deployment -n NAMESPACE

Verifique se os pods estão configurados de modo que apontem para o plano de controle istiod-asm-178-10:
```
kubectl get pods -n NAMESPACE -l istio.io/rev=asm-178-10
```
Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
Se você tiver cargas de trabalho em outros namespaces, repita os passos anteriores para cada namespace.
Se o aplicativo estiver funcionando corretamente, pule para Concluir a migração. Caso contrário, siga estas etapas para reverter à versão anterior:

Para reverter:
1. Atualize as cargas de trabalho a serem injetadas com a versão anterior do plano de controle:
```
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
```
2. Reinicie os pods para acionar a reinjeção para que os proxies tenham a versão anterior:
```
kubectl rollout restart deployment -n NAMESPACE
```
3. Reimplante a versão anterior do istio-ingressgateway:
```
kubectl -n istio-system rollout undo deploy istio-ingressgateway
```
4. Remova o novo plano de controle:
```
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-178-10 -n istio-system --ignore-not-found=true
```

Conclua a migração

Se o aplicativo estiver funcionando conforme o esperado, siga estas etapas a fim de concluir a migração para o Anthos Service Mesh:

Remova o plano de controle antigo:

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Como registrar o cluster

É necessário registrar o cluster com a frota do projeto para ter acesso à interface do usuário unificada no console do Google Cloud. Uma frota fornece uma forma unificada de visualizar e gerenciar os clusters e as cargas de trabalho deles, incluindo clusters fora do Google Cloud.

Veja informações sobre como registrar seu cluster em Como registrar clusters na frota.

A seguir

< Anterior