Como fazer upgrade do Anthos Service Mesh no GKE em uma malha de vários projetos

Neste guia, explicamos como fazer o upgrade de 1.8 or a 1.9 patch release para o Anthos Service Mesh 1.9.8 em um cluster do Google Kubernetes Engine (GKE) para uma malha contendo vários clusters que estão em diferentes projetos do Google Cloud.

Observação:

Para informações sobre outros casos de uso de integração do Anthos Service Mesh, consulte o seguinte:

• Para instruções de upgrade de clusters que estão no mesmo projeto do Google Cloud, consulte Instalação, migração e upgrade para o GKE.
• Depois de fazer upgrade do Anthos Service Mesh, se precisar configurar uma malha de serviço de vários clusters, consulte Como configurar uma malha de vários clusters.

Antes de começar

Antes de instalar o Anthos Service Mesh, verifique se você tem:

• Configure o ambiente para instalar as ferramentas necessárias.

Importante: verifique a versão de kpt que você tem e instale a versão obrigatória, se necessário. Consulte Configurar seu ambiente para ver detalhes.

Como se preparar para o upgrade

Se você tiver personalizado a instalação anterior, precisará das mesmas personalizações quando fizer upgrade para uma nova versão do Anthos Service Mesh ou migrar do Istio. Se você tiver personalizado a instalação adicionando a sinalização --set values em istioctl install, será necessário adicionar essas configurações a um arquivo YAML IstioOperator, chamado de arquivo de sobreposição. Especifique o arquivo de sobreposição usando a opção --custom_overlay com o nome de arquivo ao executar o script. O script transfere o arquivo de sobreposição para istioctl install.

Atenção: omitir o arquivo de sobreposição resulta em uma instalação bem-sucedida. Porém, 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.

Observação: o upgrade no local usando istioctl upgrade não é compatível com o Anthos Service Mesh.

O script segue o processo de upgrade de revisão (chamado de upgrades "canário" na documentação do Istio). Com um upgrade baseado em revisão, o script instala uma nova versão do plano de controle com o plano de controle atual. Ao instalar a nova versão, o script inclui um rótulo revision que identifica o novo plano de controle.

Em seguida, você migra para a nova versão definindo o mesmo rótulo revision nas cargas de trabalho e realizando uma reinicialização gradual. Isso injeta os proxies novamente para que eles usem a nova versão e configuração do Anthos Service Mesh. Com essa abordagem, é possível monitorar o efeito do upgrade em uma pequena porcentagem das cargas de trabalho. Depois de testar o aplicativo, será possível migrar todo o tráfego para a nova versão. Essa abordagem é muito mais segura do que realizar um upgrade no local em que os novos componentes do plano de controle substituem a versão anterior.

Importante: ao executar o script, inclua --option revisioned-istio-ingressgateway da maneira mostrada em todos os exemplos. Com essa opção, o script cria uma implantação revisada de istio-ingressgateway. Assim, você pode controlar quando muda para a nova versão. Se você não incluir essa opção, o script fará um upgrade no local do istio-ingressgateway.

Como configurar variáveis de ambiente

1. Consiga o ID do projeto em que o cluster foi criado e o número do projeto host do environ.

   gcloud

   Execute este comando:

   gcloud projects list
   

   Console

   1. Acesse a página Painel no console do Google Cloud:

      Ir para a página "Painel"

   2. Clique na lista suspensa Selecionar de na parte superior da página. Na janela Selecionar de exibida, selecione seu projeto.

      O ID do projeto é exibido no card Informações do projeto do Painel.

2. Crie uma variável de ambiente para o ID do projeto em que o cluster foi criado:

   export PROJECT_ID=YOUR_PROJECT_ID

3. Crie uma variável de ambiente para o número do projeto host do environ.

   export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER

4. Crie as variáveis de ambiente a seguir:

   • Defina o nome do cluster:

     export CLUSTER_NAME=YOUR_CLUSTER_NAME

   • Defina CLUSTER_LOCATION como a zona ou a região do cluster:

     export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

