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 scriptinstall_asm
, ele 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 com uma opção que distribuirá a raiz de confiança da CA da malha.
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 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 é sempreistio.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 substituaREVISION_1
por um nome que descreva a instalação, comoasm-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, comomy-name'
ouabc-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 pacoteanthos-service-mesh
e do arquivo de instalação do Anthos Service Mesh, que contémistioctl
, 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çãocitadel
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
chamaistioctl
, que depende da versão. O scriptinstall_asm
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 o script 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ê executouinstall_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 daistiod
antiga. A saída de exemplo mostra uma migração do Istio, que está usando a revisãodefault
.
Alterne
istio-ingressgateway
para a nova revisão. No comando a seguir, verifique seREVISION_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, 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 a injeção automática falha se um namespace tiver oistio-injection
e o rótulo de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do rótuloistio-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.
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:Volte para a versão antiga de
istio-ingressgatewqy
. No comando a seguir, substituaOLD_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"}]'
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-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. SubstituaREVISION_2
por um nome que descreva a instalação, comoasm-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, comomy-name'
ouabc-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 pacoteanthos-service-mesh
e do arquivo de instalação do Anthos Service Mesh, que contémistioctl
, 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 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-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 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-1106-2-distribute-root
".
Alterne
istio-ingressgateway
para a nova revisão. No comando a seguir, altereREVISION_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.
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:Volte para a
istio-ingressgatewqy
anterior. No comando a seguir, substituaOLD_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"}]'
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