Faça upgrade do Anthos Service Mesh.

Visualização — asmcli

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Nesta página, descrevemos como:

• Execute asmcli para fazer upgrade do Anthos Service Mesh ou do Istio de código aberto 1.9 or a 1.10 patch release para o Anthos Service Mesh 1.10.6. Upgrades de versões anteriores não são compatíveis.

• Faça um upgrade canário para migrar as cargas de trabalho para o novo plano de controle.

Observação: a adição de máquinas virtuais do Compute Engine à malha de serviço requer opções específicas ao fazer upgrade do Anthos Service Mesh. Para ver as etapas detalhadas, consulte Adicionar máquinas virtuais do Compute Engine ao Anthos Service Mesh.

Antes de começar

Antes de começar, verifique se você:

• Revise os pré-requisitos. No momento, asmcli não é compatível com o upgrade do Anthos Service Mesh em clusters do GKE que estão em uma malha de vários clusters em projetos diferentes, a menos que você tenha instalado inicialmente o Anthos Service Mesh usando asmcli.
• Leia as informações em Planejar o upgrade.
• Instalar as ferramentas necessárias
• Fazer o download de asmcli
• Conceder permissões de administrador de cluster
• Validar o projeto e o cluster

Personalizações do plano de controle

Se você tiver personalizado a instalação anterior, precisará das mesmas personalizações quando fizer upgrade para uma nova versão do Anthos Service Mesh ou migrar do Istio. Se você tiver personalizado a instalação adicionando a sinalização --set values em istioctl install, será necessário adicionar essas configurações a um arquivo YAML IstioOperator, chamado de arquivo de sobreposição. Especifique o arquivo de sobreposição usando a opção --custom_overlay com o nome de arquivo ao executar o script. O script transfere o arquivo de sobreposição para istioctl install.

Atenção: omitir o arquivo de sobreposição resulta em uma instalação bem-sucedida. No entanto, a malha de serviço tem uma configuração diferente da pretendida porque os valores omitidos são redefinidos para os padrões quando o plano de controle e o gateway de entrada são reimplantados.

Autoridade de certificação

Alterar a autoridade de certificação (CA) durante um upgrade causa inatividade. Durante o upgrade, o tráfego mTLS é interrompido até que todas as cargas de trabalho sejam alteradas para usar o novo plano de controle com a nova CA.

Faça upgrade do Anthos Service Mesh.

Veja a seguir como fazer upgrade do Anthos Service Mesh:

1. Execute asmcli install para instalar o Anthos Service Mesh em um único cluster. Consulte as seções a seguir para exemplos de linha de comando. Os exemplos contêm argumentos obrigatórios e opcionais que podem ser úteis. É recomendável sempre especificar o argumento output_dir para que seja possível localizar facilmente gateways de amostra e ferramentas como istioctl. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

2. Como opção, instale ou faça upgrade de um gateway de entrada.

3. Para concluir a configuração do Anthos Service Mesh, ative a injeção automática do arquivo secundário e implante ou reimplante cargas de trabalho.

Fazer upgrade com recursos padrão e Mesh CA

Nesta seção, mostramos como executar o asmcli para fazer upgrade do Anthos Service Mesh com os recursos compatíveis padrão para sua plataforma e ativar a autoridade de certificação do Anthos Service Mesh (Mesh CA) como certificado autoridade.

GKE;

Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
• --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
• --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia 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 o script:
  • 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 Use a Mesh CA como a autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota

No local

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --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 esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia 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.
   • --platform multicloud Especifica que a plataforma é local.
   • --enable_all Permite que o script:
     • 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 Use a Mesh CA como a autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. asmcliconfigura a CA da malha para usar a identidade da carga de trabalho da frota

Fazer upgrade dos recursos padrão com a CA do Istio

Nesta seção, mostramos como executar o asmcli para fazer upgrade do Anthos Service Mesh com os recursos compatíveis padrão para sua plataforma e ativar o CA do Istio.

GKE

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

• --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
• --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
• --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia 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 o script:
  • 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 Use o CA do Istio. Alterar as autoridades de certificação durante um upgrade causa inatividade.

