O Anthos Service Mesh 1.10 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 migrar para a CA da malha

A migração para a autoridade de certificação do Anthos Service Mesh (Mesh CA) do Istio CA (também conhecida como Citadel) requer a migração da raiz de confiança. Antes do Anthos Service Mesh 1.10, se você quisesse migrar do Istio no Google Kubernetes Engine (GKE) para o Anthos Service Mesh com Mesh CA, era necessário programar o tempo de inatividade porque o Anthos Service Mesh não podia carregar vários certificados raiz. Portanto, durante a migração, as cargas de trabalho recém-implantadas confiam no novo certificado raiz, enquanto outras confiam no certificado raiz antigo. Não é possível autenticar as cargas de trabalho que usam certificados assinados por diferentes certificados raiz. Isso significa que o tráfego TLS mútuo (mTLS, na sigla em inglês) é interrompido durante a migração. Todo o cluster só é recuperado totalmente quando o plano de controle e todas as cargas de trabalho em todos os namespaces são reimplantados com o certificado da CA da malha. Se sua malha tiver vários clusters com cargas de trabalho que enviam solicitações para cargas de trabalho em outro cluster, todas as cargas de trabalho nesses clusters também precisarão ser atualizadas.

Nesta página, descrevemos como migrar a CA do Istio para a CA do Mesh com tempo de inatividade mínimo ou nenhum. Siga as etapas deste guia para os seguintes casos de uso:

Migre do Istio no GKE para o plano de controle no cluster 1.10.6-asm.2 do Anthos Service Mesh com a CA da malha.
Faça upgrade do Anthos Service Mesh 1.9 or a 1.10 patch release com a CA do Istio para o plano de controle no cluster 1.10.6-asm.2 do Anthos Service Mesh com a CA da malha.

Limitações

A CA da malha é compatível apenas com o GKE.
Todos os clusters precisam estar no mesmo projeto do Google Cloud.

Pré-requisitos

Este guia pressupõe que você já tem:

Um projeto do Google Cloud.
Uma Conta de faturamento do Cloud.
As ferramentas necessárias para executar o script install_asm
Para uma malha de vários clusters usando a CA do Istio, o mesmo certificado raiz precisa ser definido em cada cluster

Ferramentas necessárias

Durante a migração, execute um script fornecido pelo Google, migrate_ca, para validar o seguinte para cada pod no cluster:

O certificado raiz da CA do Istio e da CA da malha.
O certificado mTLS da carga de trabalho emitido pela Istio CA e pela CA da malha.
Os domínios de confiança configurados pela CA do Istio e pela CA da malha.

Esse script tem as seguintes dependências:

awk
grep
istioctl Ao executar o script install_asm, ele faz o download da versão de istioctl que corresponde à versão do Anthos Service Mesh que você está instalando.
jq
kubectl
openssl

Visão geral da migração

Para migrar para a CA da malha, siga o processo de migração baseado em revisão, também conhecido como "upgrade canário". Com uma migração baseada em revisão, uma nova revisão do plano de controle é implantada ao lado do plano de controle existente. Em seguida, mova gradualmente as cargas de trabalho para a nova revisão, o que permite monitorar o efeito da migração durante o processo. Durante o processo de migração, a autenticação e a autorização estão totalmente funcionais entre as cargas de trabalho que usam a CA da malha e as cargas de trabalho que usam a CA do Istio.

Veja a seguir um resumo da migração para a CA da malha:

Distribua a raiz da CA da malha de confiança.
1. Instale uma nova revisão do plano de controle com uma opção que distribuirá a raiz de confiança da CA da malha.
2. Migre cargas de trabalho para o novo plano de controle, namespace por namespace e teste o aplicativo. Quando todas as cargas de trabalho forem migradas com sucesso para o novo plano de controle, remova o plano de controle antigo.
Migrar para a CA da malha. Agora que todos os proxies secundários estão configurados com a raiz de confiança antiga e a raiz de confiança da CA da malha, é possível migrar para a CA da malha sem tempo de inatividade. Novamente, você segue o processo de migração baseado em revisão:
1. Instale uma revisão do plano de controle com a CA da malha ativada.
2. Migre cargas de trabalho para a nova revisão do plano de controle, namespace por namespace e teste seu aplicativo. Quando todas as cargas de trabalho forem migradas com sucesso para o novo plano de controle, remova o plano de controle antigo.
3. Remova os secrets de CA no cluster associados à CA antiga e reinicie o novo plano de controle.

