Fazer upgrade do Cloud Service Mesh

Nesta página, descrevemos como:

• Execute asmcli para fazer upgrade do Cloud Service Mesh para o Cloud Service Mesh 1.23.3.

• Como opção, implante um gateway de entrada.

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

A versão do Cloud Service Mesh que pode ser atualizada varia de acordo com a plataforma.

GKE;

É possível fazer upgrade diretamente para o Cloud Service Mesh 1.23.3-asm.2 no Google Kubernetes Engine usando as seguintes versões:

1.21+

No local

É possível fazer upgrade diretamente para o Cloud Service Mesh 1.23.3-asm.2 no Google Distributed Cloud e no Google Distributed Cloud das seguintes versões:

1.21+

GKE na AWS

É possível fazer upgrade diretamente para o Cloud Service Mesh 1.23.3-asm.2 no GKE na AWS usando as seguintes versões:

1.21+

GKE no Azure

O GKE no Azure só oferece suporte ao Cloud Service Mesh 1.16. Não há suporte para upgrades de versões anteriores do Cloud Service Mesh.

Amazon EKS

Se você tiver o Cloud Service Mesh 1.7 instalado no EKS, será necessário instalar o Cloud Service Mesh 1.23 em um novo cluster. Os upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.23 não são compatíveis.

Microsoft AKS

Se você tiver o Cloud Service Mesh 1.7 instalado no AKS, será necessário instalar o Cloud Service Mesh 1.23 em um novo cluster. Os upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.23 não são compatíveis.

Antes de começar

Aviso: as ferramentas GitOps, incluindo o Config Sync, o Argo CD, o Terraform e o Jenkins, podem interferir nos processos de instalação, migração ou upgrade do Cloud Service Mesh. Para melhores resultados, desative as ferramentas de GitOps antes de instalar, migrar ou fazer upgrade do Cloud Service Mesh.

Antes de começar, verifique se você:

• Revise os pré-requisitos.
• Leia as informações em Planejar o upgrade.
• Instale as ferramentas necessárias.
• Download 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 Cloud 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.

Confira a seguir como fazer upgrade do Cloud Service Mesh:

1. Se você estiver fazendo upgrade de uma malha de vários clusters no GKE que use a autoridade de certificação do Cloud Service Mesh, execute asmcli create-mesh para configurar a malha de vários clusters para confiar na identidade da carga de trabalho da frota para o balanceamento de carga entre clusters sem inatividade durante o upgrade.

2. Execute asmcli install para instalar o Cloud 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.

3. Como opção, instale ou faça upgrade de um gateway de entrada. Por padrão, asmcli não instala o istio-ingressgateway. Recomendamos que você implante e gerencie o plano de controle e os gateways separadamente. Se você precisar do istio-ingressgateway padrão instalado com o plano de controle no cluster, inclua o argumento --option legacy-default-ingressgateway.

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

Configurar a malha de vários clusters para confiar na identidade da carga de trabalho da frota

Se você estiver fazendo upgrade de uma malha de vários clusters no GKE que use a autoridade de certificação do Cloud Service Mesh, será necessário executar asmcli create-mesh antes de fazer o upgrade de cada cluster. Esse comando configura a autoridade de certificação do Cloud Service Mesh para usar o pool de identidades da carga de trabalho da frota, FLEET_PROJECT_ID.svc.id.goog, como o domínio de confiança após o upgrade. O comando asmcli create-mesh:

• Registra todos os clusters na mesma frota.
• Configura a malha para confiar na identidade da carga de trabalho da frota.
• Cria secrets remotos.

É possível especificar o URI de cada cluster ou o caminho do arquivo kubeconfig.

URI do cluster

No comando a seguir, substitua FLEET_PROJECT_ID pelo ID do projeto do projeto host da frota e pelo URI do cluster pelo nome, zona, região e projeto do cluster ID de cada cluster.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

Arquivo kubeconfig

No comando a seguir, substitua FLEET_PROJECT_ID pelo ID do projeto do projeto host da frota e PATH_TO_KUBECONFIG pelo caminho para cada arquivo kubeconfig.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

Fazer upgrade com recursos padrão e Mesh CA

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

GKE;

