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

  • 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 Cloud Service Mesh 1.18.7-asm.26 no Google Kubernetes Engine do seguinte versões:

1.16+

No local

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

1.16+

GKE na AWS

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

1.16+

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, vai precisar instalar o Cloud Service Mesh 1.18 em um novo cluster. Os upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.18 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.18 em um novo cluster. Upgrades do Cloud Service Mesh 1.7 para o Cloud Service Mesh 1.18 não são compatíveis.

Antes de começar

Antes de começar, verifique se você:

Personalizações do plano de controle

Se você tiver personalizado a instalação anterior, precisará das mesmas personalizações quando fizer upgrade para uma nova versão do 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.

Autoridade de certificação

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

Faça upgrade do Anthos Service Mesh.

Confira a seguir como fazer upgrade do Cloud Service Mesh:

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

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

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

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

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

Se você estiver fazendo upgrade de uma malha de vários clusters no GKE que use a autoridade de certificação do Cloud Service Mesh como autoridade de certificação, será necessário executar asmcli create-mesh antes de fazer o 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 o asmcli para fazer upgrade do Cloud Service Mesh com os recursos compatíveis padrão com sua plataforma e ativar a autoridade de certificação do Cloud Service Mesh como a autoridade de certificação.

GKE;

Execute o comando a seguir para fazer upgrade do plano de controle com recursos padrão e a autoridade certificadora do Cloud Service Mesh. Digite seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca
  • --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
  • --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
  • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  • --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 autoridades certificadoras durante uma gera inatividade. asmcliconfigura Autoridade certificadora do Cloud Service Mesh a ser usada frota identidade da carga de trabalho

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 autoridade de certificação do Cloud Service Mesh. Digite seus valores nos marcadores fornecidos.

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

    kubectl config use-context CLUSTER_NAME

  2. Execute asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
    • --fleet_id O ID do projeto host da frota.
    • --kubeconfig O caminho completo para o arquivo kubeconfig. A variável de ambiente $PWD não funciona aqui. Além disso, os locais relativos de arquivos kubeconfig que usam um "~" não funcionarão.
    • --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
    • --platform multicloud especifica que a plataforma é algo diferente do Google Cloud, como no local ou em várias nuvens.
    • --enable_all Permite que o script:
      • Conceder as permissões necessárias do IAM.
      • Ative as APIs do Google necessárias.
      • Defina um rótulo no cluster que identifique a malha.
      • Registre o cluster na frota se ele ainda não estiver registrado.
    • --ca mesh_ca Use a autoridade certificadora do Cloud Service Mesh como a autoridade certificadora. Alterar as autoridades de certificação durante um upgrade causa inatividade. asmcliconfigura Autoridade certificadora do Cloud Service Mesh a ser usada frota identidade da carga de trabalho

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

  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.

  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.
  • --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 autoridades certificadoras durante uma gera inatividade. asmcliconfigura Autoridade certificadora do Cloud Service Mesh a ser usada frota identidade da carga de trabalho
  • --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.

  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 Usar a autoridade certificadora do Cloud Service Mesh como autoridade certificadora. Alterar autoridades certificadoras durante uma gera inatividade. asmcliconfigura Autoridade certificadora do Cloud Service Mesh a ser usada frota identidade da carga de trabalho
    • --custom_overlay especifica o nome do arquivo de sobreposição.

Fazer upgrade de gateways

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

Alternar para o novo plano de controle

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

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

    A saída deste comando é semelhante a:

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

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

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

  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 os valores istio-injection e rótulo de revisão, todos os comandos kubectl label no Cloud Service Mesh a documentação para garantir explicitamente que apenas um deles seja definido.

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

    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 <NEW REVISION NAME>

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

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

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

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

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

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

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

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

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

    Reversão

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

    1. Altere o nome do seu namespace para ativar a injeção automática com a versão anterior do istiod. O comando usado depende de você ter usado um rótulo de revisão ou istio-injection=enabled com a versão anterior.

      • Se você usou um rótulo de revisão para a injeção automática, faça o seguinte:

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

      • Se você usou istio-injection=enabled:

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

      Resposta esperada:

      namespace/NAMESPACE labeled

    2. Confirme se o rótulo de revisão no namespace corresponde ao rótulo de revisão na versão anterior de istiod:

      kubectl get ns NAMESPACE --show-labels

    3. Reinicie os pods para acionar a nova injeção de modo que os proxies tenham a versão do Istio:

      kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

      A saída esperada será assim:

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

    6. Se você não incluiu a sinalização --disable_canonical_service, 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-1187-26 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-1187-26
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1187-26
istiod-asm-1187-26-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1178-20
istiod-asm-1187-26-67998f4b55-r76kr          1/1     Running   0          68m   asm-1178-20
istiod-asm-1178-20-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1187-26
istiod-asm-1178-20-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1187-26

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

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

  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 os valores istio-injection e rótulo de revisão, todos os comandos kubectl label no Cloud Service Mesh a documentação para garantir explicitamente que apenas um deles seja definido.

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

  7. Se você achar que seu aplicativo está funcionando conforme esperado, continue com as etapas para concluir a transição para a nova versão de istiod. Se houver um problema com o aplicativo, siga as etapas para reverter.

    Concluir a transição

    Se o aplicativo estiver funcionando corretamente, remova o plano de controle antigo para concluir a transição para a nova versão.

    1. Altere para o diretório em que os arquivos do repositório anthos-service-mesh do GitHub estão localizados.

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

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

    3. Mova a tag padrão.

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

    4. Exclua a implantação istio-ingressgateway antiga. O comando executado depende se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Cloud Service Mesh:

      Migrar

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

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

      Fazer upgrade

      Se você fez upgrade de uma versão anterior do Cloud Service Mesh, no comando a seguir, substitua OLD_REVISION pelo rótulo de revisão da versão anterior do istio-ingressgateway.

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

    5. Exclua a versão antiga de istiod. O comando usado depende se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Cloud Service Mesh.

      Migrar

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

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

      Fazer upgrade

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

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

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

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

      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

      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.