Migração baseada em testes canários para a autoridade de certificação do Cloud Service Mesh

A migração para a autoridade de certificação do Cloud Service Mesh (autoridade de certificação do Cloud Service Mesh) a partir da AC do Istio (também conhecida como Citadel) requer a migração da raiz de confiança. Antes do Cloud Service Mesh 1.10, se quisesse migrar do Istio no Google Kubernetes Engine (GKE) para o Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh, tinha de agendar tempo de inatividade porque o Cloud Service Mesh não conseguia carregar vários certificados de raiz. Por conseguinte, durante a migração, as cargas de trabalho implementadas recentemente confiam no novo certificado de raiz, enquanto outras confiam no certificado de raiz antigo. As cargas de trabalho que usam certificados assinados por certificados de raiz diferentes não podem autenticar-se entre si. Isto significa que o tráfego de TLS mútuo (mTLS) é interrompido durante a migração. O cluster completo só é totalmente recuperado quando o plano de controlo e todas as cargas de trabalho em todos os espaços de nomes são reimplementados com o certificado da autoridade de certificação do Cloud Service Mesh. Se a sua malha tiver vários clusters com cargas de trabalho que enviam pedidos para cargas de trabalho noutro cluster, todas as cargas de trabalho nesses clusters também têm de ser atualizadas.

Use os passos neste guia para os seguintes exemplos de utilização:

  • Migre do Istio no GKE para o plano de controlo no cluster do Cloud Service Mesh 1.19.10-asm.9 com a autoridade de certificação do Cloud Service Mesh.
  • Atualize do Cloud Service Mesh 1.15 or a 1.16 patch release com a AC do Istio para o plano de controlo no cluster do Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh. 1.19.10-asm.9

Limitações

  • Todos os clusters do GKE têm de estar no mesmo Google Cloud projeto.

Pré-requisitos

Siga os passos em Instale ferramentas dependentes e valide o cluster para:

Ferramentas necessárias

Durante a migração, executa uma ferramenta fornecida pela Google, migrate_ca, para validar o seguinte para cada Pod no cluster:

  • O certificado de raiz para a AC do Istio e a autoridade de certificação do Cloud Service Mesh.
  • O certificado mTLS da carga de trabalho emitido pela AC do Istio e pela autoridade de certificação do Cloud Service Mesh.
  • Os domínios de confiança configurados pela AC do Istio e pela autoridade de certificação da malha de serviço na nuvem.

Esta ferramenta tem as seguintes dependências:

  • awk
  • grep
  • istioctl A execução do comando asmcli install transfere a versão do istioctl que corresponde à versão do Cloud Service Mesh que está a instalar.
  • jq
  • kubectl
  • openssl

Vista geral da migração

Para migrar para a autoridade de certificação do Cloud Service Mesh, segue o processo de migração baseado em revisões (também conhecido como "atualização canary"). Com uma migração baseada em revisões, é implementada uma nova revisão do plano de controlo juntamente com o plano de controlo existente. Em seguida, move gradualmente as suas cargas de trabalho para a nova revisão, o que lhe permite monitorizar 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 cargas de trabalho que usam a autoridade de certificação do Cloud Service Mesh e cargas de trabalho que usam a AC do Istio.

Segue-se um resumo da migração para a autoridade de certificação do Cloud Service Mesh:

  1. Distribua a raiz fidedigna da autoridade de certificação do Cloud Service Mesh.

    1. Instale uma nova revisão do plano de controlo que use a CA do Istio com uma opção que distribua a raiz de confiança da autoridade de certificação do Cloud Service Mesh.

    2. Migre cargas de trabalho para o novo plano de controlo, espaço de nomes por espaço de nomes, e teste a sua aplicação. Quando todas as cargas de trabalho forem migradas com êxito para o novo plano de controlo, remova o plano de controlo 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, pode migrar para a autoridade de certificação do Cloud Service Mesh sem tempo de inatividade. Mais uma vez, segue o processo de migração baseado em revisões:

    1. Instale uma revisão do plano de controlo com a autoridade de certificação do Cloud Service Mesh ativada.

    2. Migre as cargas de trabalho para a nova revisão do plano de controlo, espaço de nomes por espaço de nomes, e teste a sua aplicação. Quando todas as cargas de trabalho forem migradas com êxito para o novo plano de controlo, remova o plano de controlo antigo.

    3. Remova os segredos da CA no cluster associados à CA antiga e reinicie o novo plano de controlo.

Distribua a raiz fidedigna da autoridade de certificação do Cloud Service Mesh

