Como migrar do Istio 1.7 ou posterior para o Anthos Service Mesh e o Mesh CA

Neste documento, descrevemos como os administradores do Google Kubernetes Engine (GKE) podem instalar o Anthos Service Mesh e migrar as cargas de trabalho em execução atualmente com uma malha de serviço do Istio. A configuração implantada do Mesh Service Mesh inclui o Cloud Monitoring para telemetria e a autoridade de certificação do Mesh Service Mesh (Mesh CA) para o gerenciamento de certificados de malha gerenciados de alta disponibilidade. Gateways, serviços virtuais e outras configurações de malha que definem a topologia da malha são preservadas na migração.

Esse processo abrange uma instalação de cluster único. Para uma instalação de malha de vários clusters, consulte Como configurar uma malha de vários clusters no GKE, que inclui etapas para adicionar clusters ao Anthos Service Mesh. pós-instalação.

Para concluir as etapas deste documento, é preciso usar o Istio 1.7 ou posterior com um cluster do GKE. O Anthos Service Mesh não é compatível com o Helm para instalação ou configuração. Recomendamos que os administradores da malha usem a API IstioOperator para configurações de malha. Esse processo pode gerar inatividade para seu aplicativo ao alternar as autoridades de certificação. Portanto, recomendamos que você execute esse processo durante uma janela de manutenção programada.

O Anthos Service Mesh usa as mesmas APIs Istio e Envoy para configurar sua malha. Portanto, nenhuma alteração nos recursos atuais é necessária.

Veja a seguir algumas diferenças de implementação após a migração:

  • O plano de controle do Istio é substituído por um plano de controle do Anthos Service Mesh.

  • A autoridade de certificação do Citadel foi removida, e os certificados são gerenciados por um serviço de CA Mesh do Google Cloud.

  • A telemetria é enviada ao Cloud Logging e ao Cloud Monitoring. Painéis e gerenciamento de SLO estão disponíveis no Console do Google Cloud.

  • Se você tiver um recurso IstioOperator personalizado, o script poderá usá-lo como uma entrada.

  • A instalação do Istio de código aberto (versão 1.7 ou posterior) é migrada para a versão 1.10 do Anthos Service Mesh com o Mesh CA. Se você tiver uma versão diferente do Istio ou precisar de uma versão diferente do Anthos Service Mesh ou quiser implantar o Anthos Service Mesh com um plano de controle gerenciado pelo Google, consulte Prepare-se para migrar do Istio.

Pré-requisitos

Os seguintes pré-requisitos são necessários para concluir este guia:

  • Você tem um cluster do GKE com o Istio versão 1.7 ou posterior instalado. Se você não tiver um cluster do GKE ou quiser testar primeiro este guia em um novo cluster (de teste), siga as etapas no Apêndice para criá-lo. Um novo cluster do GKE com o Istio versão 1.7 ou posterior implantado com um aplicativo de teste.

  • Use o Cloud Shell para executar as etapas deste guia porque ele é testado no Cloud Shell.

Objetivos

Neste guia, você escolhe um caminho de migração. É possível escolher entre um caminho com script de uma etapa ou uma migração com script passo a passo.

Para mais informações, consulte Escolher um caminho de migração.

Para receber respostas para perguntas frequentes sobre essa migração, consulte Perguntas frequentes sobre como migrar do Istio 1.7 ou posterior para o Anthos Service Mesh e o Mesh CA.

Antes de começar

Para este guia, você precisa ter acesso administrativo a um cluster do GKE com o Istio instalado. Para observar como seu aplicativo se comporta durante o processo de migração, recomendamos que você primeiro execute esse processo com um cluster em um ambiente de desenvolvimento ou preparo.

O Anthos Service Mesh tem os requisitos a seguir. É possível executá-los manualmente ou permitir que as ferramentas fornecidas ativem dependências em seu nome durante o processo de pré-instalação.

  1. Ative as seguintes APIs do Google Cloud:

    • container.googleapis.com
    • meshca.googleapis.com
    • meshconfig.googleapis.com
    • gkehub.googleapis.com
    • stackdriver.googleapis.com

  2. Ative a Identidade da carga de trabalho e o Stackdriver para seu cluster GKE.

  3. Rotule seu cluster para ativar a interface do usuário do Serviço.

  4. Receba direitos de administrador de cluster no cluster do Kubernetes.

  5. Registre o cluster em uma frota.

  6. Ative o recurso servicemesh na frota.

Configure o ambiente

