Migração com base canário 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.
Siga as etapas deste guia para os seguintes casos de uso:
- Migre do Istio 1.23.2-asm.2 no GKE para o plano de controle no cluster do Anthos Service Mesh com a CA da malha.
- Faça upgrade do Anthos Service Mesh 1.15 or a 1.16 patch release com a CA do Istio para o plano de controle no cluster 1.23.2-asm.2 do Anthos Service Mesh com a CA da malha.
Limitações
- Todos os clusters precisam estar no mesmo projeto do Google Cloud.
Pré-requisitos
Siga as etapas em Instalar ferramentas dependentes e validar o cluster para:- Instale as ferramentas necessárias
- Fazer o download de
asmcli
- Conceder permissões de administrador de cluster
- Validar o projeto e o cluster
Ferramentas necessárias
Durante a migração, execute uma ferramenta fornecida 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.
Essa ferramenta tem as seguintes dependências:
awk
grep
istioctl
Executarasmcli install
faz o download da versão deistioctl
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.
Instale uma nova revisão do plano de controle que use a CA do Istio com uma opção que distribuirá a raiz de confiança da CA do Mesh.
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:
Instale uma revisão do plano de controle com a CA da malha ativada.
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.
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 em Instalar ferramentas dependentes e validar o cluster para se preparar para usar uma ferramenta fornecida pelo Google,
asmcli
, para instalar a nova revisão do plano de controle.Verifique se você tem a versão de
asmcli
que instala o Anthos Service Mesh 1.11 ou superior:./asmcli --version
Execute
asmcli install
. No comando a seguir, substitua os marcadores pelos valores../asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH
--fleet_id
O ID do projeto host da frota.--kubeconfig
O caminho para o arquivokubeconfig
. É possível especificar um caminho relativo ou completo. A variável de ambiente$PWD
não funciona aqui.--output_dir
Inclua essa opção para especificar um diretório em queasmcli
faz o download do pacoteanthos-service-mesh
e extrai o arquivo de instalação, que contémistioctl
, amostras e manifestos. Caso contrário,asmcli
fará o download dos arquivos para um diretóriotmp
. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente$PWD
não funciona aqui.-
--enable_all
Permite que a ferramenta:- Conceder as permissões necessárias do IAM.
- Ative as APIs do Google necessárias.
- Defina um rótulo no cluster que identifique a malha.
- Registre o cluster na frota se ele ainda não estiver registrado.
-ca citadel
Para evitar a inatividade, especifique a CA do Istio. A opçãocitadel
corresponde à CA do Istio. Não mude para a CA da malha neste momento.--ca_cert
: o certificado intermediário.--ca_key
: a chave do certificado intermediário--root_cert
: o certificado raiz.--cert_chain
: a cadeia de certificados.--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.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 é sempreistio.io/rev
. Por padrão, a ferramenta define o valor do rótulo de revisão com base na versão do Anthos Service Mesh, por exemplo:asm-1232-2
. Recomendamos que você inclua essa opção e substituaREVISION_1
por um nome que descreva a instalação, comoasm-1232-2-distribute-root
. O nome precisa ser um identificador DNS-1035 e conter caracteres alfanuméricos minúsculos ou-
, começar com um caractere alfabético e terminar com um caractere alfanumérico (comomy-name
ouabc-123
).
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=<var>REVISION_1</var>-distribute-root
e reiniciar suas
cargas de trabalho. Ao testar as cargas de trabalho depois de reiniciá-las, execute uma
ferramenta 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 da ferramenta de validação:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
Defina o bit executável na ferramenta:
chmod +x migrate_ca
A ferramenta
migrate_ca
chamaistioctl
, que depende da versão. A ferramentaasmcli
adiciona um link simbólico aistioctl
no diretório especificado para--output_dir
. Verifique se o diretório está no início do seu caminho. No comando a seguir, substituaISTIOCTL_PATH
pelo diretório que contémistioctl
que a ferramenta fez o download.export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
Consiga o rótulo de revisão em
istiod
e oistio-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ê executouasmcli install
. Neste exemplo, o valor éasm-1232-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 daistiod
antiga. A saída de exemplo mostra uma migração do Istio, que está usando a revisãodefault
.
Adicione o rótulo de revisão a um namespace e remova o rótulo
istio-injection
, se ele existir. No comando a seguir, substituaNAMESPACE
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ótuloistio-injection
anteriormente. Como o comportamento da injeção automática é indefinido quando um namespace tem os rótulosistio-injection
e de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh garantem explicitamente que apenas um seja definido.Reinicie os pods para acionar a nova injeção:
kubectl rollout restart deployment -n NAMESPACE
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ê precisar migrar gateways, siga as etapas em Upgrades Canary (avançado) para instalar novas implantações do gateway. Lembre-se do seguinte:
- Use
REVISION_1
como o rótulo de revisão. - Implante os recursos de gateway no mesmo namespace que o gateway da instalação mais antiga para realizar a migração sem inatividade. Verifique se os recursos de serviço que apontam para o gateway mais antigo também devem incluir as implantações mais novas.
- Não exclua as implantações de gateway mais antigas até ter certeza de que o aplicativo está funcionando corretamente (após a próxima etapa).
- Use
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.
Altere para o diretório em que os arquivos do repositório
anthos-service-mesh
do GitHub estão localizados.Configure o webhook de validação para usar o novo plano de controle.
kubectl apply -f asm/istio/istiod-service.yaml
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 doistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
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 deistiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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:Exclua as novas implantações de gateway instaladas como parte da etapa 11.
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 ouistio-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
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
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
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
Remova a nova revisão de
istiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
Remova a nova configuração
IstioOperator
.kubectl delete IstioOperator installed-state-asm-1232-2-distribute-root -n istio-system
A saída esperada será assim:
istiooperator.install.istio.io "installed-state-asm-1232-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 asmcli install
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
asmcli install
.Execute
asmcli install
. No comando a seguir, substitua os marcadores pelos valores../asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --enable_all \ --ca mesh_ca \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
--fleet_id
O ID do projeto host da frota.--kubeconfig
O caminho para o arquivokubeconfig
. É possível especificar um caminho relativo ou completo. A variável de ambiente$PWD
não funciona aqui.--output_dir
Inclua essa opção para especificar um diretório em queasmcli
faz o download do pacoteanthos-service-mesh
e extrai o arquivo de instalação, que contémistioctl
, amostras e manifestos. Caso contrário,asmcli
fará o download dos arquivos para um diretóriotmp
. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente$PWD
não funciona aqui.-
--enable_all
Permite que a ferramenta:- Conceder as permissões necessárias do IAM.
- Ative as APIs do Google necessárias.
- Defina um rótulo no cluster que identifique a malha.
- Registre o cluster na frota se ele ainda não estiver registrado.
--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.REVISION_2
Recomendado. SubstituaREVISION_2
por um nome que descreva a instalação, comoasm-1232-2-meshca-ca-migration
. O nome precisa ser um identificador DNS-1035 e conter caracteres alfanuméricos minúsculos ou-
, começar com um caractere alfabético e terminar com um caractere alfanumérico (comomy-name
ouabc-123
).--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 oistio-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-1232-2-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1232-2-distribute-root istio-ingressgateway-asm-1232-2-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1232-2-distribute-root istio-ingressgateway-asm-1232-2-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1232-2-meshca-ca-migration istio-ingressgateway-asm-1232-2-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1232-2-meshca-ca-migration istiod-asm-1232-2-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1232-2-distribute-root istiod-asm-1232-2-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1232-2-distribute-root istiod-asm-1232-2-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1232-2-meshca-ca-migration istiod-asm-1232-2-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1232-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-1232-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 doistiod
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-1232-2-distribute-root
".
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
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.
Siga as etapas descritas em Upgrades no local para fazer upgrade das implantações de gateway mais antigas instaladas na etapa 11 da seção anterior para a revisão mais recente.
REVISION_2
.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.
Altere para o diretório em que os arquivos do repositório
anthos-service-mesh
do GitHub estão localizados.Configure o webhook de validação para usar o novo plano de controle.
kubectl apply -f asm/istio/istiod-service.yaml
Exclua a implantação
istio-ingressgateway
antiga. No comando a seguir, substituaOLD_REVISION
pelo rótulo de revisão da versão anterior doistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Exclua a revisão
istiod
antiga. No comando a seguir, substituaOLD_REVISION
pelo rótulo de revisão da versão anterior deistiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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:Siga as etapas emUpgrades no local para fazer downgrade das implantações de gateway com upgrade anteriormenteetapa 6 desta seção a revisão mais antiga
REVISION_1
de dados.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
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
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
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
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
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