5. Defina a zona ou a região padrão da Google Cloud CLI. Se você não definir o padrão aqui, especifique a opção --zone ou --region nos comandos gcloud container clusters desta página.

   • Se você tiver um cluster de zona única, defina a zona padrão:

     gcloud config set compute/zone ${CLUSTER_LOCATION}

   • Se você tiver um cluster regional, defina a região padrão:

     gcloud config set compute/region ${CLUSTER_LOCATION}

   Dica: para facilitar a configuração do ambiente shell no futuro, copie e cole as instruções export de cada variável de ambiente em um script de shell simples que você source ao iniciar um novo shell. Também é possível adicionar os comandos gcloud que definem valores padrão ao script. Outra opção é usar gcloud init para criar e ativar uma configuração gcloud nomeada.

Como configurar credenciais e permissões

1. Consiga as credenciais de autenticação para interagir com o cluster: Esse comando também define o contexto atual para kubectl no cluster.

   gcloud container clusters get-credentials ${CLUSTER_NAME} \
       --project=${PROJECT_ID}
   

   Observação: a menos que você tenha definido uma zona ou região padrão, é necessário fornecer a região (--region=REGION) ou zona (--zone=ZONE) no comando.

2. Conceda permissões de administrador de cluster ao usuário atual. Você precisa dessas permissões para criar as regras necessárias de controle de acesso baseado em papéis (RBAC, na sigla em inglês) para o Anthos Service Mesh.

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

Se você observar o erro "cluster-admin-binding" already exists, poderá ignorá-lo com segurança e continuar com o cluster-admin-binding atual.

Como fazer o download do arquivo de instalação

Linux

1. Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz

2. Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig
   openssl dgst -verify /dev/stdin -signature istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig istio-1.9.8-asm.6-linux-amd64.tar.gz <<'EOF'
   -----BEGIN PUBLIC KEY-----
   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
   wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
   -----END PUBLIC KEY-----
   EOF

   A saída esperada é Verified OK.

3. Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

    tar xzf istio-1.9.8-asm.6-linux-amd64.tar.gz

   O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:

   • Exemplos de aplicativos no diretório samples.
   • A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
   • Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

4. Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.

   cd istio-1.9.8-asm.6

macOS

1. Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz

2. Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz.1.sig
   openssl dgst -sha256 -verify /dev/stdin -signature istio-1.9.8-asm.6-osx.tar.gz.1.sig istio-1.9.8-asm.6-osx.tar.gz <<'EOF'
   -----BEGIN PUBLIC KEY-----
   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
   wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
   -----END PUBLIC KEY-----
   EOF

   A saída esperada é Verified OK.

3. Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

   tar xzf istio-1.9.8-asm.6-osx.tar.gz

   O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:

   • Exemplos de aplicativos no diretório samples.
   • A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
   • Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

4. Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.

   cd istio-1.9.8-asm.6

Windows

1. Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip

2. Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip.1.sig
   openssl dgst -verify - -signature istio-1.9.8-asm.6-win.zip.1.sig istio-1.9.8-asm.6-win.zip <<'EOF'
   -----BEGIN PUBLIC KEY-----
   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
   wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
   -----END PUBLIC KEY-----
   EOF

   A saída esperada é Verified OK.

3. Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

   tar xzf istio-1.9.8-asm.6-win.zip

   O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.9.8-asm.6, que contém o seguinte:

   • Exemplos de aplicativos no diretório samples.
   • A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
   • Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

4. Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.

   cd istio-1.9.8-asm.6

Como preparar arquivos de configuração de recursos

Ao executar o comando istioctl install, especifique -f istio-operator.yaml na linha de comando. Esse arquivo contém informações sobre o projeto e o cluster exigidos pelo Anthos Service Mesh. Faça o download de um pacote que contenha istio-operator.yaml e outros arquivos de configuração de recursos para que seja possível definir as informações do projeto e do cluster.

Para preparar os arquivos de configuração de recursos, siga estas etapas:

CA da malha

1. Crie um novo diretório para os arquivos de configuração do recurso do pacote Anthos Service Mesh. Recomendamos que você use o nome do cluster como o nome do diretório.

2. Altere para o diretório em que você quer fazer o download do pacote do Anthos Service Mesh.

3. Verifique a versão do kpt. Verifique se você está executando uma versão antes da 1.x do kpt:

   kpt version
   

   A saída será semelhante a:

   0.39.2

   Se você tiver a versão 1.x ou posterior do kpt, consulte Como configurar seu ambiente para fazer o download da versão necessária para seu sistema operacional.

4. Faça o download do pacote:

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm
   

5. Defina o ID do projeto em que o cluster foi criado:

   kpt cfg set asm gcloud.core.project ${PROJECT_ID}
   

6. Defina o número do projeto host da frota:

   kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
   

