Atualize o Cloud Service Mesh

Esta página explica como:

• Execute asmcli para atualizar do Cloud Service Mesh para o Cloud Service Mesh 1.26.4.

• Opcionalmente, implemente um gateway de entrada.

• Faça uma atualização canary para migrar as suas cargas de trabalho para o novo plano de controlo.

A versão do Cloud Service Mesh a partir da qual pode fazer a atualização varia consoante a plataforma.

GKE

Pode atualizar diretamente para o Cloud Service Mesh 1.26.4-asm.1 no Google Kubernetes Engine a partir das seguintes versões:

1.24+

Nas instalações

Pode atualizar diretamente para o Cloud Service Mesh 1.26.4-asm.1 no Google Distributed Cloud e no Google Distributed Cloud a partir das seguintes versões:

1.24+

GKE no AWS

Pode atualizar diretamente para o Cloud Service Mesh 1.26.4-asm.1 no GKE no AWS a partir das seguintes versões:

1.24+

GKE no Azure

O GKE no Azure só suporta o Cloud Service Mesh 1.16. As atualizações de versões anteriores do Cloud Service Mesh não são suportadas.

Amazon EKS

Se tiver o Cloud Service Mesh 1.7 instalado no EKS, tem de instalar o Cloud Service Mesh 1.26 num novo cluster. As atualizações do Cloud Service Mesh 1.7 para o Cloud Service Mesh não são suportadas.1.26

Microsoft AKS

Se tiver o Cloud Service Mesh 1.7 instalado no AKS, tem de instalar o Cloud Service Mesh 1.26 num novo cluster. As atualizações do Cloud Service Mesh 1.7 para o Cloud Service Mesh não são suportadas.1.26

Antes de começar

Aviso: as ferramentas GitOps (incluindo Config Sync, Argo CD, Terraform e Jenkins) podem interferir com os processos de instalação, migração ou atualização do Cloud Service Mesh. Para obter os melhores resultados, desative as ferramentas GitOps antes de instalar, migrar ou atualizar o Cloud Service Mesh.

Antes de começar:

• Reveja os pré-requisitos.
• Reveja as informações em Planeie a atualização.
• Instale as ferramentas necessárias.
• Transferir asmcli.
• Conceda autorizações de administrador do cluster.
• Valide o projeto e o cluster.

Personalizações do plano de controlo

Se personalizou a instalação anterior, precisa das mesmas personalizações quando atualizar para uma nova versão do Cloud Service Mesh ou migrar do Istio. Se tiver personalizado a instalação adicionando a flag --set values a istioctl install, tem de adicionar essas definições a um IstioOperator ficheiro YAML, denominado ficheiro de sobreposição. Especifica o ficheiro de sobreposição através da opção --custom_overlay com o nome do ficheiro quando executa o script. O script transmite o ficheiro de sobreposição a istioctl install.

Atenção: se omitir o ficheiro de sobreposição, a instalação é bem-sucedida. No entanto, a sua malha de serviços tem uma configuração diferente da pretendida, porque os valores omitidos são repostos para os predefinidos quando o plano de controlo e o gateway de entrada são reimplementados.

Autoridade de certificação

A alteração da autoridade de certificação (AC) durante uma atualização provoca tempo de inatividade. Durante a atualização, o tráfego mTLS é interrompido até que todas as cargas de trabalho sejam comutadas para a utilização do novo plano de controlo com a nova AC.

Atualize o Anthos Service Mesh

As seguintes instruções descrevem como atualizar o Cloud Service Mesh:

1. Se estiver a atualizar uma malha de vários clusters no GKE que usa a autoridade de certificação do Cloud Service Mesh, execute asmcli create-mesh para configurar a malha de vários clusters de modo a confiar na identidade da carga de trabalho da frota para um equilíbrio de carga entre clusters sem tempo de inatividade durante a atualização.

