Você está vendo a documentação do Anthos Service Mesh 1.10. Veja uma mais recente ou selecione outra versão disponível:

Faça upgrade do Anthos Service Mesh.

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

Antes de começar

Antes de começar, verifique se você:

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.

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.

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-1104-14
    istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1104-14
    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-1104-14.

    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
        

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