Distribuir a raiz de confiança de CA da malha

Antes de migrar para a CA da malha, todos os clusters do GKE na malha precisam ter o Anthos Service Mesh 1.10 ou posterior, e todos os clusters precisam ser configurados com uma opção de plano de controle que acione a raiz de confiança para que a CA da malha seja distribuída aos proxies de todas as cargas de trabalho no cluster. Quando o processo é concluído, cada proxy é configurado com a raiz de confianças antiga e nova. Com esse esquema, ao migrar para a CA da malha, as cargas de trabalho que usam a CA da malha poderão se autenticar com cargas de trabalho usando a CA antiga.

Instalar uma nova revisão do plano de controle

Instale uma revisão de plano de controle com uma opção que distribui a raiz de confiança da CA da malha.

Siga as etapas da seção Como instalar o Anthos Service Mesh no GKE para se preparar para usar um script fornecido pelo Google, install_asm, para instalar a nova revisão do plano de controle.
Verifique se você tem a versão de install_asm que instala o Anthos Service Mesh 1.10 ou superior:
```
./install_asm --version
```
Execute install_asm. No comando a seguir, substitua os marcadores pelos valores.
- PROJECT_ID: obrigatório. O ID do projeto em que o cluster foi criado.
- CLUSTER_NAME: obrigatório. O nome do cluster.
- CLUSTER_LOCATION: obrigatório. A zona ou região em que o cluster está.
- REVISION_1: recomendado. Um rótulo de revisão é um par de chave-valor definido no plano de controle. A chave do rótulo de revisão é sempre istio.io/rev. Por padrão, o script define o valor do rótulo de revisão com base na versão do Anthos Service Mesh, por exemplo: asm-1106-2. Recomendamos que você inclua essa opção e substitua REVISION_1 por um nome que descreva a instalação, como asm-1106-2-distribute-root. O nome precisa ser um rótulo DNS-1035 e conter caracteres alfanuméricos minúsculos ou -, começar com um caractere alfabético e terminar com um caractere alfanumérico, como my-name' ou abc-123. A regex usada para validação é: '[a-z]([-a-z0-9]*[a-z0-9])?')
- DIR_PATH : obrigatório. Um caminho relativo para um diretório em que o script faz o download do pacote anthos-service-mesh e do arquivo de instalação do Anthos Service Mesh, que contém istioctl, amostras e manifestos.
- OVERLAYS: opcional. Se você quiser ativar recursos opcionais, incluir --custom_overlay com o nome do arquivo de sobreposição para cada recurso. Se você não estiver ativando recursos opcionais, exclua esta linha e a barra invertida na linha anterior.
```
./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --option ca-migration-citadel \
  --revision_name REVISION_1  \
  --output_dir DIR_PATH \
  OVERLAYS
```
Os seguintes argumentos de linha de comando são obrigatórios:
- --ca citadel: para evitar a inatividade, especifique a CA do Istio. A opção citadel corresponde à CA do Istio. Não mude para a CA da malha neste momento.
- --option ca-migration-citadel: quando você reimplanta as cargas de trabalho, essa opção aciona a nova raiz de confiança a ser distribuída aos proxies sidecar das cargas de trabalho.

Migrar cargas de trabalho para o novo plano de controle

Para concluir a distribuição da nova raiz de confiança, é necessário rotular seus namespaces com o rótulo de revisão istio.io/rev=asm-1106-2-distribute-root e reiniciar suas cargas de trabalho. Ao testar as cargas de trabalho depois de reiniciá-las, execute um script para validar se o proxy sidecar está configurado com a raiz de confiança antiga e nova da CA da malha.

