Como migrar do Istio no GKE para o Cloud Service Mesh

Neste guia, mostramos como fazer upgrade de um cluster do Google Kubernetes Engine (GKE) com Istio no Google Kubernetes Engine (Istio no GKE) versão 1.4 ou 1.6 (Beta) para e o Cloud Service Mesh gerenciado pelo Google plano de controle de acesso e a autoridade de certificação do Cloud Service Mesh.

Pré-requisitos

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

• Um cluster do GKE com o Istio ativado. Se você tiver vários clusters do GKE, siga as mesmas etapas para todos eles.

• O Istio no GKE precisa ser a versão 1.4 ou 1.6.

• Verifique se você está executando o GKE versão 1.17.17-gke.3100 ou superior, 1.18.16-gke.1600 ou superior, 1.19.8-gke.1600 ou superior.

• O cluster do GKE precisa estar sendo executado em um desses locais.

• A conta de usuário ou de serviço que executa esse script requer as permissões do IAM documentadas em Como configurar o projeto.

• Este guia é testado no Cloud Shell. Por isso, recomendamos que você use o Cloud Shell para executar as etapas dele.

Objetivos

• Implante o plano de controle gerenciado pelo Google do Cloud Service Mesh no canal normal. Este guia é específico para o canal normal. Canais estáveis ou rápidos exigem instruções ligeiramente modificadas. Para saber mais sobre os canais de lançamento, acesse este link.
• Migrar as configurações do Istio para o Cloud Service Mesh.
• Configure a autoridade certificadora do Cloud Service Mesh.
• Migrar aplicativos para o Cloud Service Mesh.
• Faça upgrade de istio-ingressgateway do Istio no GKE para o Cloud Service Mesh.
• Finalize a migração do Cloud Service Mesh ou reverter para o Istio no GKE.

Configurar 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 de baixo da página do console do Google Cloud, Cloud Shell sessão é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a Google Cloud CLI e a Google Cloud CLI já instaladas e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

   Observação: o script não funciona no macOS. O script foi testado apenas no Cloud Shell. O script requer os seguintes aplicativos, todos incluídos por padrão no Cloud Shell:

   • gcloud (versão 346.0.0 e mais recentes)
   • kubectl (versão 1.21 e mais recentes do cliente)
   • jq
   • sed
   • curl
   • awk

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

   # Enter your project ID
   export PROJECT_ID=PROJECT_ID
   
   # Copy and paste the following
   gcloud config set project ${PROJECT_ID}
   export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
   export CLUSTER_1=GKE_CLUSTER_NAME
   export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
   export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.
   

3. Criar uma pasta WORKDIR. Todos os arquivos associados a este guia terminam em WORKDIR para que você possa excluir WORKDIR quando terminar.

   mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
   

4. Crie um arquivo KUBECONFIG para este guia. Você também pode usar o arquivo KUBECONFIG atual que contém o contexto do cluster para o Cluster do GKE a ser migrado para o Cloud Service Mesh.

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

5. Receba as credenciais para o cluster do GKE e armazene o contexto em uma variável:

   Clusters zonais

   gcloud container clusters get-credentials ${CLUSTER_1} \
     --zone=${CLUSTER_1_LOCATION}
   
   export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
   

   Clusters regionais

   gcloud container clusters get-credentials ${CLUSTER_1} \
     --region=${CLUSTER_1_LOCATION}
   
   export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
   

6. Os clusters precisam estar registrados em uma frota. Esta etapa pode ser feita separadamente antes da instalação ou como parte da instalação passando a sinalização --fleet-id e uma das sinalizações --enable-all ou --enable-registration.

7. O projeto precisa ter o recurso Service Mesh ativado. Para ativá-lo como parte da instalação, transmita uma das sinalizações --enable-all ou --enable-registration ou execute o seguinte comando antes da instalação:

     gcloud container hub mesh enable --project=FLEET_PROJECT_ID
   

   FLEET_PROJECT_ID é o ID do projeto host da frota.

Etapa opcional

Se o cluster for particular (com master-authorized-networks ativado), adicione seu $SHELL_IP à lista de permissões master-authorized-networks. Se você já tiver acesso ao cluster, esta etapa talvez não seja necessária.