7. Defina o nome do cluster:

   kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
   

8. Defina a zona ou a região padrão:

   kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
   

9. Defina a tag para a versão do Anthos Service Mesh que você está instalando:

   kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6
   

10. Defina a revisão nos arquivos de configuração do recurso do pacote do Anthos Service Mesh:

    kpt cfg set asm anthos.servicemesh.rev asm-198-6
    

    Ao instalar o Anthos Service Mesh, você define um rótulo de revisão em istiod. Você precisa definir a mesma revisão no webhook de validação.

11. Como os clusters da sua configuração de vários clusters estão em projetos diferentes, você precisa configurar os aliases de domínio de confiança para os outros projetos que formarão a malha de serviço de vários clusters/vários projetos.

    1. Encontre o ID do projeto de todos os clusters que estarão na malha de vários clusters/vários projetos.

    2. Para o ID do projeto de cada cluster, defina os aliases do domínio de confiança. Por exemplo, se você tiver clusters em três projetos, execute o seguinte comando e substitua PROJECT_ID_1, PROJECT_ID_2 e PROJECT_ID_3 pelo ID do projeto de cada cluster.

       kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog

       Ao configurar os clusters nos outros projetos, é possível usar o mesmo comando.

       Os aliases de domínio de confiança permitem que a CA da malha autentique cargas de trabalho em clusters em outros projetos. Além de definir os aliases de domínio de confiança, depois de instalar o Anthos Service Mesh, você precisa ativar o balanceamento de carga entre clusters.

12. Gere os valores dos setters kpt:

    kpt cfg list-setters asm
    

    A saída deste comando é semelhante a:

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gke.gcr.io/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.9.8-asm.6
    anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
    base-dir                                             base
    gcloud.compute.location                              us-central
    gcloud.compute.network                               default
    gcloud.compute.subnetwork                            default
    gcloud.container.cluster                             example-cluster-1
    gcloud.container.cluster.clusterSecondaryRange
    gcloud.container.cluster.releaseChannel              REGULAR
    gcloud.container.cluster.servicesSecondaryRange
    gcloud.container.nodepool.max-nodes                  4
    gcloud.core.project                                  example-project-12345
    gcloud.project.environProjectID                      FLEET_PROJECT_ID
    gcloud.project.environProjectNumber                  1234567890123
    gcloud.project.projectNumber                         9876543210987

    Verifique se os valores dos seguintes setters estão corretos:

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • anthos.servicemesh.trustDomainAliases
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Você pode ignorar os valores dos outros setters.

CA do Istio

1. Crie um novo diretório para os arquivos de configuração do recurso do pacote Anthos Service Mesh. Recomendamos que você use o nome do cluster como o nome do diretório.

2. Altere para o diretório em que você quer fazer o download do pacote do Anthos Service Mesh.

3. Verifique a versão do kpt. Verifique se você está executando uma versão antes da 1.x do kpt:

   kpt version
   

   A saída será semelhante a:

   0.39.2

   Se você tiver a versão 1.x ou posterior do kpt, faça o download da versão necessária:

   curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
   chmod +x kpt_0_39_2
   alias kpt="$(readlink -f kpt_0_39_2)"
   

4. Faça o download do pacote:

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm
   

5. Defina o ID do projeto em que o cluster foi criado:

   kpt cfg set asm gcloud.core.project ${PROJECT_ID}
   

6. Defina o número do projeto host da frota:

   kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
   

7. Defina o nome do cluster:

   kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
   

8. Defina a zona ou a região padrão:

   kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
   

9. Defina a tag para a versão do Anthos Service Mesh que você está instalando:

   kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6
   

10. Defina a revisão nos arquivos de configuração do recurso do pacote do Anthos Service Mesh:

    kpt cfg set asm anthos.servicemesh.rev asm-198-6
    

11. Gere os valores dos setters kpt:

    kpt cfg list-setters asm
    

    A saída deste comando é semelhante a:

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gke.gcr.io/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.9.8-asm.6
    anthos.servicemesh.trustDomainAliases
    base-dir                                             base
    gcloud.compute.location                              us-central
    gcloud.compute.network                               default
    gcloud.compute.subnetwork                            default
    gcloud.container.cluster                             example-cluster-1
    gcloud.container.cluster.clusterSecondaryRange
    gcloud.container.cluster.releaseChannel              REGULAR
    gcloud.container.cluster.servicesSecondaryRange
    gcloud.container.nodepool.max-nodes                  4
    gcloud.core.project                                  example-project-12345
    gcloud.project.environProjectID                      FLEET_PROJECT_ID
    gcloud.project.environProjectNumber                  1234567890123
    gcloud.project.projectNumber                         9876543210987

    Verifique se os valores dos seguintes setters estão corretos:

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Você pode ignorar os valores dos outros setters.