Defina o contexto atual para kubectl. No comando a seguir, altere --region para --zone se você tiver um cluster de zona única.

gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION

Faça o download do script de validação:

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.10-asm/scripts/ca-migration/migrate_ca > migrate_ca

Defina o bit executável no script:
```
chmod +x migrate_ca
```
O script migrate_ca chama istioctl, que depende da versão. O script install_asm adiciona um link simbólico a istioctl no diretório especificado para --output_dir. Verifique se o diretório está no início do seu caminho. No comando a seguir, substitua ISTIOCTL_PATH pelo diretório que contém istioctl que o script fez o download.
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

Consiga o rótulo de revisão em istiod e o istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

O resultado será assim:

NAME                                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

Na saída, na coluna REV, anote o valor do rótulo de revisão para a nova revisão, que corresponde ao rótulo de revisão especificado quando você executou install_asm. Neste exemplo, o valor é asm-1106-2-distribute-root.
Você precisa excluir a revisão antiga de istiod quando terminar de mover as cargas de trabalho para a nova revisão. Observe o valor no rótulo da revisão da istiod antiga. A saída de exemplo mostra uma migração do Istio, que está usando a revisão default.

Alterne istio-ingressgateway para a nova revisão. No comando a seguir, verifique se REVISION_1 corresponde ao valor do rótulo de revisão da nova revisão.

kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'

Saída 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, substitua NAMESPACE pelo namespace a ser rotulado.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 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_1
```
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.
Valide se os proxies sidecar para todas as cargas de trabalho no cluster estão configurados com os certificados raiz antigos e novos:
```
./migrate_ca check-root-cert
```
Saída esperada:
```
Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
```
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.
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. 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:
  Migrate
  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 revisã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.
  Migrate
  Se você tiver migrado do Istio, o istio-ingressgateway 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-ingressgatewqy. No comando a seguir, 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"}]'
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. Remova a nova implantação istio-ingressgateway.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
6. Remova a nova revisão de istiod.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
7. Remova a nova configuração IstioOperator.
  kubectl delete IstioOperator installed-state-asm-1106-2-distribute-root -n istio-system
  A saída esperada será assim:
  istiooperator.install.istio.io "installed-state-asm-1106-2-distribute-root" deleted

Migrar para a CA da malha

Agora que os proxies secundários de todas as cargas de trabalho estão configurados com a raiz de confiança antiga e a nova raiz de confiança para a CA da malha, as etapas para migrar para a CA da malha são semelhantes às que você fez para distribuir a raiz de confiança da CA da malha:

Instalar um novo plano de controle com a CA da malha ativada

Use install_asm para instalar uma nova revisão de plano de controle que tenha a CA da malha ativada.

Se você tiver personalizado a instalação anterior, precisará especificar os mesmos arquivos de sobreposição ao executar install_asm.
Execute install_asm. No comando a seguir, substitua os marcadores pelos valores.
- PROJECT_ID: obrigatório. O ID do projeto em que o cluster foi criado.
- CLUSTER_NAME: obrigatório. O nome do cluster.
- CLUSTER_LOCATION: obrigatório. A zona ou região em que o cluster está.
- REVISION_2: recomendado. Substitua REVISION_2 por um nome que descreva a instalação, como asm-1106-2-meshca-ca-migration. O nome da revisão precisa ser um rótulo DNS-1035 e conter caracteres alfanuméricos minúsculos ou -, começar com um caractere alfabético e terminar com um caractere alfanumérico, como my-name' ou abc-123. A regex usada para validação é: '[a-z]([-a-z0-9]*[a-z0-9])?')
- DIR_PATH : obrigatório. Um caminho relativo para um diretório em que o script faz o download do pacote anthos-service-mesh e do arquivo de instalação do Anthos Service Mesh, que contém istioctl, amostras e manifestos.
- OVERLAYS: opcional. Se você quiser ativar recursos opcionais, incluir --custom_overlay com o nome do arquivo de sobreposição para cada recurso. Se você não estiver ativando recursos opcionais, exclua esta linha e a barra invertida na linha anterior.
```
./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --enable_all \
  --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