Clusters zonais

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --zone=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

Clusters regionais

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --region=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

Instalar o Cloud Service Mesh

Nesta seção, você implanta o Cloud Service Mesh com o plano de controle gerenciado pelo Google do canal normal no cluster do GKE. Esse plano de controle é implantado inicialmente junto com um segundo plano de controle (ou canário).

1. Faça o download da versão mais recente do script que instala o Cloud Service Mesh no diretório de trabalho atual e torne o script executável:

   curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
   chmod +x asmcli
   

2. Para configurar o cluster do GKE, execute o script de instalação para instalar o Cloud Service Mesh com o plano de controle gerenciado pelo Google do canal regular:

   ./asmcli install \
   -p ${PROJECT_ID} \
   -l ${CLUSTER_1_LOCATION} \
   -n ${CLUSTER_1} \
   --fleet_id ${FLEET_PROJECT_ID} \
   --managed \
   --verbose \
   --output_dir ${CLUSTER_1} \
   --enable-all \
   --channel regular
   

   Esse processo leva alguns minutos para ser concluído.

3. Verificar o plano de controle gerenciado pelo Google

4. Copie istioctl para a pasta WORKDIR:

   cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
   

Na próxima seção, você fará o download e executará o script migrate_addon para ajudar na migração para o Cloud Service Mesh. O utilitário de linha de comando istioctl precisa estar na mesma pasta que o script migrate_addon. Use a pasta WORKDIR para o utilitário de linha de comando istioctl e para o script migrate_addon.

Migrar configurações para o Cloud Service Mesh

Nesta seção, você migra as configurações do Istio no GKE para o Cloud Service Mesh. O script guiado identifica quais configurações podem ou não ser migradas.

1. Faça o download da ferramenta de migração e torne-a executável:

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
   chmod +x ${WORKDIR}/migrate_addon
   

2. Desative o webhook de validação do Galley. Essa etapa é necessária para migrar algumas das configurações 1.4 para o Cloud Service Mesh. Responda Y às duas perguntas:

   ${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook
   

   A saída será assim:

   tmpdir directory not present. Create directory? Continue? [Y/n] Y
   
   Disabling the Istio validation webhook... Continue? [Y/n] Y
   Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml
   Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}]
   clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched
   Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found
   Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found
   validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted
   
   

3. Verifique e migre manualmente a configuração. Essa etapa ajuda a identificar algumas das configurações que precisam ser migradas manualmente antes de migrar as cargas de trabalho para o plano de controle gerenciado pelo Google.

   ${WORKDIR}/migrate_addon -d tmpdir --command config-check
   

   A saída será assim:

   Installing the authentication CR migration tool...
   OK
   
   Checking for configurations that will need to be explicitly migrated...
   No resources found
   

Migrar configurações personalizadas

Talvez seja necessário migrar as configurações personalizadas manualmente antes de migrar para do Cloud Service Mesh. O script anterior identifica as configurações personalizadas e imprime informações sobre o que é necessário. Essas personalizações são as seguintes:

• O Cloud Service Mesh não oferece suporte a filtros envoy personalizados detectados. Remova-as, se possível. No momento, os filtros do Envoy não são compatíveis com o plano de controle gerenciado pelo Google.

• Certificado de plug-in personalizado detectado. Os certificados do plug-in não serão migrados para o Cloud Service Mesh. Se certificados de plug-in forem usados com o Istio no GKE, esses certificados não serão usados após a migração das cargas de trabalho para o plano de controle gerenciado pelo Google. Todos os workloads usam certificados assinados pela autoridade certificadora do Google Cloud Service Mesh. Os certificados de plug-in são não tem suporte da autoridade de certificação do Cloud Service Mesh. Esta mensagem é informativa e nenhuma ação é necessária.

• Políticas de segurança detectadas que não puderam ser migradas. <Motivo do erro>. Isso geralmente falha devido às políticas Alfa AuthZ que precisam ser migradas manualmente. Para mais contexto e informações sobre como migrar políticas, consulte Migrar a política de segurança pré-Istio 1.4 Alfa para as APIs atuais. Para mais informações sobre a mensagem de erro, consulte security-policy-migrate.

