O Anthos Service Mesh 1.9 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

1.20 (mais recente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Como fazer upgrade do Anthos Service Mesh no GKE em uma malha de vários projetos

Neste guia, explicamos como fazer o upgrade de 1.8 or a 1.9 patch release para o Anthos Service Mesh 1.9.8 em um cluster do Google Kubernetes Engine (GKE) para uma malha contendo vários clusters que estão em diferentes projetos do Google Cloud.

Antes de começar

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

Configure o ambiente para instalar as ferramentas necessárias.

Como se preparar para o upgrade

Se você tiver personalizado a instalação anterior, precisará das mesmas personalizações quando fizer upgrade para uma nova versão do Anthos Service Mesh ou migrar do Istio. Se você tiver personalizado a instalação adicionando a sinalização --set values em istioctl install, será necessário adicionar essas configurações a um arquivo YAML IstioOperator, chamado de arquivo de sobreposição. Especifique o arquivo de sobreposição usando a opção --custom_overlay com o nome de arquivo ao executar o script. O script transfere o arquivo de sobreposição para istioctl install.

O script segue o processo de upgrade de revisão (chamado de upgrades "canário" na documentação do Istio). Com um upgrade baseado em revisão, o script instala uma nova versão do plano de controle com o plano de controle atual. Ao instalar a nova versão, o script inclui um rótulo revision que identifica o novo plano de controle.

Em seguida, você migra para a nova versão definindo o mesmo rótulo revision nas cargas de trabalho e realizando uma reinicialização gradual. Isso injeta os proxies novamente para que eles usem a nova versão e configuraçã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, será 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 os novos componentes do plano de controle substituem a versão anterior.

Como configurar variáveis de ambiente

Consiga o ID do projeto em que o cluster foi criado e o número do projeto host do environ.
gcloud
Execute este comando:
```
gcloud projects list
```
Console
1. Acesse a página Painel no console do Google Cloud:
  
  Ir para a página "Painel"
2. Clique na lista suspensa Selecionar de na parte superior da página. Na janela Selecionar de exibida, selecione seu projeto.
  
  O ID do projeto é exibido no card Informações do projeto do Painel.
Crie uma variável de ambiente para o ID do projeto em que o cluster foi criado:
```
export PROJECT_ID=YOUR_PROJECT_ID
```
Crie uma variável de ambiente para o número do projeto host do environ.
```
export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER
```
Crie as variáveis de ambiente a seguir:
- Defina o nome do cluster:
```
export CLUSTER_NAME=YOUR_CLUSTER_NAME
```
- Defina CLUSTER_LOCATION como a zona ou a região do cluster:
```
export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
```
Defina a zona ou a região padrão da Google Cloud CLI. Se você não definir o padrão aqui, especifique a opção --zone ou --region nos comandos gcloud container clusters desta página.
- Se você tiver um cluster de zona única, defina a zona padrão:
```
gcloud config set compute/zone ${CLUSTER_LOCATION}
```
- Se você tiver um cluster regional, defina a região padrão:
```
gcloud config set compute/region ${CLUSTER_LOCATION}
```
Dica: para facilitar a configuração do ambiente shell no futuro, copie e cole as instruções export de cada variável de ambiente em um script de shell simples que você source ao iniciar um novo shell. Também é possível adicionar os comandos gcloud que definem valores padrão ao script. Outra opção é usar gcloud init para criar e ativar uma configuração gcloud nomeada.

Como configurar credenciais e permissões

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.9.8-asm.6-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.9.8-asm.6-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig istio-1.9.8-asm.6-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.9.8-asm.6-linux-amd64.tar.gz
```
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:
- Exemplos de aplicativos no diretório samples.
- A ferramenta de linha de comando istioctl que você usa 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.9.8-asm.6
```

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.9.8-asm.6-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.9.8-asm.6-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.9.8-asm.6-osx.tar.gz.1.sig istio-1.9.8-asm.6-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.9.8-asm.6-osx.tar.gz
```
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:
- Exemplos de aplicativos no diretório samples.
- A ferramenta de linha de comando istioctl que você usa 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.9.8-asm.6
```

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.9.8-asm.6-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.9.8-asm.6-win.zip.1.sig
openssl dgst -verify - -signature istio-1.9.8-asm.6-win.zip.1.sig istio-1.9.8-asm.6-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.9.8-asm.6-win.zip
```
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:
- Exemplos de aplicativos no diretório samples.
- A ferramenta de linha de comando istioctl que você usa 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.9.8-asm.6
```

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.
Verifique a versão do kpt. Verifique se você está executando uma versão antes da 1.x do kpt:
```
kpt version
```
A saída será semelhante a:
```
0.39.2
```
Se você tiver a versão 1.x ou posterior do kpt, consulte Como configurar seu ambiente para fazer o download da versão necessária para seu sistema operacional.

Faça o download do pacote:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-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.9.8-asm.6
```
Defina a revisão nos arquivos de configuração do recurso do pacote do Anthos Service Mesh:
```
kpt cfg set asm anthos.servicemesh.rev asm-198-6
```
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               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.9.8-asm.6
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.

CA do Istio

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.
Verifique a versão do kpt. Verifique se você está executando uma versão antes da 1.x do kpt:
```
kpt version
```
A saída será semelhante a:
```
0.39.2
```
Se você tiver a versão 1.x ou posterior do kpt, faça o download da versão necessária:
```
curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
chmod +x kpt_0_39_2
alias kpt="$(readlink -f kpt_0_39_2)"
```

Faça o download do pacote:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-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.9.8-asm.6
```
Defina a revisão nos arquivos de configuração do recurso do pacote do Anthos Service Mesh:
```
kpt cfg set asm anthos.servicemesh.rev asm-198-6
```

Gere os valores dos setters kpt:

kpt cfg list-setters asm

A saída deste comando é semelhante a:

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.9.8-asm.6
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 fazer upgrade do Anthos Service Mesh

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.
Se necessário, mude para o diretório istio-1.9.8-asm.6. O cliente istioctl depende da versão. Certifique-se de usar a versão no diretório istio-1.9.8-asm.6/bin.
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.
```
bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --revision=asm-198-6
```
O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-198-6 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.
- O arquivo revisioned-istio-ingressgateway.yaml configura uma implantação revisada para o istio-ingressgateway.

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-198-6-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.

CA do Istio

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.
Se necessário, mude para o diretório istio-1.9.8-asm.6. O cliente istioctl depende da versão. Certifique-se de usar a versão no diretório istio-1.9.8-asm.6/bin.
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.
```
bin/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 \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --revision=asm-198-6
```
O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-198-6 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 citadel-ca.yaml configura a CA do Istio como autoridade de certificação.
- 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.
- O arquivo revisioned-istio-ingressgateway.yaml configura uma implantação revisada para o istio-ingressgateway.

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-198-6-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 implantar e reimplantar cargas de trabalho

A instalação não é completa até você ativar a injeção automática de proxy de arquivo secundário (injeção automática). As migrações do OSS Istio e os upgrades seguem o processo de upgrade baseado na revisão (chamado de "upgrades canário" na documentação do Istio). Com um upgrade baseado em revisão, a nova versão do plano de controle é instalada com o plano de controle atual. Depois, transfira algumas das cargas de trabalho para a nova versão. Isso permite monitorar o efeito do upgrade com uma pequena porcentagem das cargas de trabalho antes de migrar todo o tráfego para a nova versão.

Ao executar istioctl install, você define um rótulo de revisão no formato istio.io/rev=asm-198-6 em istiod. Para ativar a injeção automática, adicione um rótulo de revisão correspondente aos namespaces. O rótulo de revisão é usado pelo webhook do injetor do sidecar para associar os sidecars injetados a uma revisão istiod específica. Depois de adicionar o rótulo, reinicie os pods no namespace para que os arquivos secundários sejam injetados.

Se você incluiu revisioned-istio-ingressgateway.yaml ao executar istioctl install, uma implantação revisada será configurada para o istio-ingressgateway. Assim, você pode controlar quando muda para a nova versão.

Consiga o rótulo de revisão em istiod e o istio-ingressgateway.
```
kubectl get pod -n istio-system -L istio.io/rev
```
A saída deste comando é semelhante a:
```
NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-198-6
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-198-6
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-186-8
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-186-8
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-198-6
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-198-6
```
1. Observe se você tem as versões antigas e novas de istio-ingressgateway.
  - Se você tiver incluído a opção revisioned-istio-ingressgateway ao fazer upgrade, um upgrade canário do istio-ingressgateway será feito. Nesse caso, sua saída mostrará as versões antigas e novas de istio-ingressgateway.
  - Se você não incluiu revisioned-istio-ingressgateway quando fez upgrade, um upgrade no local do istio-ingressgateway foi feito. Nesse caso, o resultado mostrará apenas a nova versão.
2. Na saída, na coluna REV, anote o valor do rótulo de revisão da nova versão. Neste exemplo, o valor é asm-198-6.
3. Observe também o valor no rótulo de revisão da versão istiod antiga. Você precisará dele para excluir a versão antiga do istiod ao terminar de mover as cargas de trabalho para a nova versão. No exemplo de saída, o valor do rótulo de revisão da versão antiga é asm-186-8.
Se você tiver as versões antigas e novas do istio-ingressgateway, mude o istio-ingressgateway para a nova revisão. No comando a seguir, altere REVISION para o valor que corresponda ao rótulo de revisão da nova versão.
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
```
Resposta esperada: service/istio-ingressgateway patched
Adicione o rótulo de revisão a um namespace e remova o rótulo istio-injection, se ele existir. No comando a seguir, altere REVISION para o valor que corresponda à nova revisão de istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection

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

kubectl rollout restart deployment -n NAMESPACE

Verifique se os pods estão configurados para apontar para a nova versão de istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```
Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.
Se você achar que seu aplicativo está funcionando conforme esperado, continue com as etapas para concluir a transição para a nova versão de istiod. Se houver um problema com o aplicativo, siga as etapas para reverter.
Execute o seguinte comando novamente para confirmar se você tem as versões antigas e novas do istio-ingressgateway ou apenas a nova versão. Isso determina como você processará a transição para a nova versão do istio-ingressgateway ou a reversão para a versão antiga.
```
kubectl get pod -n istio-system -L istio.io/rev
```
Cuidado: não execute comandos que excluam a implantação istio-ingressgateway se você tiver apenas a nova versão do istio-ingressgateway. Isso impedirá que o tráfego entre na malha de serviço.
Concluir a transição
Se o aplicativo estiver funcionando corretamente, remova o plano de controle antigo para concluir a transição para a nova versão.
1. Altere para o diretório em que os arquivos do repositório anthos-service-mesh do GitHub estão localizados.
2. Configure o webhook de validação para usar o novo plano de controle.
  kubectl apply -f asm/istio/istiod-service.yaml
3. Se você tiver as versões antigas e novas do istio-ingressgateway, exclua a implantação istio-ingressgateway antiga. O comando executado depende se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Anthos Service Mesh:
  Migrar
  Se você tiver migrado do Istio, o istio-ingressgateway antigo não terá um rótulo de revisão.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  Fazer upgrade
  Se você tiver feito upgrade de uma versão anterior do Anthos Service Mesh, no comando a seguir, substitua OLD_REVISION pelo rótulo de revisão da versão anterior do istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
4. Exclua a versão antiga de istiod. O comando usado depende de se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Anthos Service Mesh.
  Migrar
  Se você tiver migrado do Istio, o istiod antigo não terá um rótulo de revisão.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Fazer upgrade
  Se você fez upgrade de uma versão anterior do Anthos Service Mesh, no comando a seguir, verifique se OLD_REVISION corresponde ao rótulo de revisão da versão anterior de istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
5. Remova a versão antiga da configuração de IstioOperator.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  A saída esperada terá esta aparência:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Reversão
Se você encontrar um problema ao testar seu aplicativo com a nova versão de istiod, siga estas etapas para reverter para a versão anterior:
1. Volte para a versão antiga de istio-ingressgateway. O comando usado depende de você ter as versões antigas e novas do istio-ingressgateway ou apenas a nova versão.
  - Se você tiver as versões antigas e novas do istio-ingressgateway, execute o comando kubectl patch service e substitua OLD_REVISION pela revisão antiga.
    
    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
  - Se você tiver apenas a nova versão do istio-ingressgateway, execute o comando kubectl rollout undo.
    
    kubectl -n istio-system rollout undo deploy istio-ingressgateway
2. Altere o nome do seu namespace para ativar a injeção automática com a versão anterior do istiod. O comando usado depende de você ter usado um rótulo de revisão ou istio-injection=enabled com a versão anterior.
  - Se você usou um rótulo de revisão para a injeção automática, faça o seguinte:
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - Se você usou istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Saída esperada:
  namespace/NAMESPACE labeled
3. Confirme se o rótulo de revisão no namespace corresponde ao rótulo de revisão na versão anterior de istiod:
  kubectl get ns NAMESPACE --show-labels
4. Reinicie os pods para acionar a nova injeção de modo que os proxies tenham a versão do Istio:
  kubectl rollout restart deployment -n NAMESPACE
5. Se você tiver as versões antigas e novas do istio-ingressgateway, remova a nova implantação istio-ingressgateway. Verifique se o valor de REVISION no comando a seguir está correto.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
6. Remova a nova versão de istiod. Verifique se o valor de REVISION no comando a seguir está correto.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
7. Remova a nova versão da configuração IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION -n istio-system
  A saída esperada será assim:
  istiooperator.install.istio.io "installed-state-REVISION" deleted
8. Se você não incluiu a sinalização --disable_canonical_service, o script ativou o controlador de serviço canônico. É recomendável deixá-la ativada, mas, se você precisar desativá-la, consulte Como ativar e desativar o controlador de serviço canônico.

Como fazer upgrade do Anthos Service Mesh no GKE em uma malha de vários projetos

Antes de começar

Como se preparar para o upgrade

Como configurar variáveis de ambiente

gcloud

Console

Como configurar credenciais e permissões

Como fazer o download do arquivo de instalação

Linux

macOS

Windows

Como preparar arquivos de configuração de recursos

CA da malha

CA do Istio

Como fazer upgrade do Anthos Service Mesh

CA da malha

CA do Istio

Como implantar e reimplantar cargas de trabalho

Concluir a transição

Migrar

Fazer upgrade

Migrar

Fazer upgrade

Reversão

A seguir