```
Os seguintes argumentos de linha de comando são obrigatórios:
- --ca mesh_ca: agora é possível alternar para a CA da malha porque a raiz da CA da malha de confiança foi distribuída.
- --option ca-migration-migration: quando você reimplanta suas cargas de trabalho, essa opção configura os proxies para usar a raiz de confiança da CA da malha.

Migrar cargas de trabalho para o novo plano de controle

Para concluir a instalação, é preciso rotular seus namespaces com o novo rótulo de revisão e reiniciar as cargas de trabalho.

Consiga o rótulo de revisão em istiod e o istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

A resposta será semelhante a:

NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-asm-1106-2-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1106-2-distribute-root
istio-ingressgateway-asm-1106-2-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1106-2-distribute-root
istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1106-2-meshca-ca-migration
istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2-meshca-ca-migration
istiod-asm-1106-2-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1106-2-distribute-root
istiod-asm-1106-2-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1106-2-distribute-root
istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2-meshca-ca-migration
istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2-meshca-ca-migration

Na saída, na coluna REV, anote o valor do rótulo de revisão da nova versão. Neste exemplo, o valor é asm-1106-2-meshca-ca-migration.
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, o valor do rótulo de revisão da revisão anterior é "asm-1106-2-distribute-root".

Alterne istio-ingressgateway para a nova revisão. No comando a seguir, altere REVISION_2 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_2"}]'

Saída esperada:

service/istio-ingressgateway patched

Adicione o novo rótulo de revisão em um namespace. No comando a seguir, substitua NAMESPACE pelo namespace a ser rotulado.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
```

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_2
```
Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente. Certifique-se de que a comunicação mTLS funcione entre cargas de trabalho no namespace mais antigo e no namespace mais recente.
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 o novo plano de controle. Se houver um problema com o aplicativo, siga as etapas para reverter.
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. Exclua a implantação istio-ingressgateway antiga. 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 revisão istiod antiga. No comando a seguir, substitua OLD_REVISION pelo 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 configuração IstioOperator antiga.
  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ê encontrou um problema ao testar o aplicativo com a nova revisão istiod, siga estas etapas para reverter para a revisão anterior:
1. Volte para a istio-ingressgatewqy anterior. No comando a seguir, 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"}]'
2. Rotule seu namespace novamente para ativar a injeção automática com a revisão istiod anterior.
  kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --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. Remova a nova implantação istio-ingressgateway.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
6. Remova a nova versão de istiod. Certifique-se de que o rótulo de revisão no comando a seguir corresponda à sua revisão.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
7. Remova a nova versão da configuração IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
  A saída esperada será assim:
  istiooperator.install.istio.io "installed-state-REVISION_2" deleted

Remover os secrets da CA e reiniciar o novo plano de controle

Preserve os secrets caso seja necessário:

kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2

Remova os secrets da CA no cluster associado à CA antiga:

 kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found

Reinicie o plano de controle recém-instalado. Isso garante que a raiz de confiança antiga seja excluída de todas as cargas de trabalho em execução na malha.
```
kubectl rollout restart deployment -n istio-system
```

Como migrar para a CA da malha

Limitações

Pré-requisitos

Ferramentas necessárias

Visão geral da migração

Distribuir a raiz de confiança de CA da malha

Instalar uma nova revisão do plano de controle

Migrar cargas de trabalho para o novo plano de controle

Concluir a transição

Migrate

Fazer upgrade

Migrate

Fazer upgrade

Reversão

Migrar para a CA da malha

Instalar um novo plano de controle com a CA da malha ativada

Migrar cargas de trabalho para o novo plano de controle

Concluir a transição

Reversão

Remover os secrets da CA e reiniciar o novo plano de controle