No local

1. Defina o contexto atual para o cluster de usuário:

    kubectl config use-context CLUSTER_NAME
   

2. Execute o seguinte comando para instalar o Anthos Service Mesh com recursos padrão e a CA do Istio:

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --output_dir DIR_PATH \
      --platform multicloud \
      --enable_all \
      --ca citadel \
   

   • --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 esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia 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.
   • --platform multicloud Especifica que a plataforma é local.
   • --enable_all Permite que o script:
     • 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 Use o CA do Istio. Alterar a autoridade de certificação (CA) durante um upgrade causa inatividade.

Fazer upgrade com recursos opcionais

Um arquivo de sobreposição é um arquivo YAML contendo um recurso personalizado (CR) IstioOperator que você passa para asmcli para configurar o plano de controle. É possível substituir a configuração do plano de controle padrão e ativar um recurso opcional transmitindo o arquivo YAML para asmcli. É possível usar mais camadas, e cada arquivo de sobreposição substitui a configuração nas camadas anteriores.

GKE;

Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
• --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
• --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia 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 o script:
  • 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 Use a Mesh CA como a autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota
• --custom_overlay especifica o nome do arquivo de sobreposição.

No local

1. Defina o contexto atual para o cluster de usuário:

   kubectl config use-context CLUSTER_NAME
   

2. Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --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 esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia 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.
   • --platform multicloud Especifica que a plataforma é local.
   • --enable_all Permite que o script:
     • 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 Use a Mesh CA como a autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota
   • --custom_overlay especifica o nome do arquivo de sobreposição.

Fazer upgrade de gateways

Se você tiver gateways implantados, será necessário atualizá-los também. Para fazer um upgrade simples, siga a seção "Upgrades no local" no guia Instalar e atualizar gateways.

Aviso: se você instalou o Anthos Service Mesh com qualquer método diferente de asmcli, o gateway de entrada padrão instalado será removido, a menos que você transmita o argumento --option legacy-default-ingressgateway.

Alternar para o novo plano de controle

1. Receba o rótulo de revisão que está em istiod.

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

   A saída deste comando é semelhante a:

   NAME                                             READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

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

   2. Observe também o valor no rótulo de revisão da versão istiod antiga. Você precisará dele para excluir a versão antiga do istiod ao terminar de mover as cargas de trabalho para a nova versão. No exemplo de saída, o valor do rótulo de revisão da versão antiga é asm-198-3.

2. Adicione o rótulo de revisão a um namespace de aplicativo e remova o rótulo istio-injection (se ele existir). No comando a seguir, altere REVISION para o valor que corresponda à nova revisão de istiod.

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

   Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

7. 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 versão antiga de istiod. O comando usado depende de se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Anthos Service Mesh.

      Migrate

      Se você tiver migrado do Istio, o istio-ingressgateway antigo não terá um rótulo de revisão.

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

      Fazer upgrade

      Se você fez upgrade de uma versão anterior do Anthos Service Mesh, no comando a seguir, verifique se OLD_REVISION corresponde ao rótulo de revisão da versão anterior de istiod.

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

   4. Remova a versão antiga da configuração de IstioOperator.

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

      A saída esperada terá esta aparência:

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

   Reversão

   Se você encontrar um problema ao testar seu aplicativo com a nova versão de istiod, siga estas etapas para reverter para a versão anterior:

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

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

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

   4. Remova a nova versão de istiod. Verifique se o valor de REVISION no comando a seguir está correto.

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

   5. Remova a nova versão da configuração IstioOperator.

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

      A saída esperada será assim:

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

   6. Se você não incluiu a sinalização --disable_canonical_service, o script ativou o controlador de serviço canônico. É recomendável deixá-la ativada, mas, se você precisar desativá-la, consulte Como ativar e desativar o controlador de serviço canônico.

   7. Se você tiver gateways implantados, altere o rótulo da revisão no namespace ou na implantação para corresponder à versão anterior de istiod. Siga o mesmo processo descrito na seção "Backups no local" no guia Instalar e fazer upgrade de gateways.