Você está vendo a documentação do Anthos Service Mesh 1.8. Veja uma mais recente ou selecione outra versão disponível:

Como migrar do Istio para o Anthos Service Mesh

Esta página faz parte de um guia de várias páginas que explica como migrar do Istio para a versão 1.8.6 do Anthos Service Mesh em um cluster do GKE para uma malha que contém vários clusters que estão em diferentes projetos do Cloud.

Para migrações em uma malha de cluster único ou para uma malha que contém vários clusters no mesmo projeto do Cloud, consulte Instalação, migração e upgrade para o GKE.

Antes de começar

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

Como se preparar para a migração

Leia Como se preparar para migrar do Istio.

Para migrar do Istio, siga o processo de upgrade de revisão, conhecido como upgrades "canário" na documentação do Istio. Com um upgrade baseado em revisão, você instala uma nova revisão do plano de controle com o plano de controle atual. Ao executar istioctl install, você inclui uma opção para definir 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 em suas cargas de trabalho e realizando uma reinicialização gradual para injetar novamente os proxies com 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, é 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 um novo plano de controle substitui imediatamente a versão anterior do plano de controle.

Como configurar credenciais e permissões

  1. Inicialize seu projeto para prepará-lo para instalação. Entre outras coisas, este comando cria uma conta de serviço para permitir componentes de plano de controle, como o proxy sidecar, para acessar com segurança os dados e os recursos do seu projeto:

    curl --request POST \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --data '' \
      "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"

    A resposta do comando mostra chaves vazias: {}

  2. 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}
    
  3. 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.8.6-asm.8-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.8.6-asm.8-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.8.6-asm.8-linux-amd64.tar.gz.1.sig istio-1.8.6-asm.8-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.8.6-asm.8-linux-amd64.tar.gz

    O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.8.6-asm.8, 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.8.6-asm.8
  5. macOS

  6. 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.8.6-asm.8-osx.tar.gz
  7. 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.8.6-asm.8-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.8.6-asm.8-osx.tar.gz.1.sig istio-1.8.6-asm.8-osx.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    A saída esperada é Verified OK.

  8. 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.8.6-asm.8-osx.tar.gz

    O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.8.6-asm.8, 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.

  9. Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.
    cd istio-1.8.6-asm.8
  10. Windows

  11. 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.8.6-asm.8-win.zip
  12. 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.8.6-asm.8-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.8.6-asm.8-win.zip.1.sig istio-1.8.6-asm.8-win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    A saída esperada é Verified OK.

  13. 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.8.6-asm.8-win.zip

    O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado istio-1.8.6-asm.8, 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.

  14. Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.
    cd istio-1.8.6-asm.8

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.8-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.8.6-asm.8
    
  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-186-8
    

    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               gcr.io/gke-release/asm/canonical-service-controller:1.8.6-asm.8
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gcr.io/gke-release/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.8.6-asm.8
    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.8-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.8.6-asm.8
    
  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-186-8
    
  11. Gere os valores dos setters kpt:

    kpt cfg list-setters asm
    

    A saída deste comando é semelhante a:

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.8.6-asm.8
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gcr.io/gke-release/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.8.6-asm.8
    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 migrar para o 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.8.6-asm.8. O cliente istioctl depende da versão. Certifique-se de usar a versão no diretório istio-1.8.6-asm.8/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.

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

    O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-186-8 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 para um namespace, rotule-o 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-186-8-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.

Citadel

  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.8.6-asm.8. O cliente istioctl depende da versão. Certifique-se de usar a versão no diretório istio-1.8.6-asm.8/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.

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

    O argumento --revision adiciona um rótulo de revisão no formato istio.io/rev=asm-186-8 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 para um namespace, rotule-o 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 citadel-ca.yaml configura o Citadel como a CA.

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

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

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

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

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

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

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

      Migrate

      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.

      Migrate

      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 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-ingressgatewqy. No comando a seguir, 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"}]'
      
    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
        

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