Como fazer upgrade do Anthos Service Mesh

CA da malha

1. Verifique se o contexto kubeconfig atual está apontando para o cluster em que você quer instalar o Anthos Service Mesh:

   kubectl config current-context
   

   A saída está no seguinte formato:

   gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

   O contexto kubeconfig e os valores dos setters kpt precisam ser correspondentes. Se necessário, execute o comando gcloud container clusters get-credentials para definir o contexto kubeconfig atual.

2. Se necessário, mude para o diretório istio-1.9.8-asm.6. O cliente istioctl depende da versão. Certifique-se de usar a versão no diretório istio-1.9.8-asm.6/bin.

3. Execute o seguinte comando para implantar o novo plano de controle com o perfil asm-gcp-multiproject. Se você quiser ativar um recurso opcional compatível, inclua -f e o nome de arquivo YAML na linha de comando a seguir. Para ver mais informações, consulte Como ativar recursos opcionais.

   Importante: se você estiver instalando no GKE 1.15, adicione o arquivo de sobreposição -f asm/istio/options/v1beta1-crds.yaml, além dos arquivos de sobreposição especificados no comando a seguir.

   bin/istioctl install \
     -f asm/istio/istio-operator.yaml \
     -f asm/istio/options/multiproject.yaml \
     -f asm/istio/options/multicluster.yaml \
     -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
     --revision=asm-198-6
   

   O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-198-6 a istiod. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Para ativar a injeção automática de sidecar em um namespace, você precisa rotulá-lo com uma revisão correspondente a uma implantação istiod.

   Os arquivos a seguir modificam as configurações no arquivo istio-operator.yaml:

   • O arquivo multiproject.yaml define o perfil asm-gcp-multiproject.

   • O arquivo multicluster.yaml define as configurações que o Anthos Service Mesh precisa para uma configuração de vários clusters.

   • O arquivo revisioned-istio-ingressgateway.yaml configura uma implantação revisada para o istio-ingressgateway.

4. Verifique se os pods do plano de controle em istio-system estão ativos:

   kubectl get pods -n istio-system
   

   Exemplo de saída:

   NAME                                        READY   STATUS    RESTARTS   AGE
   istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
   istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
   istiod-asm-198-6-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
   istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

   Você tem duas implantações e serviços de plano de controle em execução lado a lado.

5. Implante o controlador de serviços canônicos no cluster:

   kubectl apply -f asm/canonical-service/controller.yaml

   O controlador de serviços canônicos agrupa cargas de trabalho que pertencem ao mesmo serviço lógico. Para mais informações sobre os serviços canônicos, consulte a visão geral dos serviços canônicos.

CA do Istio

1. Verifique se o contexto kubeconfig atual está apontando para o cluster em que você quer instalar o Anthos Service Mesh:

   kubectl config current-context
   

   A saída está no seguinte formato:

   gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

   O contexto kubeconfig e os valores dos setters kpt precisam ser correspondentes. Se necessário, execute o comando gcloud container clusters get-credentials para definir o contexto kubeconfig atual.

2. Se necessário, mude para o diretório istio-1.9.8-asm.6. O cliente istioctl depende da versão. Certifique-se de usar a versão no diretório istio-1.9.8-asm.6/bin.

