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 o Istio no Google Kubernetes Engine (Istio no GKE) versão 1.4 ou 1.6 (Beta) para o Cloud Service Mesh gerenciado com o plano de controle gerenciado pelo Google 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.
- Migre aplicativos para o Cloud Service Mesh.
- Faça upgrade do
istio-ingressgatewayno 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:
No Console do Google Cloud, ative 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.
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.Criar uma pasta
WORKDIR. Todos os arquivos associados a este guia terminam emWORKDIRpara que você possa excluirWORKDIRquando terminar.mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`Crie um arquivo
KUBECONFIGpara este guia. Também é possível usar o arquivoKUBECONFIGatual 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-kubeconfigReceba 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}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.
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_IDFLEET_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ê vai implantar 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).
Faça o download da versão mais recente do script que instala o Cloud Service Mesh ao diretório de trabalho atual e torne o script executável:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcliPara 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 normal:
./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 regularEsse processo leva alguns minutos para ser concluído.
Copie
istioctlpara a pastaWORKDIR:cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
Na próxima seção, você vai fazer o download e executar o script migrate_addon para auxiliar
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ê vai migrar as configurações do Istio no GKE para do Cloud Service Mesh. O script guiado identifica quais configurações podem ou não ser migradas.
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_addonDesative o webhook de validação do Galley. Esta etapa é necessária para migrar alguns das configurações da versão 1.4 para o Cloud Service Mesh. Responda
Yàs duas perguntas:${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhookA 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" deletedVerifique 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-checkA 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:
Os filtros de envio personalizados detectados não são compatíveis com o Cloud Service Mesh. 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 migrou 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 não são compatíveis com a autoridade certificadora 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. Usespec.http.headers, em vez disso. - Não é necessário usar
websocketUpgrade. Ela está ativada por padrão. - Substitua o campo
abort.percentporabort.percentage.
- Não há suporte para o uso de
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:
Migre manualmente todas as configurações personalizadas (exceto a última listada ) antes de prosseguir para a etapa 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-configsO 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
Aplique a confiança raiz da autoridade certificadora do Cloud Service Mesh. Isso permite que você migre da Citadel CA atual para a autoridade de certificação do Cloud Service Mesh sem incorrer em inatividade nos seus aplicativos.
${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-caO 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 OKEsta 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,istiodeistio-citadel. As mudanças incluem o seguinte:- Como fazer upgrade das imagens para os builds mais recentes.
- Desativando a verificação de
trust-domainconfigurandoPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true. - Adição da raiz de confiança da autoridade de certificação do Cloud Service Mesh a
istio-citadelpara distribuir oConfigMapa todos os namespaces. - Adicionar a raiz de confiança da autoridade certificadora do Cloud Service Mesh a
istio-ca-secretpara 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ê vai migrar cargas de trabalho em execução no Istio no GKE para o Cloud Service Mesh. Após a migração, verifique se os proxies sidecar corretos (Cloud Service Mesh) são injetados em cada pod e se o aplicativo está funcionando conforme o esperado.
Se você estiver executando este procedimento em um cluster atual, selecione um namespace a ser migrado.
Defina o namespace como uma variável. esse namespace é migrado Cloud Service Mesh:
export NAMESPACE=NAMESPACE_NAME
Para migrar cargas de trabalho para o Cloud Service Mesh, é preciso rotular novamente o namespace para o Cloud Service Mesh. A rotulagem do namespace permite que o Cloud Service Mesh injete sidecars automaticamente 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- --overwriteExecute 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 ...
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 podsA 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
AGEdos pods. Certifique-se de que o valor seja curto, por exemplo, alguns minutos.Verifique a versão do proxy do Envoy do arquivo secundário de qualquer um dos pods Implantação no namespace para confirmar que agora você tem proxies 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"
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}'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
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
migrationStatusmostrarMIGRATION_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.
No console do Google Cloud, acesse a página Cloud Service Mesh.
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.
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 que você quer prosseguir 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.
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-gatewayA 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 OKreconfigurar 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-webhookO 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' OKRotular novamente todos os namespaces com o rótulo do Cloud Service Mesh e executar reinicialização gradual 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ótuloistio-injectionanteriormente, 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-injectione o rótulo de revisão,kubectl labelna documentação do Istio no GKE incluem a remoção doistio-injectionrótulo.Finalize a migração executando o seguinte comando:
${WORKDIR}/migrate_addon -d tmpdir --command write-markerA saída será assim:
Current migration state: SUCCESS Running: kubectl apply -f - configmap/asm-addon-migration-state created OK
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=DISABLEDClusters regionais
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --region=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLEDLimpe as configurações executando o seguinte comando:
${WORKDIR}/migrate_addon -d tmpdir --command cleanupA 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" deletedVerifique 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,servicesO 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.
Reverter as alterações mutáveis do webhook:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhookRotular novamente os namespaces para usar o Istio na injeção de arquivo secundário do GKE em vez do 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 --overwritepara 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 --overwriteExecute uma reinicialização gradual de todas as implantações no namespace:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}Aguarde alguns minutos e verifique se todos os pods estão em execução:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get podsA saída será assim:
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
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"
Verifique e teste seus aplicativos após a reinicialização.
Reverta as mudanças da autoridade certificadora do Cloud Service Mesh:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-caReative 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. Você pode seguir o mesmo processo para todos os namespaces na Seção Migrar cargas de trabalho para o Cloud Service Mesh.
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-boutiqueAguarde 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 recommendationserviceVerifique 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 podsA 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
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"
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 as perguntas frequentes e respostas relacionadas a como migrar 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 é o produto de malha de serviço gerenciado e compatível com o Google com a 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 continue usando as configurações do Istio ao migrar do 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 as capacidades 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, remarque os namespaces ativados para o Istio para começar
a usar o Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh.
Verifique se você tem PodDisruptionBudgets corretamente configurados para seus aplicativos, de modo que você não tenha qualquer inatividade do aplicativo. 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 independente no GKE (no Google Cloud). Para mais informações, consulte Detalhes de preços do Cloud Service Mesh.
Há recursos ou configurações incompatíveis com a 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 Versão do Cloud Service Mesh. Há determinadas configurações que podem exigir outras etapas da migração da versão 1.4 do Istio 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, suas configurações do Istio funcionam no Cloud Service Mesh sem a necessidade mudanças.
Após migrar para o Cloud Service Mesh, posso migrar de volta para o Istio?
Sim, não há compromisso de usar o Cloud Service Mesh. Você pode 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. Você pode abrir um caso de suporte no console do Google Cloud. Para saber mais, consulte Como gerenciar casos de suporte.
O que acontecerá 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).