• Detectou possivelmente uma configuração incompatível do VirtualService. <Configuração suspensa específica>. Você precisa atualizar as seguintes configurações de VirtualService:

  • Não há suporte para o uso de appendHeaders. Use spec.http.headers, em vez disso.
  • Não é necessário usar websocketUpgrade. Ela está ativada por padrão.
  • Substitua o campo abort.percent por abort.percentage.

• Detectou a instalação personalizada dos recursos do mixer que não puderam ser migrados. Requer migração manual para a telemetriav2. Se as políticas do mixer personalizadas forem configuradas além da instalação padrão do Istio na instalação do GKE, você precisará migrar manualmente essas políticas para a telemetria v2. Para mais informações sobre como fazer isso, consulte Como personalizar métricas do Istio.

• A implantação <deploymentName> pode ser um gateway personalizado. Faça a migração manualmente. Você precisa migrar manualmente todas as implantações de gateway diferentes do istio-ingressgateway (que é instalado por padrão). Para informações sobre como fazer upgrade de gateways do plano de controle gerenciado pelo Google, consulte Como configurar o plano de controle gerenciado pelo Google.

Para migrar configurações, siga estas etapas:

1. Migre manualmente todas as configurações personalizadas (exceto a última listada ) antes de prosseguir para a etapa 2.

2. Use a ferramenta de migração para migrar as configurações que podem ser migradas automaticamente (ou ignoradas).

   ${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs
   

   O resultado será assim:

   Converting authentication CRs...
   2021/06/25 20:44:58 found root namespace: istio-system
   2021/06/25 20:44:59 SUCCESS converting policy /default
   Running: kubectl apply --dry-run=client -f beta-policy.yaml
   peerauthentication.security.istio.io/default created (dry run)
   
   Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y
   Running: kubectl apply -f beta-policy.yaml
   peerauthentication.security.istio.io/default created
   OK
   
   

3. Aplicar a confiança raiz da autoridade certificadora do Cloud Service Mesh. Assim, você pode migrar da atual Citadel CA para autoridade de certificação do Cloud Service Mesh sem incorrer em inatividade aos aplicativos.

   ${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca
   

   O resultado será assim:

   Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y
   Running: kubectl get cm -n istio-system istio-asm-managed -oyaml
   Running: kubectl -n istio-system apply -f -
   secret/meshca-root created
   Running: kubectl get cm istio -n istio-system -o yaml
   Running: kubectl get cm istio -n istio-system -o yaml
   Running: kubectl replace -f -
   configmap/istio replaced
   Running: kubectl get deploy istio-pilot -n istio-system -o yaml
   Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{
       "name":"discovery",
       "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12",
       "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}]
     }]}}}}
   deployment.apps/istio-pilot patched
   Running: kubectl get deploy istio-citadel -n istio-system -o yaml
   Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{
       "containers":[{
         "name":"citadel",
         "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"],
         "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}]
       }],
       "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}]
     }}}}
   deployment.apps/istio-citadel patched
   OK
   
   Waiting for root certificate to distribute to all pods. This will take a few minutes...
   ASM root certificate not distributed to asm-system, trying again later
   ASM root certificate not distributed to asm-system, trying again later
   ASM root certificate distributed to namespace asm-system
   ASM root certificate distributed to namespace default
   ASM root certificate distributed to namespace istio-operator
   ASM root certificate not distributed to istio-system, trying again later
   ASM root certificate not distributed to istio-system, trying again later
   ASM root certificate distributed to namespace istio-system
   ASM root certificate distributed to namespace kube-node-lease
   ASM root certificate distributed to namespace kube-public
   ASM root certificate distributed to namespace kube-system
   ASM root certificate distributed to namespace online-boutique
   Waiting for proxies to pick up the new root certificate...
   OK
   
   Configuring Istio Addon 1.6 to trust Anthos Service Mesh...
   Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found
   Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml
   Running: kubectl replace -f -
   configmap/istio-istio-1611 replaced
   Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge
   istiooperator.install.istio.io/istio-1-6-11-gke-0 patched
   Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem}
   Running: kubectl -n istio-system patch secret istio-ca-secret
   secret/istio-ca-secret patched
   Running: kubectl patch deploy istiod-istio-1611 -n istio-system
   deployment.apps/istiod-istio-1611 patched
   Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system
   Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination...
   deployment "istiod-istio-1611" successfully rolled out
   Running: kubectl apply -f - -n istio-system
   envoyfilter.networking.istio.io/trigger-root-cert created
   Waiting for proxies to pick up the new root certificate...
   Running: kubectl delete envoyfilter trigger-root-cert -n istio-system
   OK
   
   

   Esta etapa leva alguns minutos para o certificado raiz do Cloud Service Mesh para todos os namespaces. Aguarde até que o script termine com uma mensagem OK.