2. Execute asmcli install para instalar o Cloud Service Mesh num único cluster. Consulte as secções seguintes para ver exemplos de linhas de comandos. Os exemplos contêm argumentos obrigatórios e argumentos opcionais que podem ser úteis. Recomendamos que especifique sempre o argumento output_dir para que possa localizar facilmente gateways e ferramentas de exemplo, como istioctl. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

3. Opcionalmente, instale ou atualize um gateway de entrada. Por predefinição, o asmcli não instala o istio-ingressgateway. Recomendamos que implemente e faça a gestão do plano de controlo e das gateways separadamente. Se precisar do istio-ingressgatewaypredefinido instalado com o painel de controlo no cluster, inclua o argumento --option legacy-default-ingressgateway.

4. Para concluir a configuração do Cloud Service Mesh, tem de ativar a injeção automática de sidecar e implementar ou reimplementar cargas de trabalho.

Configure a malha de vários clusters para confiar no Workload Identity da frota

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

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

Pode especificar o URI para cada cluster ou o caminho do ficheiro kubeconfig.

URI do cluster

No comando seguinte, substitua FLEET_PROJECT_ID pelo ID do projeto do projeto anfitrião da frota e o URI do cluster pelo nome, zona ou região do cluster e o ID do projeto para 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

ficheiro kubeconfig

No comando seguinte, substitua FLEET_PROJECT_ID pelo ID do projeto do projeto anfitrião da frota e PATH_TO_KUBECONFIG pelo caminho para cada ficheiro kubeconfig.

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

Atualize com as funcionalidades predefinidas e a CA de malha

Esta secção mostra como executar asmcli para atualizar o Cloud Service Mesh com as funcionalidades suportadas predefinidas para a sua plataforma e ativar a autoridade de certificação do Cloud Service Mesh como autoridade de certificação.

GKE

Execute o seguinte comando para atualizar o plano de controlo com as funcionalidades predefinidas e a autoridade de certificação do Cloud Service Mesh. Introduza os seus valores nos marcadores de posição 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 no qual o cluster se encontra, o nome do cluster e a zona ou a região do cluster.
• --fleet_id O ID do projeto do projeto anfitrião da frota. Se não incluir esta opção, asmcli usa o projeto no qual o cluster foi criado ao registar o cluster.
• --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  Nota: tome nota deste diretório --output_dir. Tem de fazer referência a ele quando implementar gateways.
• --enable_all Permite que o script:
  • Conceda as autorizações de IAM necessárias.
  • Ative as APIs Google necessárias.
  • Defina uma etiqueta no cluster que identifique a malha.
  • Registe o cluster na frota se ainda não estiver registado.
• --ca mesh_ca Use a autoridade de certificação do Cloud Service Mesh como a autoridade de certificação. A alteração das autoridades de certificação durante uma atualização provoca tempo de inatividade. asmcliconfigura 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 seguintes comandos noutros clusters do GKE Enterprise para atualizar o plano de controlo com funcionalidades predefinidas e a autoridade de certificação do Cloud Service Mesh. Introduza os seus valores nos marcadores de posição fornecidos.

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca mesh_ca Use a autoridade de certificação do Cloud Service Mesh como a autoridade de certificação. A alteração das autoridades de certificação durante uma atualização causa tempo de inatividade. asmcliconfigura a autoridade de certificação do Cloud Service Mesh para usar a identidade da carga de trabalho da frota

Atualize as funcionalidades predefinidas com o serviço de CA

Esta secção mostra como executar asmcli para atualizar o Cloud Service Mesh com as funcionalidades suportadas predefinidas para a sua plataforma e ativar o serviço de autoridade de certificação.

GKE

Execute o seguinte comando para atualizar o plano de controlo com as funcionalidades predefinidas e o serviço de autoridade de certificação. Introduza os seus valores nos marcadores de posição 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 no qual o cluster se encontra, o nome do cluster e a zona ou a região do cluster.
• --fleet_id O ID do projeto do projeto anfitrião da frota. Se não incluir esta opção, asmcli usa o projeto no qual o cluster foi criado ao registar o cluster.
• --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  Nota: tome nota deste diretório --output_dir. Tem de fazer referência a ele quando implementar gateways.
• --enable_all Permite que o script:
  • Conceda as autorizações de IAM necessárias.
  • Ative as APIs Google necessárias.
  • Defina uma etiqueta no cluster que identifique a malha.
  • Registe o cluster na frota se ainda não estiver registado.