3. Execute o seguinte comando para implantar o novo plano de controle com o perfil asm-gcp-multiproject. Se você quiser ativar um recurso opcional compatível, inclua -f e o nome de arquivo YAML na linha de comando a seguir. Para ver mais informações, consulte Como ativar recursos opcionais.

   Importante: se você estiver instalando no GKE 1.15, adicione o arquivo de sobreposição -f asm/istio/options/v1beta1-crds.yaml, além dos arquivos de sobreposição especificados no comando a seguir.

   bin/istioctl install \
     -f asm/istio/istio-operator.yaml \
     -f asm/istio/options/citadel-ca.yaml \
     -f asm/istio/options/multiproject.yaml \
     -f asm/istio/options/multicluster.yaml \
     -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
     --revision=asm-198-6
   

   O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-198-6 a istiod. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Para ativar a injeção automática de sidecar em um namespace, você precisa rotulá-lo com uma revisão correspondente a uma implantação istiod.

   Os arquivos a seguir modificam as configurações no arquivo istio-operator.yaml:

   • O citadel-ca.yaml configura a CA do Istio como autoridade de certificação.

   • O arquivo multiproject.yaml define o perfil asm-gcp-multiproject.

   • O arquivo multicluster.yaml define as configurações que o Anthos Service Mesh precisa para uma configuração de vários clusters.

   • O arquivo revisioned-istio-ingressgateway.yaml configura uma implantação revisada para o istio-ingressgateway.

4. Verifique se os pods do plano de controle em istio-system estão ativos:

   kubectl get pods -n istio-system
   

   Exemplo de saída:

   NAME                                        READY   STATUS    RESTARTS   AGE
   istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
   istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
   istiod-asm-198-6-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
   istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

   Você tem duas implantações e serviços de plano de controle em execução lado a lado.

5. Implante o controlador de serviços canônicos no cluster:

   kubectl apply -f asm/canonical-service/controller.yaml

   O controlador de serviços canônicos agrupa cargas de trabalho que pertencem ao mesmo serviço lógico. Para mais informações sobre os serviços canônicos, consulte a visão geral dos serviços canônicos.

Como implantar e reimplantar cargas de trabalho

A instalação não é completa até você ativar a injeção automática de proxy de arquivo secundário (injeção automática). As migrações do OSS Istio e os upgrades seguem o processo de upgrade baseado na 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 atual. Depois, transfira algumas 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.

Ao executar istioctl install, você define um rótulo de revisão no formato istio.io/rev=asm-198-6 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 do sidecar para associar os sidecars 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.

Se você incluiu revisioned-istio-ingressgateway.yaml ao executar istioctl install, uma implantação revisada será configurada para o istio-ingressgateway. Assim, você pode controlar quando muda para a nova versão.

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

   1. Observe se você tem as versões antigas e novas de istio-ingressgateway.

      • Se você tiver incluído a opção revisioned-istio-ingressgateway ao fazer upgrade, um upgrade canário do istio-ingressgateway será feito. Nesse caso, sua saída mostrará as versões antigas e novas de istio-ingressgateway.

      • Se você não incluiu revisioned-istio-ingressgateway quando fez upgrade, um upgrade no local do istio-ingressgateway foi feito. Nesse caso, o resultado mostrará apenas a nova versão.

   2. Na saída, na coluna REV, anote o valor do rótulo de revisão da nova versão. Neste exemplo, o valor é asm-198-6.

   3. 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-186-8.

2. Se você tiver as versões antigas e novas do istio-ingressgateway, mude o 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 a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection

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

   kubectl rollout restart deployment -n NAMESPACE

5. Verifique se os pods estão configurados para apontar para a nova versão de istiod.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

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

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

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

9. Execute o seguinte comando novamente para confirmar se você tem as versões antigas e novas do istio-ingressgateway ou apenas a nova versão. Isso determina como você processará a transição para a nova versão do istio-ingressgateway ou a reversão para a versão antiga.

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

   Cuidado: não execute comandos que excluam a implantação istio-ingressgateway se você tiver apenas a nova versão do istio-ingressgateway. Isso impedirá que o tráfego entre na malha de serviço.

   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. Se você tiver as versões antigas e novas do istio-ingressgateway, 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 Anthos 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 Anthos 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
      

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

      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

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

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

   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. Volte para a versão antiga de istio-ingressgateway. O comando usado depende de você ter as versões antigas e novas do istio-ingressgateway ou apenas a nova versão.

      • Se você tiver as versões antigas e novas do istio-ingressgateway, execute o comando kubectl patch service e substitua OLD_REVISION pela revisão antiga.

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

      • Se você tiver apenas a nova versão do istio-ingressgateway, execute o comando kubectl rollout undo.

        kubectl -n istio-system rollout undo deploy istio-ingressgateway
        

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

      Saída esperada:

      namespace/NAMESPACE labeled

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

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

   5. Se você tiver as versões antigas e novas do istio-ingressgateway, 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
      

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

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

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

A seguir

• Implantar o aplicativo de amostra Online Boutique
• Como configurar uma malha de vários clusters