A etapa anterior faz o seguinte:

• Instala a raiz de confiança da autoridade certificadora do Cloud Service Mesh para todas as cargas de trabalho na cluster.

• Altera as configurações das implantações do plano de controle istio-pilot, istiod e istio-citadel. As mudanças incluem o seguinte:

  • Como fazer upgrade das imagens para os builds mais recentes.
  • Desativando a verificação de trust-domain configurando PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
  • Adição da raiz de confiança da autoridade de certificação do Cloud Service Mesh a istio-citadel para distribuir o ConfigMap a todos os namespaces.
  • Adicionar a raiz de confiança da autoridade certificadora do Cloud Service Mesh a istio-ca-secret para distribuir a raiz certificado.

• Armazena os manifestos de configuração mais antigos no tmpdir.

• Fornece etapas para a função de reversão (documentadas posteriormente).

Migrar cargas de trabalho para o Cloud Service Mesh

Nesta seção, você migra cargas de trabalho em execução no Istio no GKE para o Cloud Service Mesh. Após a migração, verifique se o arquivo secundário correto (Cloud Service Mesh) são injetados em cada pod e que o aplicativo está funcionando como esperado.

Se você estiver executando este procedimento em um cluster atual, selecione um namespace a ser migrado.

1. Definir o namespace como uma variável. Esse namespace é migrado para o Cloud Service Mesh:

   export NAMESPACE=NAMESPACE_NAME
   

2. Para migrar cargas de trabalho para o Cloud Service Mesh, é preciso rotular novamente o namespace para o Cloud Service Mesh. Rotular o namespace permite que o Cloud Service Mesh para injetar automaticamente arquivos secundários em todas as cargas de trabalho. Para rotular o namespace, execute o seguinte comando, definindo o rótulo como asm-managed:

   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
   

3. Execute uma reinicialização gradual de todas as implantações no namespace:

   kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
   

   A saída será assim:

   deployment.apps/deploymentName1 restarted
   deployment.apps/deploymentName2 restarted
   ...
   

4. Verifique se todos os pods foram reiniciados e estão em execução com dois contêineres por pod:

   kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
   

   A saída será assim:

   NAME                        READY   STATUS    RESTARTS   AGE
   deploymentName1-PodName     2/2     Running   0          101s
   deploymentName2-PodName     2/2     Running   2          100s
   ...
   

   Uma boa maneira de verificar essa etapa é observar o AGE dos pods. Certifique-se de que o valor seja curto, por exemplo, alguns minutos.

5. Verifique a versão do proxy sidecar do Envoy de qualquer um dos pods de qualquer implantação no namespace para confirmar que agora você tem proxies do Envoy do Cloud Service Mesh implantados:

   export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
   kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
   

   O resultado será assim:

   "gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
   "appContainerImage"
   

6. Verifique e teste seus aplicativos após a reinicialização.

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

7. Se você quiser que o Google gerencie upgrades de proxies, ative o plano de dados gerenciado pelo Google.

Ver o status da migração

Execute o seguinte comando para ver o status da migração:

kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}

A saída indica se as migrações estão concluídas, pendentes ou com falha:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Se migrationStatus gerar SUCCESS, o plano de controle foi atualizado para o Cloud Service Mesh. Para atualizar manualmente o plano de dados, conclua as etapas em Migrar cargas de trabalho.