Execute o comando a seguir para fazer upgrade do plano de controle com recursos padrão e a autoridade certificadora do Cloud Service Mesh. 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.
  Observação:anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --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 autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura a autoridade de certificação do Cloud Service Mesh para usar a identidade da carga de trabalho da frota.

Outros clusters do GKE Enterprise

Execute os comandos a seguir em outros clusters do GKE Enterprise para fazer upgrade do plano de controle com recursos padrão e a autoridade certificadora do Cloud Service Mesh. Digite seus valores nos marcadores fornecidos.

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./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 completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. Alterar as autoridades de certificação durante um upgrade causa inatividade. asmcliconfigura a autoridade de certificação do Cloud Service Mesh para usar a identidade da carga de trabalho da frota.

Fazer upgrade dos recursos padrão com o serviço de CA

Nesta seção, mostramos como executar o asmcli para fazer upgrade do Cloud Service Mesh com os recursos compatíveis padrão com sua plataforma e ativar o Serviço de autoridade de certificação.

GKE;

Execute o comando a seguir para fazer o upgrade do plano de controle com recursos padrão e o Certificate Authority Service. 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 gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

• --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.
  Observação:anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --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 gcp_cas Use o Certificate Authority Service como autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura o Certificate Authority Service para usar a identidade da carga de trabalho da frota.
• --ca_pool O identificador completo do Pool de CA do Certificate Authority Service.

No local

Execute os comandos a seguir no Google Distributed Cloud ou no Google Distributed Cloud para fazer upgrade do plano de controle com recursos padrão e o Certificate Authority Service. Digite seus valores nos marcadores fornecidos.

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
    --kubeconfig KUBECONFIG_FILE \
    --fleet_id FLEET_PROJECT_ID \
    --output_dir DIR_PATH \
    --enable_all \
    --ca gcp_cas \
    --platform multicloud \
    --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 gcp_cas Use o Certificate Authority Service como autoridade de certificação. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura o Certificate Authority Service para usar a identidade da carga de trabalho da frota.
   • --ca_pool O identificador completo do pool de CAs (em inglês) do Certificate Authority Service.

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

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

GKE;

Execute o comando a seguir para fazer upgrade do plano de controle com recursos padrão e CA do Istio. 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 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.
  Observação:anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --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

Execute os comandos a seguir no Google Distributed Cloud ou no Google Distributed Cloud para fazer upgrade do plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 a CA do Istio como autoridade de certificação.
   • --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

AWS

Execute os seguintes comandos no GKE na AWS para fazer upgrade do plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos. É possível optar por ativar a entrada para a sub-rede pública ou particular.

Público

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 a CA do Istio como autoridade de certificação.
   • --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

Privado

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

   kubectl config use-context CLUSTER_NAME
   

2. Salve o seguinte YAML em um arquivo chamado istio-operator-internal-lb.yaml:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 a CA do Istio como autoridade de certificação.
   • --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

Amazon EKS

Execute os comandos a seguir no Amazon EKS para fazer upgrade do plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

Observação da plataforma:se você tiver o Cloud Service Mesh 1.7 instalado no EKS, será necessário instalar o Cloud Service Mesh 1.23 em um novo cluster. Os upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.23 não são compatíveis.

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 a CA do Istio como autoridade de certificação.
   • --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

Microsoft AKS

Execute os comandos a seguir no Amazon EKS para fazer upgrade do plano de controle com recursos padrão e a CA do Istio. Digite seus valores nos marcadores fornecidos.

Observação: se o Cloud Service Mesh 1.7 estiver instalado no AKS, será necessário instalar o Cloud Service Mesh 1.23 em um novo cluster. Os upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.23 não são compatíveis.

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id O ID do projeto host da frota.
   • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 a CA do Istio como autoridade de certificação.
   • --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

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 das camadas anteriores.

GKE

Execute o comando a seguir para instalar o plano de controle com um recurso opcional. Para adicionar vários arquivos, especifique --custom_overlay e o nome do arquivo. Por exemplo: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml Insira 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.
  Observação:anote este diretório --output_dir. Você vai precisar referenciá-lo ao implantar gateways.
• --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 autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura a autoridade de certificação do Cloud Service Mesh para usar a identidade da carga de trabalho da frota.
• --custom_overlay especifica o nome do arquivo de sobreposição.

Fora do Google Cloud