Para configurar o ambiente, siga estas etapas:

  1. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a Google Cloud CLI já instalada e com valores já definidos para seu projeto atual. A inicialização da sessão pode levar alguns segundos.

  2. Crie as variáveis de ambiente usadas neste guia:

    export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE

  3. Criar uma pasta WORKDIR:

    mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`

  4. Crie um arquivo KUBECONFIG para este guia:

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. Conecte-se ao seu cluster do GKE:

    Clusters zonais

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --zone ${CLUSTER_LOCATION}

    Clusters regionais

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --region ${CLUSTER_LOCATION}

  6. Faça o download do script de migração:

    curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
chmod +x ./migrate-to-asm

Escolher um caminho de migração

Escolha um dos dois caminhos para migrar para o Anthos Service Mesh. Escolha apenas uma dessas duas estratégias e prossiga para a seção:

  • Migração em uma etapa para o Anthos Service Mesh Como o nome sugere, é possível executar todas as etapas necessárias para migrar para o Anthos Service Mesh usando um único comando. Isso pode ser benéfico se você tiver muitos clusters e precisar de uma maneira rápida e fácil de fazer upgrade para o Anthos Service Mesh. No entanto, esse método pode resultar em tempo de inatividade do aplicativo.

  • Migração passo a passo para o Anthos Service Mesh. Esse método oferece mais controle sobre cada etapa e ajuda a entender exatamente o que é necessário para migrar para o Anthos Service Mesh.

Migração em uma etapa para o Anthos Service Mesh

Nesta seção, você migra sua instalação atual do Istio versão 1.7 (ou posterior) para o Anthos Service Mesh versão 1.10. Esta seção permite executar a migração executando uma única etapa. Se você quiser executar a migração executando uma série de etapas, consulte a seção Migração passo a passo para o Anthos Service Mesh.

Para migrar para o Anthos Service Mesh, execute o seguinte comando. Com qualquer comando, é possível usar a sinalização --dry-run para imprimir comandos em vez de executá-los ou usar a sinalização --verbose para imprimir comandos à medida que o script os executa. Se você já tiver configurado dependências, conforme observado na seção Antes de começar, poderá omitir a sinalização --enable-dependencies.

Nenhum recurso personalizado

Não use um recurso IstioOperator personalizado:

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

Usar recurso personalizado

Use um recurso IstioOperator personalizado:

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

Esse comando executa as seguintes etapas:

  • Garante que a versão do Istio seja 1.7 ou posterior.
  • Ativa a identidade da carga de trabalho no cluster. A identidade da carga de trabalho é necessária para a CA da malha. Não é necessário ativar o servidor de metadados do GKE nos pools de nós atuais.
  • Ativa as APIs necessárias para o Anthos Service Mesh.
  • Registra o cluster em uma frota.
  • Atualiza o cluster com os rótulos necessários.
  • Avalia se um plano de controle gerenciado pelo Google é melhor para o cluster especificado.
  • Implanta o Anthos Service Mesh com a configuração ideal do plano de controle.
  • Remarca todos os namespaces ativados para o Istio com o rótulo necessário do Anthos Service Mesh.
  • Reinicia as cargas de trabalho em todos os namespaces ativados do Anthos Service Mesh para que as cargas de trabalho recebam os novos proxies do Anthos Service Mesh.
  • Remove o plano de controle do Istio.

Migração passo a passo para o Anthos Service Mesh

Nesta seção, você migrará a instalação da versão 1.7 (ou posterior) do Istio para o Anthos Service Mesh versão 1.10. Esta seção permite executar a migração executando uma série de etapas. Se você quiser realizar a migração em uma única etapa, consulte a seção Migração em uma etapa para o Anthos Service Mesh.

As etapas a seguir são necessárias para migrar para o Anthos Service Mesh:

  1. Execute uma etapa de pré-migração para validar e preparar o cluster e o ambiente para migração para o Anthos Service Mesh.
  2. Instale o Anthos Service Mesh como um plano de controle canário junto com um plano de controle existente do Istio e prepare cargas de trabalho.
  3. Teste as cargas de trabalho no Anthos Service Mesh e rerotule namespaces para a injeção de arquivo secundário do Anthos Service Mesh.
  4. Acessar e inspecionar os painéis do Anthos Service Mesh
  5. Limpe os artefatos do Istio ou reverta para uma versão atual do Istio.

Realizar a etapa de pré-migração

A etapa de pré-migração executa as seguintes ações:

  • Ele valida que as informações do projeto e do cluster estão corretas e que a versão do Istio instalada é compatível com a migração.

  • Ela faz o backup da configuração do gateway padrão e dos rótulos da malha de serviço atual do Istio.

  • Se a sinalização --enable-dependencies for usada, ela ativará as dependências em seu nome. caso contrário, ele verifica se as dependências estão ativadas.

O script de pré-migração cria uma nova pasta (ou substitui uma pasta existente) chamada configuration_backup no diretório atual.

Para executar a etapa de pré-migração, execute o seguinte comando:

Dependências

Ativar dependências:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

Sem dependências

Não ative dependências:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

O resultado será assim:

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Instalar o Anthos Service Mesh e preparar cargas de trabalho

Esta etapa faz o seguinte:

  • Ele verifica a presença da pasta configuration_backup e, se ela não estiver presente, é cancelada para garantir que a ferramenta de pré-migração seja executada com êxito.
  • Ele instala e configura um plano de controle do Anthos Service Mesh com base na análise da configuração do cluster e da malha.
  • Ele usa o recurso IstioOperator personalizado, se houver. Se você tiver gateways personalizados ou se configurou vários gateways usando um recurso IstioOperator, use o mesmo recurso nesta etapa.

Para ignorar a análise e forçar a ferramenta a instalar um plano de controle não gerenciado em execução com os recursos do cluster, adicione a sinalização --no-mcp ao comando.

Escolha um dos três caminhos ao instalar o Anthos Service Mesh:

  • Opção 1: sem um recurso IstioOperator personalizado. É possível instalá-lo sem um recurso personalizado. O uso dessa opção instala a configuração padrão do Istio e atualiza o istio-ingressgateway padrão em vigor.

  • Opção 2: com uma opção --no-gateways. Ao instalar o Anthos Service Mesh sem um recurso IstioOperator personalizado, também é possível usar a opção --no-gateways para não atualizar o istio-ingressgateway padrão em vigor. Se você usar essa opção, vai precisar fazer upgrade dos gateways manualmente após a instalação.

  • Opção 3: com um recurso IstioOperator personalizado. É possível instalar o Anthos Service Mesh com um recurso IstioOperator personalizado. Se você implantou o Istio usando um recurso IstioOperator personalizado, recomendamos usar o mesmo recurso IstioOperator ao instalar o Anthos Service Mesh.

Para instalar o Anthos Service Mesh, execute um dos seguintes comandos:

Opção 1

Atualize o istio-ingressgateway padrão em vigor:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

Opção 2

Não atualize o istio-ingressgateway padrão:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

Opção 3

Faça upgrade dos gateways em vigor com um recurso IstioOperator personalizado:

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

O resultado será assim:

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

Reinjetar cargas de trabalho e verificar o comportamento do aplicativo

O plano de controle do Anthos Service Mesh agora está pronto para lidar com cargas de trabalho, mas o plano de controle atual do Istio ainda está gerenciando as cargas de trabalho atuais. Para migrar essas cargas de trabalho, você precisa remarcar os namespaces do Kubernetes que estão atualmente rotulados para a injeção do Istio com o rótulo de revisão do Anthos Service Mesh. Em seguida, será preciso reiniciar as cargas de trabalho nesses namespaces. É possível fazer isso manualmente (veja a Nota na etapa 1) ou em uma etapa usando a ferramenta.

A etapa de remarcação realiza o seguinte:

  • Ele encontra todos os namespaces que atualmente usam um rótulo de injeção do Istio.
  • Ele rotula esses namespaces novamente com istio.io/rev=asm-1102-2.
  • Ele reinicia as cargas de trabalho no namespace.

Para reinjetar as cargas de trabalho, siga estas etapas:

  1. Rotule todos os namespaces ativados para o Istio e reinicie as cargas de trabalho executando o seguinte comando:

     ./migrate-to-asm relabel \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

    O resultado será assim:

    migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for $CLUSTER_NAME.
migrate-to-asm:
migrate-to-asm: Verifying connectivity (20s)...
migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
******
migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with migration? (Y/n)Y
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!

  2. Aguarde até que todas as implantações sejam reiniciadas e verifique a versão do plano de dados executando o seguinte comando:

    istioctl version

    O resultado será assim:

    client version: 1.8.0
pilot version: 1.9.5
istiod version: 1.10.2-asm.2
data plane version: 1.10.2-asm.2 (14 proxies)

  3. Verifique se os aplicativos estão funcionando corretamente após a reinicialização.

Acessar os painéis do Anthos Service Mesh

Nesta seção, você acessa os painéis do Anthos Service Mesh e verifica se está recebendo os sinais de ouro de todos os Serviços. Você também verá a topologia do seu aplicativo.

  1. No Console do Google Cloud, acesse a página do Anthos Service Mesh.

    Acesse o Anthos Service Mesh

  2. Você verá as métricas e a topologia dos seus serviços.

Para saber mais sobre os painéis do Anthos Service Mesh, consulte Como explorar o Anthos Service Mesh no console do Google Cloud.

Finalize a migração

Antes de finalizar a migração, verifique se todos os aplicativos estão funcionando corretamente. Depois de concluir a migração, não será possível reverter para a versão atual do Istio. A finalização da migração executa as etapas a seguir:

  • Ele valida que todos os proxies em execução no cluster estão usando malha de serviço.
  • Ele remove os componentes não utilizados do Istio do cluster. Essa etapa é irreversível.

Para concluir a migração para o Anthos Service Mesh, execute o seguinte comando:

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
O resultado será assim: 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

Reverter para uma versão existente do Istio

Execute a etapa de reversão para remarcar namespaces com o rótulo de injeção anterior do Istio, reiniciar cargas de trabalho e reverter alterações de gateway. Depois, a ferramenta remove todos os componentes do Anthos Service Mesh implantados no cluster.

Você precisa reverter manualmente todas as dependências ativadas pela etapa de pré-migração.

Para reverter ao Istio, execute o seguinte comando:

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
O resultado será assim: 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

Apêndice

Criar um cluster do GKE com o Istio instalado

Nesta seção, você implantará um cluster do GKE com o Istio ativado. É possível usar um cluster do GKE particular ou não particular. Os clusters privados do GKE precisam ter um endpoint público do GKE. Você também verifica a instalação do Istio.

Se você já tiver um cluster do GKE, pule a etapa de criação e verifique se tem acesso ao cluster que usa o arquivo KUBECONFIG. O contexto usado por este guia é definido na variável ${CLUSTER_1_CTX}. É possível definir o contexto do cluster como essa variável.

  1. Crie as variáveis de ambiente usadas neste guia:

    # Enter your project ID
export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5

  2. Criar um cluster do GKE com o Istio ativado (este é um cluster particular). Também é possível executar essas etapas com um cluster não particular do GKE.

    Clusters zonais

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --zone ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

    Clusters regionais

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --region ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

  3. Confirme se o cluster é RUNNING:

     gcloud container clusters list

    O resultado será assim:

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING

  4. Conecte-se ao cluster:

    Clusters zonais

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION}

    Clusters regionais

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --region ${CLUSTER_LOCATION}

Lembre-se de desativar a variável KUBECONFIG no final.

Instalar o Istio

Nesta seção, você implantará a versão 1.7 do Istio no cluster do GKE.

  1. Fazer o download do Istio:

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -

  2. Instale o Istio usando a ferramenta de linha de comando istioctl. Escolha uma das opções a seguir:

    • Opção 1: sem um recurso IstioOperator personalizado

    • Opção 2: com um recurso IstioOperator personalizado

    Opção 1

    Sem um recurso IstioOperator personalizado:

    ./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y

    O resultado será assim:

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

    Opção 2

    Com um recurso IstioOperator personalizado:

    cat <<EOF > istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 name: istio-operator
spec:
 components:
   base:
     enabled: true
   ingressGateways:
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         metrics:
         - resource:
             name: cpu
             targetAverageUtilization: 80
           type: Resource
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     name: istio-ingressgateway
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     label:
       istio: istio-api-ingressgateway
     name: istio-api-ingressgateway
 meshConfig:
   defaultConfig:
     tracing:
       sampling: 1
       zipkin:
         address: jaeger-collector.observability.svc.cluster.local:9411
   enableTracing: true
EOF

./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y

    O resultado será assim:

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

  3. Verifique se os serviços e pods do Istio estão implantados e em execução:

    kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods

    O resultado será assim:

    Opção 1

    Sem um recurso IstioOperator personalizado:

    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s

NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s

    Opção 2

    Com um recurso IstioOperator personalizado:

    NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s

Implantar Boutique on-line

Nesta seção, você implantará um aplicativo baseado em microsserviços de amostra chamado "Online Boutique" no cluster do GKE. O Online Boutique é implantado em um namespace ativado para o Istio. Você verifica se o aplicativo está funcionando e se o Istio está injetando os proxies sidecar em cada pod.

Se você já tiver clusters com aplicativos, poderá ignorar a criação de um novo namespace e a implantação do Online Boutique. É possível seguir o mesmo processo para todos os namespaces na seção Instalar o Anthos Service Mesh e preparar cargas de trabalho.

  1. Implante o Online Boutique no cluster do GKE:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique

  2. Aguarde até que todas as implantações estejam prontas:

    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

  3. Verifique se há dois contêineres por pod: o contêiner do aplicativo e o proxy sidecar do Istio que o Istio injeta automaticamente no pod:

    kubectl --context=${CLUSTER_CTX} -n online-boutique get pods

    O resultado será assim:

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

  4. Também é possível verificar a versão do proxy sidecar do Envoy de qualquer um dos pods para confirmar que você tem proxies do Envoy do Istio versão 1.4 implantados:

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

    O resultado será assim:

    "docker.io/istio/proxyv2:1.7.4"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

  5. Acesse o aplicativo navegando até o endereço IP do endereço IP do serviço istio-ingressgateway:

    kubectl --context=${CLUSTER_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

A seguir