Se migrationStatus gerar qualquer outro status além de SUCCESS, será possível optar por:

• Não fazer nada a mais se o erro de migração não afetar as cargas de trabalho atuais do Istio no GKE. Caso contrário, reverta, se necessário.
• Atualize as configurações personalizadas no cluster e execute novamente a migração manualmente se migrationStatus mostrar MIGRATION_CONFIG_ERROR.

Você pode ver as métricas do plano de controle no Metrics Explorer após a migração. Veja verify_control_plane_metrics

Acessar painéis do Cloud Service Mesh

Nesta seção, você vai acessar os painéis do Cloud Service Mesh e verificar que você está recebendo os sinais de ouro para todos os Serviços. Você também verá a topologia do seu aplicativo.

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

   Acessar o Cloud Service Mesh

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

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

Observação :a topologia e a visualização em tabela nos painéis do Cloud Service Mesh podem reserve alguns minutos para representar os dados corretos.

Concluir uma migração

Nesta seção, você finaliza a migração do Istio no GKE para o Cloud Service Mesh. Antes de prosseguir com esta seção, verifique se você quer continuar com o Cloud Service Mesh. Esta seção também ajuda você a limpar os artefatos do Istio no GKE. Se você quiser reverter para o Istio no GKE, siga para a próxima seção.

1. Substitua istio-ingressgateway (parte do Istio padrão no GKE) pelo gateway com controle de versão gerenciado pelo plano do Google:

   ${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway
   

   A saída será assim:

   Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y
   Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite
   label "istio.io/rev" not found.
   namespace/istio-system labeled
   Running: kubectl apply -f -
   serviceaccount/asm-ingressgateway created
   deployment.apps/asm-ingressgateway created
   role.rbac.authorization.k8s.io/asm-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created
   Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system
   deployment.apps/asm-ingressgateway condition met
   
   Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y
   Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}}
   horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change)
   Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0
   deployment.apps/istio-ingressgateway scaled
   OK
   

2. reconfigurar o webhook para usar o plano de controle gerenciado pelo Google; todas as cargas de trabalho começam usando o plano de controle gerenciado pelo Google:

   ${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook
   

   O resultado será assim:

   Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y
   Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}]
   mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched
   Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this
   revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default'
   OK
   