• --ca gcp_cas Use o Certificate Authority Service como a autoridade de certificação. A alteração das autoridades de certificação durante uma atualização provoca tempo de inatividade. O asmcliconfigura o serviço de autoridade de certificação para usar a identidade da carga de trabalho da frota
• --ca_pool O identificador completo do serviço de autoridade de certificação CA Pool.

Nas instalações

Execute os seguintes comandos no Google Distributed Cloud ou no Google Distributed Cloud para atualizar o plano de controlo com as funcionalidades predefinidas e o serviço de autoridade de certificação. Introduza os seus valores nos marcadores de posição fornecidos.

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca gcp_cas Use o Certificate Authority Service como a autoridade de certificação. A alteração das autoridades de certificação durante uma atualização provoca tempo de inatividade. O asmcliconfigura o serviço de autoridade de certificação para usar a identidade da carga de trabalho da frota
   • --ca_pool O identificador completo do serviço de autoridade de certificação CA Pool.

Atualize as funcionalidades predefinidas com a CA do Istio

Esta secção mostra como executar asmcli para atualizar o Cloud Service Mesh com as funcionalidades suportadas predefinidas para a sua plataforma e ativar a CA do Istio.

GKE

Execute o seguinte comando para atualizar o plano de controlo com as funcionalidades predefinidas e a AC do Istio. Introduza os seus valores nos marcadores de posição 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 no qual o cluster se encontra, o nome do cluster e a zona ou a região do cluster.
• --fleet_id O ID do projeto do projeto anfitrião da frota. Se não incluir esta opção, asmcli usa o projeto no qual o cluster foi criado ao registar o cluster.
• --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  Nota: tome nota deste diretório --output_dir. Tem de fazer referência a ele quando implementar gateways.
• --enable_all Permite que o script:
  • Conceda as autorizações de IAM necessárias.
  • Ative as APIs Google necessárias.
  • Defina uma etiqueta no cluster que identifique a malha.
  • Registe o cluster na frota se ainda não estiver registado.
• --ca citadel Use a AC do Istio. A alteração das autoridades de certificação durante uma atualização provoca tempo de inatividade.

Nas instalações

Execute os seguintes comandos no Google Distributed Cloud ou no Google Distributed Cloud para atualizar o plano de controlo com as funcionalidades predefinidas e a CA do Istio. Introduza os seus valores nos marcadores de posição fornecidos.

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca citadel Use a AC do Istio como autoridade de certificação.
   • --ca_cert O certificado intermédio
   • --ca_key A chave do certificado intermédio
   • --root_cert O certificado de raiz
   • --cert_chain A cadeia de certificados

AWS

Execute os seguintes comandos no GKE no AWS para atualizar o plano de controlo com as funcionalidades predefinidas e a CA do Istio. Introduza os seus valores nos marcadores de posição fornecidos. Pode optar por ativar a entrada para a sub-rede pública ou a sub-rede privada.

Público

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca citadel Use a AC do Istio como autoridade de certificação.
   • --ca_cert O certificado intermédio
   • --ca_key A chave do certificado intermédio
   • --root_cert O certificado de raiz
   • --cert_chain A cadeia de certificados

Privado

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Guarde o seguinte YAML num ficheiro denominado 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. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca citadel Use a AC do Istio como autoridade de certificação.
   • --ca_cert O certificado intermédio
   • --ca_key A chave do certificado intermédio
   • --root_cert O certificado de raiz
   • --cert_chain A cadeia de certificados

Amazon EKS

Execute os seguintes comandos no Amazon EKS para atualizar o plano de controlo com as funcionalidades predefinidas e a CA do Istio. Introduza os seus valores nos marcadores de posição fornecidos.