Execute os seguintes comandos no Google Distributed Cloud, no GKE na AWS, no Amazon EKS ou no Microsoft AKS. Digite seus valores nos marcadores fornecidos.

Observação da plataforma:se você tiver o Cloud Service Mesh 1.7 instalado no EKS, será necessário instalar o Cloud Service Mesh 1.23 em um novo cluster. Os upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.23 não são compatíveis.

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

   kubectl config use-context CLUSTER_NAME
   

2. Execute asmcli install:

   ./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 completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
   • --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 é algo diferente do Google Cloud, como no local ou em várias nuvens.
   • --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 autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. Alterar as autoridades de certificação durante um upgrade causa inatividade. O asmcli configura a autoridade de certificação do Cloud Service Mesh 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 Cloud Service Mesh com qualquer outro método que não seja 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-1233-2-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1226-2
   istiod-asm-1233-2-67998f4b55-r76kr           1/1     Running   0          68m   asm-1226-2
   istiod-1226-2-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1233-2
   istiod-1226-2-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1233-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-1233-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-1226-2.

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

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

   Aviso: reinicie todos os pods para acionar a nova injeção de arquivos secundários. Caso contrário, os relatórios de métricas do Cloud Service Mesh podem ficar inconsistentes entre os proxies anteriores e os novos no cluster.

   kubectl rollout restart deployment -n NAMESPACE

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

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

6. 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. Mover a tag padrão:

      <OUTPUT_DIR>/istioctl tag set default --revision REVISION --overwrite
      

   4. Exclua a versã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 istiod 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

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

      2. Exclua o recurso validatingwebhookconfiguration da revisão antiga:

         kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found=true
         

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

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true
      

      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 --ignore-not-found=true
      

      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, asmcli 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.

Como implantar e reimplantar cargas de trabalho

A instalação (ou upgrade) só vai ser concluída quando você ativar a injeção automática de proxy sidecar (injeção automática). As migrações do OSS Istio e os upgrades seguem o processo de upgrade baseado em revisão (chamado de "upgrades canário" na documentação do Istio). Com um upgrade baseado em revisão, a nova versão do plano de controle é instalada com o plano de controle existente. Depois, transfira parte das cargas de trabalho para a nova versão. Isso permite monitorar o efeito do upgrade com uma pequena porcentagem das cargas de trabalho antes de migrar todo o tráfego para a nova versão.

O script define um rótulo de revisão no formato istio.io/rev=asm-1233-2 em istiod. Para ativar a injeção automática, adicione um rótulo de revisão correspondente aos namespaces. O rótulo de revisão é usado pelo webhook do injetor automático de arquivos secundários para associar os arquivos secundários injetados a uma revisão istiod específica. Depois de adicionar o rótulo, reinicie os pods no namespace para que os arquivos secundários sejam injetados.

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 saída deste comando é semelhante a:

   NAME                                                READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-1233-2
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1233-2
   istiod-asm-1233-2-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1226-2
   istiod-asm-1233-2-67998f4b55-r76kr          1/1     Running   0          68m   asm-1226-2
   istiod-asm-1226-2-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1233-2
   istiod-asm-1226-2-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1233-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-1233-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-1226-2.

2. Alterne istio-ingressgateway para a nova revisão. No comando a seguir, altere REVISION para o valor que corresponda ao rótulo de revisão da nova versão.

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   Resposta esperada: service/istio-ingressgateway patched

3. Adicione o rótulo de revisão a um namespace 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 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.

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

   Aviso: reinicie todos os pods para acionar a nova injeção de arquivos secundários. Caso contrário, os relatórios de métricas do Cloud Service Mesh podem ficar inconsistentes entre os proxies antigos e novos no cluster.

   kubectl rollout restart deployment -n NAMESPACE

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. Mova a tag padrão.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite
      

   4. Exclua a implantação istio-ingressgateway antiga. O comando executado depende se você está migrando do Istio ou fazendo upgrade de uma versão anterior do 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
      

   5. Exclua a versã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
      

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

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system --ignore-not-found=true
      

      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 implantação istio-ingressgateway. Verifique se o valor de REVISION no comando a seguir está correto.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      

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

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

      kubectl delete IstioOperator installed-state-REVISION -n istio-system --ignore-not-found=true
      

      A saída esperada será assim:

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

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