Migração baseada em canário para a autoridade certificadora do Cloud Service Mesh

"><br

Migrar para a autoridade de certificação do Cloud Service Mesh (autoridade de certificação do Cloud Service Mesh) da CA do Istio (também conhecida como Citadel) requer a migração da raiz de confiança. Antes do Cloud Service Mesh 1.10, se você quisesse migrar do Istio no Google Kubernetes Engine (GKE) para o Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh, era necessário programar o tempo de inatividade porque o Cloud Service Mesh não conseguia 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. O cluster inteiro só se recupera totalmente quando o plano de controle e todas as cargas de trabalho em todos os namespaces são reimplantados com o certificado da autoridade de certificação do Cloud Service Mesh. 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 no GKE para o plano de controle no cluster do Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh.
  • Faça upgrade do Cloud Service Mesh com o Istio CA para o plano de controle no cluster do Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh.

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:

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 autoridade de certificação da CA do Istio e do Cloud Service Mesh.
  • O certificado mTLS da carga de trabalho emitido pela Istio CA e pela autoridade de certificação do Cloud Service Mesh.
  • Os domínios de confiança configurados pela autoridade de certificação da CA do Istio e do Cloud Service Mesh.

Essa ferramenta tem as seguintes dependências:

  • awk
  • grep
  • istioctl A execução de asmcli install faz o download da versão de istioctl que corresponde à versão do Cloud Service Mesh que você está instalando.
  • jq
  • kubectl
  • openssl

Visão geral da migração

Para migrar para a autoridade de certificação do Cloud Service Mesh, siga o processo baseado em revisão, também chamado de "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 são totalmente funcionais entre as cargas de trabalho que usam a autoridade de certificação do Cloud Service Mesh e as cargas de trabalho que usam a CA do Istio.

Confira a seguir um resumo da migração para a autoridade de certificação do Cloud Service Mesh:

  1. Distribua a raiz de confiança da autoridade certificadora do Cloud Service Mesh.

    1. 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 autoridade de certificação do Cloud Service Mesh.

    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.

  2. Migre para a autoridade de certificação do Cloud Service Mesh. Agora que todos os proxies sidecar estão configurados com a raiz de confiança antiga e a raiz de confiança da autoridade de certificação do Cloud Service Mesh, é possível migrar para a autoridade de certificação do Cloud Service Mesh sem inatividade. Novamente, você segue o processo de migração baseado em revisão:

    1. Instale uma revisão do plano de controle com a autoridade certificadora do Cloud Service Mesh 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 da autoridade certificadora do Cloud Service Mesh

Antes de migrar para a autoridade certificadora do Cloud Service Mesh, todos os clusters do GKE na malha precisam ter o Cloud Service Mesh 1.10 ou mais recente. Além disso, todos os clusters precisam ser configurados com uma opção de plano de controle que aciona a raiz de confiança para que a autoridade de certificação do Cloud Service Mesh seja distribuída para os 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 autoridade de certificação do Cloud Service Mesh, as cargas de trabalho que usam a autoridade de certificação do Cloud Service Mesh poderão ser autenticadas com as cargas de trabalho usando a CA antiga.

Instalar uma nova revisão do plano de controle

Instale uma revisão do plano de controle com uma opção que distribua a raiz de confiança da autoridade de certificação do Cloud Service Mesh.

  1. 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.

  2. Verifique se você tem a versão do asmcli que instala o Cloud Service Mesh 1.11 ou mais recente:

    ./asmcli --version

  3. 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 arquivo kubeconfig. É 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 que asmcli faz o download do pacote anthos-service-mesh e extrai o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É 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ção "citadel" corresponde à CA do Istio). Não mude para a autoridade de certificação do Cloud Service Mesh 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](/service-mesh/docs/revisions-overview) é 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, a ferramenta define o valor do rótulo de revisão com base na versão do Cloud Service Mesh, por exemplo: . Recomendamos que você inclua essa opção e substitua REVISION_1 por um nome que descreva a instalação, como -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).

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 suas cargas de trabalho depois de reiniciá-las, você executa uma ferramenta para validar se o proxy sidecar está configurado com a raiz de confiança antiga e nova para a autoridade de certificação do Cloud Service Mesh.

  1. 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

  2. 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

  3. Defina o bit executável na ferramenta:

    chmod +x migrate_ca

  4. A ferramenta migrate_ca chama istioctl, que depende da versão. A ferramenta asmcli 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 a ferramenta fez o download.

    export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH

  5. 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

    1. 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 asmcli install. Neste exemplo, o valor é -distribute-root.

    2. 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.

  6. 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 o comportamento da injeção automática é indefinido quando um namespace tem o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas um seja definido.

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

    kubectl rollout restart deployment -n NAMESPACE

  8. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.

  9. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.

  10. 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]

  11. 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).

  12. 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 de você estar migrando do Istio ou fazendo upgrade de uma versão anterior do Cloud 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ê fez upgrade de uma versão anterior do Cloud 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 se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Cloud Service Mesh.

      Migrar

      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 Cloud 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 anterior da configuração 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. Exclua as novas implantações de gateway instaladas como parte da etapa 11.

    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--distribute-root -n istio-system

      A saída esperada será assim:

      istiooperator.install.istio.io "installed-state--distribute-root" deleted

Migre para a autoridade certificadora do Cloud Service Mesh

Agora que os proxies sidecar de todas as cargas de trabalho estão configurados com a raiz de confiança antiga e a nova para a autoridade de certificação do Cloud Service Mesh, as etapas para migrar para a autoridade de certificação do Cloud Service Mesh são semelhantes às que você fez para distribuir a raiz de confiança da autoridade certificadora do Cloud Service Mesh:

Instalar um novo plano de controle com a autoridade certificadora do Cloud Service Mesh ativada

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

  1. Se você tiver personalizado a instalação anterior, precisará especificar os mesmos arquivos de sobreposição ao executar asmcli install.

  2. 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 arquivo kubeconfig. É 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 que asmcli faz o download do pacote anthos-service-mesh e extrai o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É 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 mudar para a autoridade de certificação do Cloud Service Mesh, já que a raiz de confiança da autoridade de certificação do Cloud Service Mesh foi distribuída.
      • REVISION_2 Recomendado. Substitua REVISION_2 por um nome que descreva a instalação, como -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 (como my-name ou abc-123).
      • --option ca-migration-migration Quando você [reimplanta suas cargas de trabalho](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), essa opção configura os proxies para usar a raiz de confiança da autoridade certificadora do Cloud Service Mesh.

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.

  1. 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--distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   -distribute-root
istio-ingressgateway--distribute-root65d884685d-94wgz       1/1     Running   0          67m   -distribute-root
istio-ingressgateway--meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    -meshca-ca-migration
istio-ingressgateway--meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   -meshca-ca-migration
istiod--distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   -distribute-root
istiod--distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   -distribute-root
istiod--meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   -meshca-ca-migration
istiod--meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   -meshca-ca-migration

    1. Na saída, na coluna REV, anote o valor do rótulo de revisão da nova versão. Neste exemplo, o valor é -meshca-ca-migration.

    2. Observe também o valor no identificador de revisão da versão anterior do istiod. Isso é necessário para excluir a versão anterior do istiod quando você 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 é "-distribute-root".

  2. 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

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

    kubectl rollout restart deployment -n NAMESPACE

  4. 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.

  5. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.

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

  7. 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. 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 antigaREVISION_1 de dados.

    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

  1. 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

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

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

  3. 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