Nota da plataforma: se tiver o Cloud Service Mesh 1.7 instalado no EKS, tem de instalar o Cloud Service Mesh 1.26 num novo cluster. As atualizações do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.26 não são suportadas.

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca citadel Use a AC do Istio como autoridade de certificação.
   • --ca_cert O certificado intermédio
   • --ca_key A chave do certificado intermédio
   • --root_cert O certificado de raiz
   • --cert_chain A cadeia de certificados

Microsoft AKS

Execute os seguintes comandos no Amazon EKS para atualizar o plano de controlo com as funcionalidades predefinidas e a CA do Istio. Introduza os seus valores nos marcadores de posição fornecidos.

Nota: se tiver o Cloud Service Mesh 1.7 instalado no AKS, tem de instalar o Cloud Service Mesh 1.26 num novo cluster. As atualizações do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.26 não são suportadas.

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca citadel Use a AC do Istio como autoridade de certificação.
   • --ca_cert O certificado intermédio
   • --ca_key A chave do certificado intermédio
   • --root_cert O certificado de raiz
   • --cert_chain A cadeia de certificados

Atualize com funcionalidades opcionais

Um ficheiro de sobreposição é um ficheiro YAML que contém um IstioOperator recurso personalizado (CR) que transmite ao asmcli para configurar o plano de controlo. Pode substituir a configuração do plano de controlo predefinido e ativar uma funcionalidade opcional transmitindo o ficheiro YAML para asmcli. Pode aplicar mais sobreposições e cada ficheiro de sobreposição substitui a configuração nas camadas anteriores.

GKE

Execute o seguinte comando para instalar o plano de controlo com uma funcionalidade opcional. Para adicionar vários ficheiros, especifique --custom_overlay e o nome do ficheiro, por exemplo: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml Introduza os seus valores nos marcadores de posição 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 no qual o cluster se encontra, o nome do cluster e a zona ou a região do cluster.
• --fleet_id O ID do projeto do projeto anfitrião da frota. Se não incluir esta opção, asmcli usa o projeto no qual o cluster foi criado ao registar o cluster.
• --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  Nota: tome nota deste diretório --output_dir. Tem de fazer referência a ele quando implementar gateways.
• --enable_all Permite que o script:
  • Conceda as autorizações de IAM necessárias.
  • Ative as APIs Google necessárias.
  • Defina uma etiqueta no cluster que identifique a malha.
  • Registe o cluster na frota se ainda não estiver registado.
• --ca mesh_ca Use a autoridade de certificação do Cloud Service Mesh como a autoridade de certificação. A alteração das autoridades de certificação durante uma atualização provoca tempo de inatividade. asmcliconfigura a autoridade de certificação do Cloud Service Mesh para usar a identidade da carga de trabalho da frota
• --custom_overlay Especifique o nome do ficheiro de sobreposição.

Fora do Google Cloud

Execute os seguintes comandos no Google Distributed Cloud, Google Distributed Cloud, GKE on AWS, Amazon EKS ou Microsoft AKS. Introduza os seus valores nos marcadores de posição fornecidos.

Nota da plataforma: se tiver o Cloud Service Mesh 1.7 instalado no EKS, tem de instalar o Cloud Service Mesh 1.26 num novo cluster. As atualizações do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.26 não são suportadas.

1. Defina o contexto atual para o cluster de utilizadores:

   kubectl config use-context CLUSTER_NAME
   

2. Corrida 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 do projeto anfitrião da frota.
   • --kubeconfig O caminho completo para o ficheiro kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, as localizações de ficheiros kubeconfig relativas que usam um "~" não funcionam.
   • --output_dir Inclua esta opção para especificar um diretório onde asmcli transfere o pacote anthos-service-mesh e extrai o ficheiro de instalação, que contém istioctl, exemplos e manifestos. Caso contrário, asmcli transfere os ficheiros para um diretório tmp. Pode especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
   • --platform multicloud Especifica que a plataforma é algo diferente de Google Cloud, como no local ou na nuvem múltipla.
   • --enable_all Permite que o script:
     • Conceda as autorizações de IAM necessárias.
     • Ative as APIs Google necessárias.
     • Defina uma etiqueta no cluster que identifique a malha.
     • Registe o cluster na frota se ainda não estiver registado.
   • --ca mesh_ca Use a autoridade de certificação do Cloud Service Mesh como a autoridade de certificação. A alteração das autoridades de certificação durante uma atualização provoca tempo de inatividade. asmcliconfigura a autoridade de certificação do Cloud Service Mesh para usar a identidade da carga de trabalho da frota
   • --custom_overlay Especifique o nome do ficheiro de sobreposição.