Antes de poder migrar para a autoridade de certificação do Cloud Service Mesh, todos os clusters do GKE na malha têm de ter o Cloud Service Mesh 1.10 ou posterior, e todos os clusters têm de estar configurados com uma opção de plano de controlo que aciona a raiz de confiança da autoridade de certificação do Cloud Service Mesh a ser distribuída aos proxies de todas as cargas de trabalho no cluster. Quando o processo terminar, cada proxy é configurado com a raiz de confiança antiga e a nova. Com este esquema, quando 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 vão poder fazer a autenticação com cargas de trabalho que usam a AC antiga.

Instale uma nova revisão do plano de controlo

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

  1. Siga os passos em Instale ferramentas dependentes e valide o cluster para se preparar para usar uma ferramenta fornecida pela Google, asmcli, para instalar a nova revisão do plano de controlo.

  2. Certifique-se de que tem a versão do asmcli que instala o Cloud Service Mesh 1.11 ou superior:

    ./asmcli --version

  3. Corrida asmcli install. No comando seguinte, substitua os marcadores de posição pelos seus 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 do projeto anfitrião da frota.
  • --kubeconfig O caminho para o ficheiro kubeconfig Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  • --output_dir Inclua esta opção para especificar um diretório onde o asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  • --enable_all Permite que a ferramenta:
    • Conceda as autorizações de IAM necessárias.
    • Ative as APIs Google necessárias.
    • Defina uma etiqueta no cluster que identifique a malha.
    • Registe o cluster na frota, se ainda não estiver registado.
  • -ca citadel Para evitar o tempo de inatividade, especifique a CA do Istio (a opção `citadel` corresponde à CA do Istio). Não mude para a autoridade de certificação da malha de serviços na nuvem neste momento.
  • --ca_cert O certificado intermédio.
  • --ca_key A chave do certificado intermédio
  • --root_cert O certificado de raiz.
  • --cert_chain A cadeia de certificados.
  • --option ca-migration-citadel Quando implementa novamente as suas cargas de trabalho, esta opção aciona a distribuição da nova raiz de fidedignidade para os proxies sidecar das cargas de trabalho.
  • REVISION_1: recomendado. Uma etiqueta de revisão é um par de chave-valor que é definido no plano de controlo. A chave da etiqueta de revisão é sempre istio.io/rev. Por predefinição, a ferramenta define o valor da etiqueta de revisão com base na versão do Cloud Service Mesh, por exemplo: asm-11910-9. Recomendamos que inclua esta opção e substitua REVISION_1 por um nome que descreva a instalação, como asm-11910-9-distribute-root. O nome tem de ser uma etiqueta DNS-1035 e tem de consistir em carateres alfanuméricos em minúsculas ou -, começar com um caráter do alfabeto e terminar com um caráter alfanumérico (como my-name ou abc-123).

Migre cargas de trabalho para o novo plano de controlo