3. Rotule todos os namespaces com o rótulo do Cloud Service Mesh e execute uma reinicialização contínua de todas as cargas de trabalho para colocá-las no plano de controle gerenciado pelo Google:

   export NAMESPACE=NAMESPACE_NAME \
       kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
       istio.io/rev=asm-managed istio-injection- --overwrite`
   
       kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
   ${NAMESPACE}
   

   Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente, o que é esperado em novas instalações do Cloud Service Mesh ou em novas implantações. Como a injeção automática falhará se um namespace tiveristio-injection e o rótulo de revisão, kubectl label na documentação do Istio no GKE incluem a remoção doistio-injection rótulo.

4. Finalize a migração executando o seguinte comando:

   ${WORKDIR}/migrate_addon -d tmpdir --command write-marker
   

   A saída será assim:

   Current migration state: SUCCESS
   Running: kubectl apply -f -
   configmap/asm-addon-migration-state created
   OK
   
   

5. Desative o Istio no GKE executando o seguinte comando:

   Clusters zonais

   gcloud beta container clusters update ${CLUSTER_1} \
       --project=$PROJECT_ID \
       --zone=${CLUSTER_1_LOCATION} \
       --update-addons=Istio=DISABLED
   

   Clusters regionais

   gcloud beta container clusters update ${CLUSTER_1} \
       --project=$PROJECT_ID \
       --region=${CLUSTER_1_LOCATION} \
       --update-addons=Istio=DISABLED
   

6. Limpe as configurações executando o seguinte comando:

   ${WORKDIR}/migrate_addon -d tmpdir --command cleanup
   

   A saída será assim:

   Cleaning up old resources...
   Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus}
   Will delete IstioOperator/istio-1-6-11-gke-0.istio-system
   Will delete ServiceAccount/istio-citadel-service-account.istio-system
   ...
   Will delete DestinationRule/istio-policy.istio-system
   Will delete DestinationRule/istio-telemetry.istio-system
   Will delete Secret/istio-ca-secret.istio-system
   
   Deleting resources previously listed... Continue? [Y/n] Y
   Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found
   istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted
   Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found
   serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found
   ...
   Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found
   secret "istio-ca-secret" deleted
   Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security
   job.batch "istio-security-post-install-1.4.10-gke.8" deleted
   

7. Verifique se o Istio nas implantações e nos serviços do GKE foram removidos com êxito do cluster:

   kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services
   

   O resultado será assim:

   NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/asm-ingressgateway   1/1     1            1           10m
   
   NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      AGE   PORT(S)
   service/istio-ingressgateway   LoadBalancer   10.64.5.208   34.139.100.237   95m   15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP
   
   

   Você só vai encontrar o serviço e a implantação do gateway de entrada do Cloud Service Mesh.

Parabéns! Você migrou do Istio no GKE para o Cloud Service Mesh com o plano de controle gerenciado pelo Google e a autoridade de certificação do Cloud Service Mesh sem nenhum tempo de inatividade para seus aplicativos.

Reverter mudanças

Nesta seção, se você não quiser continuar com o Cloud Service Mesh, reverta as mudanças do Cloud Service Mesh. Depois de concluir esta seção, suas cargas de trabalho serão movidas para o Istio no GKE.

1. Reverter as alterações mutáveis do webhook:

   ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
   

2. Rotule os namespaces para usar o Istio na injeção de sidecar do GKE em vez da Cloud Service Mesh executando o seguinte comando:

   para namespaces com cargas de trabalho da versão 1.4:

   export NAMESPACE=NAMESPACE_NAME
   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
   

   para namespaces com cargas de trabalho da versão 1.6:

   export NAMESPACE=NAMESPACE_NAME
   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
   

3. Execute uma reinicialização gradual de todas as implantações no namespace:

   kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
   

4. Aguarde alguns minutos e verifique se todos os pods estão em execução:

   kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
   

   A saída será assim:

   NAME                       READY   STATUS    RESTARTS   AGE
   deploymentName1-PodName    2/2     Running   0          101s
   deploymentName2-PodName    2/2     Running   2          100s
   ...
   
   

5. Verifique a versão do proxy sidecar do Envoy de qualquer um dos pods para confirmar que os proxies do Istio no GKE v1.4 do Envoy foram implantados:

   export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
   kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
   

   O resultado será assim:

   "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
   "appContainerImage"
   

   ou

   "gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
   "appContainerImage"
   

6. Verifique e teste seus aplicativos após a reinicialização.

7. Reverta as alterações da autoridade de certificação do Cloud Service Mesh:

   ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
   

8. Reative o webhook do Istio Galley:

   ${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
   

Você reverteu com sucesso suas alterações do Istio no GKE.

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 no GKE 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. Siga o mesmo processo para todos os namespaces na seção Migrar cargas de trabalho para o Cloud Service Mesh.

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_1_CTX} create namespace online-boutique
   kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled
   
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique
   

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

   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
   kubectl --context=${CLUSTER_1_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_1_CTX} -n online-boutique get pods
   

   A saída 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 se você tem os proxies do Istio no GKE v1.4 Envoy implantados:

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

   A saída será assim:

   "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
   "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_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
   

Perguntas frequentes

Esta seção descreve perguntas frequentes e respostas relacionadas sobre a migração do Istio no GKE para o Cloud Service Mesh.

Por que estou migrando do Istio no GKE para o Cloud Service Mesh?

O Istio no Google Kubernetes Engine é um recurso Beta que implanta o Istio gerenciado pelo Google em um cluster do Google Kubernetes Engine (GKE). O Istio no GKE implanta uma versão incompatível (versão 1.4). Para oferecer os recursos mais recentes da malha de serviço e uma implementação de malha de serviço compatível, estamos atualizando todos os usuários do Istio no GKE para o Cloud Service Mesh.

O Cloud Service Mesh é um produto de malha de serviço gerenciado e compatível com o Google com tecnologia das APIs do Istio. O Cloud Service Mesh é para o Istio o que o GKE é para o Kubernetes. Como o Cloud Service Mesh é baseado nas APIs do Istio, é possível continuar usando as configurações do Istio ao migrar para o Cloud Service Mesh. Além disso, não existe um fornecedor proprietário.

O Cloud Service Mesh oferece os seguintes benefícios de segurança:

• Uma malha de serviço gerenciada pelo Google e compatível com o Google.
• APIs do Istio sem dependência de fornecedores.
• Painéis de telemetria prontos e gerenciamento de SLO prontos sem a necessidade de gerenciar outras soluções de terceiros.
• Opções de autoridade de certificação hospedadas pelo Google.
• Integração com a rede do Google Cloud e o Identity-Aware Proxy (IAP).
• Suporte a plataformas híbridas e com várias nuvens.

Para saber mais sobre os recursos e funcionalidades do Cloud Service Mesh, consulte Recursos compatíveis com o plano de controle gerenciado pelo Google.

Há um tempo de inatividade associado a essa migração?

O script de migração foi projetado para evitar o tempo de inatividade. O script instala o Cloud Service Mesh como um plano de controle canário junto com o plano de controle atual do Istio. O istio-ingressgateway é atualizado no local. Em seguida, rotule novamente os namespaces ativados para o Istio para iniciar usar o Cloud Service Mesh com a autoridade certificadora do Cloud Service Mesh.

Verifique se o PodDisruptionBudgets está configurado corretamente nos seus aplicativos para que você não tenha tempo de inatividade. Mesmo que você consiga evitar a inatividade, se estiver executando essa migração por conta própria, recomendamos fazer essa migração durante uma janela de manutenção programada. As migrações orientadas pelo Google são realizadas durante uma janela de manutenção do GKE. Verifique se os clusters do GKE têm janelas de manutenção configuradas.

Existe algum custo associado ao uso do Cloud Service Mesh?

Há duas maneiras de usar o Cloud Service Mesh no GKE:

• Se você for assinante do GKE Enterprise, o Cloud Service Mesh será incluído como como parte da sua assinatura do GKE Enterprise.

• Se você não for assinante do GKE Enterprise, poderá usar o Cloud Service Mesh como um produto autônomo no GKE (em Google Cloud). Para mais informações, consulte Detalhes do preço do Cloud Service Mesh.

Há recursos ou configurações que não são compatíveis na versão mais recente do Cloud Service Mesh?

O script verifica todas as configurações do Istio e as migra para a versão mais recente do Cloud Service Mesh. Algumas configurações podem exigir Etapas extras a serem migradas do Istio versão 1.4 para o Cloud Service Mesh versão 1.10. O script executa uma verificação de configuração e informa se alguma configuração requer etapas adicionais.

A migração altera minhas configurações atuais do Istio?

Não, as configurações do Istio funcionam no Cloud Service Mesh sem exigir nenhuma alteração.

Depois de migrar para o Cloud Service Mesh, posso migrar de volta para o Istio?

Sim, não há compromisso de usar o Cloud Service Mesh. É possível desinstalar o Cloud Service Mesh e reinstalar o Istio a qualquer momento.

Se a migração falhar, é possível revertê-la?

Sim, o script permite reverter para a versão anterior do Istio no GKE.

Qual versão do Istio posso migrar usando este script?

O script ajuda você a migrar do Istio na versão 1.4 do GKE para a versão 1.10 do Cloud Service Mesh. O script valida a versão do Istio durante o estágio de pré-migração e informa se ela pode ser migrada.

Como posso receber mais ajuda com essa migração?

Nossa equipe de suporte tem prazer em ajudar. É possível abrir um caso de suporte no console do Google Cloud. Para saber mais, consulte Como gerenciar casos de suporte.

O que acontece se eu não migrar para o Cloud Service Mesh?

Os componentes do Istio continuam funcionando, mas o Google não gerencia mais a instalação do Istio. Você não receberá mais atualizações automáticas, e não há garantia de que a instalação funcionará conforme a versão do cluster do Kubernetes for atualizada.

Para mais informações, consulte Suporte do Istio (em inglês).