Atualize gateways

Se tiver gateways implementados, também tem de os atualizar. Para uma atualização simples, siga a secção Atualizações no local no guia Instale e atualize gateways.

Aviso: se instalou o Cloud Service Mesh com qualquer outro método que não seja asmcli, o gateway de entrada predefinido instalado é removido, a menos que transmita o argumento --option legacy-default-ingressgateway.

Mude para o novo plano de controlo

1. Obtenha a etiqueta de revisão que está em istiod.

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

   O resultado do comando é semelhante ao seguinte.

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1264-1-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1254-0
   istiod-asm-1264-1-67998f4b55-r76kr           1/1     Running   0          68m   asm-1254-0
   istiod-1254-0-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1264-1
   istiod-1254-0-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1264-1

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

   2. Tenha também em atenção o valor na etiqueta de revisão da versão antiga do istiod. Precisa desta opção para eliminar a versão antiga do istiod quando terminar de mover as cargas de trabalho para a nova versão. No exemplo de saída, o valor da etiqueta de revisão para a versão antiga é asm-1254-0.

2. Adicione a etiqueta de revisão a um espaço de nomes da aplicação e remova a etiqueta istio-injection (se existir). No comando seguinte, altere REVISION para o valor que corresponde à 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, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que o comportamento de injeção automática não está definido quando um espaço de nomes tem a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas uma está definida.

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

   Aviso: certifique-se de que reinicia todos os pods para acionar a reinjeção de sidecars. Caso contrário, os relatórios de métricas do Cloud Service Mesh podem tornar-se inconsistentes entre os proxies anteriores e novos no cluster.

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   Conclua a transição

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

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

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

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

   3. Mova a etiqueta predefinida:

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

   4. Elimine a versão antiga do istiod. O comando que usa depende de estar a migrar do Istio ou a atualizar a partir de uma versão anterior do Cloud Service Mesh.

      Migrar

      Se migrou do Istio, o antigo istiod não tem uma etiqueta de revisão:

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

      Atualizar

      1. Se fez a atualização a partir de uma versão anterior do Cloud Service Mesh, no comando seguinte, certifique-se de que OLD_REVISION corresponde à etiqueta de revisão da versão anterior do istiod:

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

      2. Elimine o recurso validatingwebhookconfiguration para a 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 IstioOperator:

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

      O resultado esperado é semelhante ao seguinte:

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

   Reversão

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

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

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

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

      • Se usou o istio-injection=enabled:

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

      Resultado esperado:

      namespace/NAMESPACE labeled

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

      kubectl get ns NAMESPACE --show-labels
      

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

      kubectl rollout restart deployment -n NAMESPACE
      

   4. Remova a nova versão do istiod. Certifique-se de que o valor de REVISION no seguinte comando 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
      

      O resultado esperado é semelhante ao seguinte:

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

   6. Se não incluiu a flag --disable_canonical_service, o controlador do serviço canónico foi ativado.asmcli Recomendamos que a deixe ativada, mas se precisar de a desativar, consulte o artigo Ativar e desativar o controlador de serviços canónico.

   7. Se tiver gateways implementados, certifique-se de que altera a etiqueta de revisão no espaço de nomes ou na implementação para corresponder à versão anterior do istiod. Siga o mesmo processo descrito na secção Atualizações no local do guia Instalar e atualizar gateways.

Implementação e reimplementação de cargas de trabalho