Para terminar a distribuição da nova raiz de confiança, tem de etiquetar os seus namespaces com a etiqueta de revisão istio.io/rev=<var>REVISION_1</var>-distribute-root e reiniciar as suas cargas de trabalho. Quando testar as cargas de trabalho depois de as reiniciar, execute 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 seguinte, altere --region para --zone se tiver um cluster de zona única.

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

  2. Transfira a 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 que especificou para --output_dir. Certifique-se de que o diretório está no início do caminho. No comando seguinte, substitua ISTIOCTL_PATH pelo diretório que contém istioctl que a ferramenta transferiu.

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

  5. Obtenha a etiqueta de revisão que está em istiod e istio-ingressgateway.

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

    O resultado é semelhante ao seguinte:

    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. No resultado, na coluna REV, tome nota do valor da etiqueta de revisão da nova revisão, que corresponde à etiqueta de revisão que especificou quando executou asmcli install. Neste exemplo, o valor é asm-11910-9-distribute-root.

    2. Tem de eliminar a revisão antiga de istiod quando terminar de mover as cargas de trabalho para a nova revisão. Tenha em atenção o valor na etiqueta de revisão da revisão istiod antiga. O resultado de exemplo mostra uma migração do Istio, que está a usar a revisão default.

  6. Adicione a etiqueta de revisão a um espaço de nomes e remova a etiqueta istio-injection (se existir). No comando seguinte, substitua NAMESPACE pelo espaço de nomes a etiquetar.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite

    Se vir "istio-injection not found" na saída, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que o comportamento de injeção automática não está definido quando um espaço de nomes tem a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas uma está definida.

  7. Reinicie os pods para acionar a reinjeção.

    kubectl rollout restart deployment -n NAMESPACE

  8. Teste a sua aplicação para verificar se as cargas de trabalho estão a funcionar corretamente.

  9. Se tiver cargas de trabalho noutros espaços de nomes, repita os passos para etiquetar o espaço de nomes e reinicie os pods.

  10. Valide se os proxies sidecar para todas as cargas de trabalho no cluster estão configurados com os certificados de raiz antigos e novos:

    ./migrate_ca check-root-cert

    Resultado esperado:

    Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

  11. Se precisar de migrar gateways, siga os passos em Atualizações canárias (avançadas) para instalar novas implementações de gateways. Tenha em atenção os seguintes pontos:

    • Use REVISION_1 como etiqueta de revisão.
    • Implemente os recursos de gateway no mesmo espaço de nomes que o gateway da instalação mais antiga para fazer uma migração sem tempo de inatividade. Certifique-se de que os recursos de serviço que apontam para o gateway mais antigo também incluem agora as implementações mais recentes.
    • Não elimine as implementações de gateway mais antigas até ter a certeza de que a sua aplicação está a funcionar corretamente (após o passo seguinte).

  12. Se tiver a certeza de que a sua aplicação está a funcionar como esperado, continue com os passos para fazer a transição para a nova versão da istiod. Se houver um problema com a sua aplicação, siga os passos para reverter.

    Conclua a transição

    Se tiver a certeza de que a sua aplicação está a funcionar como esperado, remova o plano de controlo antigo para concluir a transição para a nova versão.

    1. Altere para o diretório onde se encontram os ficheiros do repositório do GitHub.anthos-service-mesh

    2. Configure o webhook de validação para usar o novo plano de controlo.

      kubectl apply -f asm/istio/istiod-service.yaml

    3. Elimine a istio-ingressgatewayimplementação antiga. O comando que executa depende de estar a migrar do Istio ou a atualizar a partir de uma versão anterior do Cloud Service Mesh:

      Migrar

      Se migrou do Istio, o istio-ingressgateway antigo não tem uma etiqueta de revisão.

      kubectl delete deploy/istio-ingressgateway -n istio-system

      Atualizar

      Se fez a atualização a partir de uma versão anterior do Cloud Service Mesh, no comando seguinte, substitua OLD_REVISION pela etiqueta 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. Elimine a revisão antiga de istiod. O comando que usa depende de estar a migrar do Istio ou a atualizar a partir de uma versão anterior do Cloud Service Mesh.

      Migrar

      Se migrou do Istio, o istio-ingressgateway antigo não tem uma etiqueta de revisão.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

      Atualizar

      Se fez a atualização a partir de uma versão anterior do Cloud Service Mesh, no comando seguinte, certifique-se de que OLD_REVISION corresponde à etiqueta de revisão da versão anterior do 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

      O resultado esperado é semelhante ao seguinte:

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    Reversão

    Se encontrou um problema ao testar a sua aplicação com a nova versão do istiod, siga estes passos para reverter para a versão anterior:

    1. Elimine as novas implementações de gateways instaladas como parte do passo 11.

    2. Volte a etiquetar o seu espaço de nomes para ativar a injeção automática com a versão anterior do istiod. O comando que usa depende de ter usado ou não uma etiqueta de revisão istio-injection=enabled com a versão anterior.

      • Se usou uma etiqueta de revisão para a injeção automática:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      • Se usou o istio-injection=enabled:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

      Resultado esperado:

      namespace/NAMESPACE labeled

    3. Confirme que a etiqueta de revisão no espaço de nomes corresponde à etiqueta de revisão na versão anterior de istiod:

      kubectl get ns NAMESPACE --show-labels

    4. Reinicie os agrupamentos para acionar a reinjeção, para que os proxies tenham a versão anterior:

      kubectl rollout restart deployment -n NAMESPACE

    5. Remova a nova implementaçã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 de IstioOperator.

      kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system

      O resultado esperado é semelhante ao seguinte:

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

Migre para a autoridade de certificação do Cloud Service Mesh

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

Instale um novo plano de controlo com a autoridade de certificação do Cloud Service Mesh ativada

Usa asmcli install para instalar uma nova revisão do plano de controlo com a CA de malha ativada.

  1. Se personalizou a instalação anterior, tem de especificar os mesmos ficheiros de sobreposição quando executar asmcli install.

  2. Corrida asmcli install. No comando seguinte, substitua os marcadores de posição pelos seus valores.

     ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --enable_all \
   --ca mesh_ca \
   --option ca-migration-meshca \
  --revision_name REVISION_2 \
  OVERLAYS
      • --fleet_id O ID do projeto do projeto anfitrião da frota.
      • --kubeconfig O caminho para o ficheiro kubeconfig Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
      • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
      • --enable_all Permite que a ferramenta:
        • Conceda as autorizações de IAM necessárias.
        • Ative as APIs Google necessárias.
        • Defina uma etiqueta no cluster que identifique a malha.
        • Registe o cluster na frota se ainda não estiver registado.
      • --ca mesh_ca Já pode mudar para a autoridade de certificação do Cloud Service Mesh, uma vez 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 asm-11910-9-meshca-ca-migration. O nome tem de ser uma etiqueta DNS-1035 e tem de consistir em carateres alfanuméricos em minúsculas ou -, começar com um caráter do alfabeto e terminar com um caráter alfanumérico (como my-name ou abc-123).
      • --option ca-migration-migration Quando [implementa novamente as suas cargas de trabalho](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), esta opção configura os proxies para usar a raiz de confiança da autoridade de certificação do Cloud Service Mesh.

