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

• 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.2-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.2-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 Cloud Service Mesh 1.23.2-asm.2 no GKE na AWS usando o 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. 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. 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: ferramentas GitOps (incluindo Config Sync, Argo CD, Terraform, e Jenkins) podem interferir na instalação, migração ou e processos de upgrade. 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ê personalizou a instalação anterior, precisará das mesmas personalizações ao fazer 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 usa Autoridade certificadora do Cloud Service Mesh, execute asmcli create-mesh para configurar da malha de vários clusters para confiar identidade da carga de trabalho da frota 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, você precisa ativar o arquivo secundário automático injeção e implantar ou reimplantar 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 certificadora do Cloud Service Mesh como autoridade certificadora, você precisa executar asmcli create-mesh antes de fazer upgrade de cada cluster. Esse comando configura Autoridade certificadora do Cloud Service Mesh para usar o pool de identidades de cargas de trabalho da frota FLEET_PROJECT_ID.svc.id.goog, que é o domínio de confiança depois de você fazer 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 asmcli para fazer upgrade do Cloud Service Mesh com a recursos compatíveis padrão com sua plataforma e ativar a autoridade certificadora do Cloud Service Mesh como autoridade certificadora.

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 Usar a autoridade certificadora do Cloud Service Mesh como 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 Usar a autoridade certificadora do Cloud Service Mesh como 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 asmcli para fazer upgrade do Cloud Service Mesh com a recursos compatíveis padrão com sua plataforma e ative o Certificate Authority Service.

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 esse 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 asmcli para fazer upgrade do Cloud Service Mesh com a recursos compatíveis padrão com sua plataforma e ativar a AC 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; Upgrades de Cloud Service Mesh 1.7 para Cloud Service Mesh 1.23 não tem suporte.

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 esse 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 Usar a autoridade certificadora do Cloud Service Mesh como 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 comandos a seguir no Google Distributed Cloud. Google Distributed Cloud, GKE na AWS, Amazon EKS ou Microsoft AKS. Digite seus valores nos marcadores fornecidos.

Observação sobre a plataforma: Se você tiver o Cloud Service Mesh 1.7 instalado no EKS, precisará instalar 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 método diferente de asmcli, os 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-1232-2-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1225-1
   istiod-asm-1232-2-67998f4b55-r76kr           1/1     Running   0          68m   asm-1225-1
   istiod-1225-1-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1232-2
   istiod-1225-1-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1232-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-1232-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-1225-1.

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 que você usa depende se está migrando do Istio ou atualizando de uma versão 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ê tiver feito upgrade de uma versão anterior do Cloud Service Mesh, na 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-1232-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-1232-2
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1232-2
   istiod-asm-1232-2-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1225-1
   istiod-asm-1232-2-67998f4b55-r76kr          1/1     Running   0          68m   asm-1225-1
   istiod-asm-1225-1-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1232-2
   istiod-asm-1225-1-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1232-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-1232-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-1225-1.

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 que você ser executados se você estiver 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ê tiver feito upgrade de uma versão anterior do Cloud Service Mesh, na 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 que você usa depende se está migrando do Istio ou atualizando de uma versão 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.