A instalação (ou a atualização) não está concluída até ativar a injeção automática de proxy sidecar (injeção automática). As migrações do Istio de código aberto e as atualizações seguem o processo de atualização baseado em revisões (denominado "atualizações canárias" na documentação do Istio). Com uma atualização baseada em revisões, a nova versão do plano de controlo é instalada juntamente com o plano de controlo existente. Em seguida, move algumas das suas cargas de trabalho para a nova versão, o que lhe permite monitorizar o efeito da atualização com uma pequena percentagem das cargas de trabalho antes de migrar todo o tráfego para a nova versão.

O script define uma etiqueta de revisão no formato istio.io/rev=asm-1264-1 em istiod. Para ativar a injeção automática, adicione uma etiqueta de revisão correspondente aos seus espaços de nomes. A etiqueta de revisão é usada pelo webhook do injetor de sidecar para associar sidecars injetados a uma revisão istiod específica. Depois de adicionar a etiqueta, reinicie os pods no espaço de nomes para que os sidecars sejam injetados.

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

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

   O resultado do comando é semelhante ao seguinte.

   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-1264-1
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1264-1
   istiod-asm-1264-1-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1254-0
   istiod-asm-1264-1-67998f4b55-r76kr          1/1     Running   0          68m   asm-1254-0
   istiod-asm-1254-0-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1264-1
   istiod-asm-1254-0-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1264-1

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

   2. Tenha também em atenção o valor na etiqueta de revisão da versão antiga do istiod. Precisa desta opção para eliminar a versão antiga do istiod quando terminar de mover as cargas de trabalho para a nova versão. No exemplo de saída, o valor da etiqueta de revisão para a versão antiga é asm-1254-0.

2. Mude o istio-ingressgateway para a nova revisão. No comando seguinte, altere REVISION para o valor que corresponde à etiqueta 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"}]'

   Resultado esperado: service/istio-ingressgateway patched

3. Adicione a etiqueta de revisão a um espaço de nomes e remova a etiqueta istio-injection (se existir). No comando seguinte, altere REVISION para o valor que corresponde à 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, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que o comportamento de injeção automática não está definido quando um espaço de nomes tem a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas uma está definida.

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

   Aviso: certifique-se de que reinicia todos os pods para acionar a reinjeção dos sidecars. Caso contrário, os relatórios de métricas do Cloud Service Mesh podem tornar-se inconsistentes entre os proxies antigos e novos no cluster.

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   Conclua a transição

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

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

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

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

   3. Mova a etiqueta predefinida.

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

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

      Migrar

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

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

      Atualizar

      Se fez a atualização a partir de uma versão anterior do Cloud Service Mesh, no comando seguinte, substitua OLD_REVISION pela etiqueta de revisão da versão anterior do istio-ingressgateway.

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

   5. Elimine a versão antiga do istiod. O comando que usa depende de estar a migrar do Istio ou a atualizar a partir de uma versão anterior do Cloud Service Mesh.

      Migrar

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

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

      Atualizar

      Se fez a atualização a partir de uma versão anterior do Cloud Service Mesh, no comando seguinte, certifique-se de que OLD_REVISION corresponde à etiqueta de revisão da versão anterior do istiod.

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

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

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

      O resultado esperado é semelhante ao seguinte:

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

   Reversão

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

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

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

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

      • Se usou o istio-injection=enabled:

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

      Resultado esperado:

      namespace/NAMESPACE labeled

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

      kubectl get ns NAMESPACE --show-labels
      

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

      kubectl rollout restart deployment -n NAMESPACE
      

   4. Remova a nova implementação istio-ingressgateway. Certifique-se de que o valor de REVISION no seguinte comando 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 do istiod. Certifique-se de que o valor de REVISION no seguinte comando 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
      

      O resultado esperado é semelhante ao seguinte:

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

   7. Se não incluiu a flag --disable_canonical_service, o script ativou o controlador de serviço canónico. Recomendamos que a deixe ativada, mas se precisar de a desativar, consulte o artigo Ativar e desativar o controlador de serviços canónico.