Migre cargas de trabalho para o novo plano de controlo

Para concluir a instalação, tem de etiquetar os seus espaços de nomes com a nova etiqueta de revisão e reiniciar as cargas de trabalho.

  1. Obtenha a etiqueta de revisão que está em istiod e istio-ingressgateway.

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

    O resultado é semelhante ao seguinte:

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

    1. Na saída, na coluna REV, tome nota do valor da etiqueta de revisão para a nova versão. Neste exemplo, o valor é asm-11910-9-meshca-ca-migration.

    2. Tenha também em atenção o valor na etiqueta de revisão da versão istiod anterior. Precisa desta opção para eliminar a versão anterior do istiod quando terminar de mover as cargas de trabalho para a nova versão. No exemplo, o valor da etiqueta de revisão para a revisão anterior é asm-11910-9-distribute-root.

  2. Adicione a nova etiqueta de revisão a um espaço de nomes. No comando seguinte, substitua NAMESPACE pelo espaço de nomes a etiquetar.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite

  3. Reinicie os pods para acionar a reinjeção.

    kubectl rollout restart deployment -n NAMESPACE

  4. Teste a sua aplicação para verificar se as cargas de trabalho estão a funcionar corretamente. Certifique-se de que a comunicação mTLS funciona entre cargas de trabalho no espaço de nomes mais antigo e cargas de trabalho no espaço de nomes mais recente.

  5. Se tiver cargas de trabalho noutros espaços de nomes, repita os passos para etiquetar o espaço de nomes e reinicie os pods.

  6. Siga os passos descritos em Atualizações no local para atualizar as implementações de gateway mais antigas instaladas no passo 11 da secção anterior para a revisão mais recente REVISION_2.

  7. Se tiver a certeza de que a sua aplicação está a funcionar como esperado, continue com os passos para fazer a transição para o novo plano de controlo. Se houver um problema com a sua aplicação, siga os passos para reverter.

    Conclua a transição

    Se tiver a certeza de que a sua aplicação está a funcionar como esperado, remova o plano de controlo antigo para concluir a transição para a nova versão.

    1. Altere para o diretório onde se encontram os ficheiros do repositório do GitHub.anthos-service-mesh

    2. Configure o webhook de validação para usar o novo plano de controlo.

      kubectl apply -f asm/istio/istiod-service.yaml

    3. Elimine a istio-ingressgatewayimplementação antiga. No comando seguinte, substitua OLD_REVISION pela etiqueta 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. Elimine a revisão antiga istiod. No comando seguinte, substitua OLD_REVISION pela etiqueta 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 antiga IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      O resultado esperado é semelhante ao seguinte:

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    Reversão

    Se encontrou um problema ao testar a sua aplicação com a nova revisão istiod, siga estes passos para reverter para a revisão anterior:

    1. Siga os passos em Atualizações no local para alterar para uma versão anterior as implementações de gateways atualizadas anteriormente no passo 6 desta secção para a revisão mais antiga REVISION_1.

    2. Volte a etiquetar o seu espaço de nomes para ativar a injeção automática com a revisão istiod anterior.

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      Resultado esperado:

      namespace/NAMESPACE labeled

    3. Confirme que a etiqueta de revisão no espaço de nomes corresponde à etiqueta de revisão na versão anterior de istiod:

      kubectl get ns NAMESPACE --show-labels

    4. Reinicie os agrupamentos para acionar a reinjeção, para que os proxies tenham a versão anterior:

      kubectl rollout restart deployment -n NAMESPACE

    5. Remova a nova implementaçã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 do istiod. Certifique-se de que a etiqueta de revisão no comando seguinte corresponde à 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

      O resultado esperado é semelhante ao seguinte:

      istiooperator.install.istio.io "installed-state-REVISION_2" deleted

Remova os segredos da AC e reinicie o novo plano de controlo

  1. Preserve secrets caso precise deles:

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

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

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

  3. Reinicie o plano de controlo recém-instalado. Isto garante que a raiz de confiança antiga é limpa de todas as cargas de trabalho em execução na malha.

    kubectl rollout restart deployment -n istio-system