Migrar do Istio no GKE para o Cloud Service Mesh

Este guia mostra como atualizar 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 a malha de serviços na nuvem gerida com o plano de controlo gerido pela Google e a autoridade de certificação da malha de serviços na nuvem.

Pré-requisitos

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

  • Um cluster do GKE com o Istio no GKE ativado. Se tiver vários clusters do GKE, siga os mesmos passos para todos os clusters.

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

  • Certifique-se de que está a usar a versão 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ ou posterior do GKE.

  • O cluster do GKE tem de estar em execução numa destas localizações.

  • O utilizador ou a conta de serviço que executa este script requer as autorizações da IAM documentadas em Configurar o seu projeto.

  • Este guia é testado na Cloud Shell, por isso, recomendamos que use a Cloud Shell para realizar os passos neste guia.

Objetivos

  • Implemente o painel de controlo gerido pela Google do Cloud Service Mesh no canal normal. Este guia é específico do canal normal. Os canais estáveis ou rápidos requerem instruções ligeiramente modificadas. Para saber mais sobre os canais de lançamento, aceda a este link.
  • Migre as configurações do Istio para o Cloud Service Mesh.
  • Configure a autoridade de certificação da malha de serviço na nuvem.
  • Migre aplicações para o Cloud Service Mesh.
  • Atualize istio-ingressgateway do Istio no GKE para o Cloud Service Mesh.
  • Finalize a migração do Cloud Service Mesh ou reverta para o Istio no GKE.

Configure o seu ambiente

Para configurar o seu ambiente, siga estes passos:

  1. Na Google Cloud consola, ative o Cloud Shell.

    Ative o Cloud Shell

    Na parte inferior da Google Cloud página da consola, é iniciada uma sessão doCloud Shell e é apresentado um comando. O Cloud Shell é um ambiente de shell com a CLI do Google Cloud e a CLI do Google Cloud já instaladas, e com valores já definidos para o seu projeto atual. A sessão pode demorar alguns segundos a ser inicializada.

  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. Crie uma pasta WORKDIR. Todos os ficheiros associados a este guia acabam em WORKDIR para que possa eliminar WORKDIR quando terminar.

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

  4. Crie um ficheiro KUBECONFIG para este guia. Também pode usar o seu ficheiro KUBECONFIG existente 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. Obtenha credenciais para o cluster do GKE e armazene o contexto numa 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 seus clusters têm de estar registados numa frota. Este passo pode ser feito separadamente antes da instalação ou como parte da instalação, transmitindo o --fleet-id e uma das flags --enable-all ou --enable-registration.

  7. O seu projeto tem de ter a funcionalidade de malha de serviços ativada. Pode ativá-lo como parte da instalação transmitindo uma das flags --enable-all ou --enable-registration, ou executando o seguinte comando antes da instalação:

      gcloud container hub mesh enable --project=FLEET_PROJECT_ID

    onde FLEET_PROJECT_ID é o ID do projeto do projeto anfitrião da frota.

Passo opcional

Se o cluster for um cluster privado (com a opção master-authorized-networks ativada), adicione o seu $SHELL_IP à lista de autorizações master-authorized-networks. Se já tiver acesso ao seu cluster, este passo pode não ser necessário.

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

Instale o Cloud Service Mesh

Nesta secção, implementa a malha de serviços na nuvem com o plano de controlo gerido pela Google do canal normal no cluster do GKE. Este plano de controlo é implementado inicialmente em paralelo como um segundo plano de controlo (ou canary).

  1. Transfira a versão mais recente do script que instala o Cloud Service Mesh para o 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 controlo gerido pela 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 regular

    Este passo pode demorar alguns minutos a ser concluído.

  3. Valide o plano de controlo gerido pela Google

  4. Copie istioctl para a pasta WORKDIR:

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

Na secção seguinte, transfere e executa o script migrate_addon para ajudar na migração para a Cloud Service Mesh. O utilitário de linha de comandos istioctl tem de estar na mesma pasta que o script migrate_addon. Use a pasta WORKDIR para o utilitário de linha de comandos istioctl e o script migrate_addon.

Migre configurações para o Cloud Service Mesh

Nesta secção, migra as configurações do Istio no GKE para o Cloud Service Mesh. O script guiado identifica as configurações que podem e não podem ser migradas.

  1. Transfira a 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. Este passo é necessário para migrar algumas das configurações da versão 1.4 para o Cloud Service Mesh. Responda Y a ambas as perguntas:

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

    O resultado é semelhante ao seguinte:

    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. Valide e migre manualmente a configuração. Este passo ajuda a identificar algumas das configurações que têm de ser migradas manualmente antes de migrar cargas de trabalho para o plano de controlo gerido pela Google.

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

    O resultado é semelhante ao seguinte:

    Installing the authentication CR migration tool...
OK

Checking for configurations that will need to be explicitly migrated...
No resources found

Migre configurações personalizadas

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

  • Os filtros do Envoy personalizados detetados não são suportados pela Cloud Service Mesh. Remova-os, se possível. Atualmente, os filtros do Envoy não são suportados no plano de controlo gerido pela Google.

  • Certificado de plug-in personalizado detetado. Os certificados de plug-ins não vão ser migrados para o Cloud Service Mesh. Se forem usados certificados de plug-ins com o Istio no GKE, estes certificados não são usados após a migração das cargas de trabalho para o plano de controlo gerido pela Google. Todas as cargas de trabalho usam certificados assinados pela autoridade de certificação do Google Cloud Service Mesh. Os certificados de plug-ins não são suportados pela autoridade de certificação do Cloud Service Mesh. Esta mensagem é informativa e não é necessária nenhuma ação.

  • Foram detetadas políticas de segurança que não puderam ser migradas. <Error reason>. Normalmente, esta ação falha devido a políticas de autorização alfa que têm de ser migradas manualmente. Para mais contexto e informações sobre como migrar políticas, consulte o artigo Migre a política de segurança alfa pré-Istio 1.4 para as APIs atuais. Para mais informações acerca da mensagem de erro, consulte o artigo security-policy-migrate.

  • Foi detetada uma configuração de VirtualService possivelmente incompatível. <Specific deprecated config>. Tem de atualizar as seguintes VirtualService configurações:

    • A utilização de appendHeaders não é suportada. Em alternativa, use spec.http.headers.
    • Não é necessário usar websocketUpgrade. Está ativada por predefinição.
    • Substitua o campo abort.percent por abort.percentage.

  • Foi detetada uma instalação personalizada de recursos do misturador que não foi possível migrar. Requer migração manual para telemetryv2. Se forem configuradas políticas do misturador personalizadas, além da instalação predefinida do Istio no GKE, tem de migrar manualmente estas políticas para a telemetria v2. Para mais informações sobre como o fazer, consulte o artigo Personalizar métricas do Istio.

  • A implementação <deploymentName> pode ser um gateway personalizado. Migre isto manualmente. Tem de migrar manualmente todas as implementações de gateway, exceto a istio-ingressgateway (que é instalada por predefinição). Para obter informações sobre como atualizar gateways para o plano de controlo gerido pela Google, consulte o artigo Configurar o plano de controlo gerido pela Google.

Para migrar configurações, siga estes passos:

  1. Migre manualmente todas as configurações personalizadas (exceto a última configuração indicada) antes de avançar para o passo 2.

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

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

    O resultado é semelhante ao seguinte:

    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. Aplique a confiança na raiz da autoridade de certificação do Cloud Service Mesh. Isto permite-lhe migrar da AC do Citadel atual para a autoridade de certificação do Cloud Service Mesh sem incorrer em tempo de inatividade nas suas aplicações.

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

    O resultado é semelhante ao seguinte:

    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

    Este passo demora alguns minutos para que o certificado de raiz do Cloud Service Mesh seja distribuído a todos os espaços de nomes. Aguarde até que o script termine com uma mensagem OK.

O passo anterior faz o seguinte:

  • Instala a raiz de confiança da autoridade de certificação do Cloud Service Mesh para todas as cargas de trabalho no cluster.

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

    • Atualizar as imagens para as compilações mais recentes.
    • Desativar a validação trust-domaindefinindoPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
    • Adicionar a raiz de confiança da autoridade de certificação do Cloud Service Mesh a istio-citadel para distribuir o ConfigMap a todos os espaços de nomes.
    • Adicionar a raiz fidedigna da autoridade de certificação do Cloud Service Mesh a istio-ca-secret para distribuir o certificado de raiz.

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

  • Fornece passos para a função de reversão (documentada mais tarde).

Migre cargas de trabalho para o Cloud Service Mesh

Nesta secção, migra cargas de trabalho executadas no Istio no GKE para a Cloud Service Mesh. Após a migração, verifique se os proxies sidecar corretos (Cloud Service Mesh) são injetados em todos os pods e se a aplicação está a funcionar conforme esperado.

Se estiver a realizar este procedimento num cluster existente, selecione um espaço de nomes a migrar.

  1. Defina o espaço de nomes como uma variável. Este espaço de nomes é migrado para o Cloud Service Mesh:

    export NAMESPACE=NAMESPACE_NAME

  2. Para migrar cargas de trabalho para o Cloud Service Mesh, tem de voltar a etiquetar o espaço de nomes para o Cloud Service Mesh. A etiquetagem do espaço de nomes permite que o Cloud Service Mesh injete automaticamente sidecars em todas as cargas de trabalho. Para etiquetar o espaço de nomes, execute o seguinte comando, definindo a etiqueta como asm-managed:

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

  3. Faça um reinício contínuo de todas as implementações no espaço de nomes:

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

    O resultado é semelhante ao seguinte:

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

  4. Certifique-se de que todos os pods são reiniciados e estão a ser executados com dois contentores por pod:

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

    O resultado é semelhante ao seguinte:

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

    Uma boa forma de validar este passo é analisar o AGE dos pods. Certifique-se de que o valor é curto, por exemplo, alguns minutos.

  5. Verifique a versão do proxy Envoy do sidecar de qualquer um dos pods de qualquer implementação no espaço de nomes para confirmar que tem agora proxies Envoy da Cloud Service Mesh implementados:

    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 é semelhante ao seguinte:

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

  6. Valide e teste as suas aplicações após o reinício.

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

  7. (Opcional) Se quiser que a Google faça a gestão das atualizações dos proxies, ative o plano de dados gerido pela Google

Veja o estado da migração

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

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

O resultado indica se a migração está concluída, pendente ou falhou:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Se migrationStatus gerar SUCCESS, o plano de controlo foi atualizado com êxito para o Cloud Service Mesh. Para atualizar manualmente o plano de dados, conclua os passos em Migrar cargas de trabalho.

Se migrationStatus gerar um estado diferente de SUCCESS, pode optar por:

  • Não tome nenhuma medida adicional se o erro de migração não afetar as suas cargas de trabalho do Istio no GKE existentes. Caso contrário, reverta se necessário.
  • Atualize as configurações personalizadas no cluster e volte a executar a migração manualmente se migrationStatus mostrar MIGRATION_CONFIG_ERROR.

Pode ver as métricas do plano de controlo no Explorador de métricas após a migração bem-sucedida. Consulte verify_control_plane_metrics

Aceda aos painéis de controlo do Cloud Service Mesh

Nesta secção, acede aos painéis de controlo do Cloud Service Mesh e certifica-se de que está a receber os sinais de ouro para todos os serviços. Também deve conseguir ver a topologia da sua aplicação.

  1. Na Google Cloud consola, aceda à página Cloud Service Mesh.

    Aceda ao Cloud Service Mesh

  2. Deve conseguir ver as métricas e a topologia dos seus serviços.

Para saber mais acerca dos painéis de controlo do Cloud Service Mesh, consulte o artigo Explorar o Cloud Service Mesh na Google Cloud consola.

Conclua uma migração bem-sucedida

Nesta secção, finaliza a migração do Istio no GKE para o Cloud Service Mesh. Antes de continuar com esta secção, certifique-se de que quer continuar com o Cloud Service Mesh. Esta secção também ajuda a limpar os artefactos do Istio no GKE. Se quiser reverter para o Istio no GKE, avance para a secção seguinte.

  1. Substitua o istio-ingressgateway (parte do Istio padrão no GKE) pelo gateway com versões do plano de controlo gerido pela Google:

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

    O resultado é semelhante ao seguinte:

    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. Reconfigure o webhook para usar o plano de controlo gerido pela Google. Todas as cargas de trabalho começam a usar o plano de controlo gerido pela Google:

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

    O resultado é semelhante ao seguinte:

    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. Volte a etiquetar todos os espaços de nomes com a etiqueta do Cloud Service Mesh e faça um reinício contínuo de todas as cargas de trabalho para as colocar no plano de controlo gerido pela 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}

    Pode ignorar a mensagem "istio-injection not found" no resultado. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection, o que deve esperar em novas instalações do Cloud Service Mesh ou novas implementações. Uma vez que a injeção automática falha se um espaço de nomes tiver a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Istio no GKE incluem a remoção da etiqueta istio-injection.

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

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

    O resultado é semelhante ao seguinte:

    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

    O resultado é semelhante ao seguinte:

    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. Certifique-se de que as implementações e os serviços do Istio no GKE foram removidos com êxito do cluster:

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

    O resultado é semelhante ao seguinte:

    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

    Só vê o serviço e a implementação do gateway de entrada do Cloud Service Mesh.

Parabéns. Migrou com êxito do Istio no GKE para o Cloud Service Mesh com o plano de controlo gerido pela Google e a autoridade de certificação do Cloud Service Mesh sem qualquer tempo de inatividade para as suas aplicações.

Reverta alterações

Nesta secção, se não quiser continuar com o Cloud Service Mesh, pode reverter as alterações do Cloud Service Mesh. Depois de concluir esta secção, as suas cargas de trabalho voltam para o Istio no GKE.

  1. Reverta as alterações do webhook de mutação: 

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

  2. Reetiquete os espaços de nomes para usar o Istio na injeção de sidecar do GKE, em vez do Cloud Service Mesh, executando o seguinte comando:

    Para espaços de nomes 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 espaços de nomes 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. Faça um reinício contínuo de todas as implementações no espaço de nomes:

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

  4. Aguarde alguns minutos e certifique-se de que todos os pods estão em execução:

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

    O resultado é semelhante ao seguinte:

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

  5. Valide a versão do proxy Envoy do sidecar de qualquer um dos pods para confirmar que tem proxies Envoy do Istio na versão 1.4 do GKE implementados:

    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 é semelhante ao seguinte:

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

    ou

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

  6. Valide e teste as suas aplicações após o reinício.

  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

Reverteu com êxito as alterações ao Istio no GKE.

Implemente a loja online

Nesta secção, implementa uma aplicação de exemplo baseada em microsserviços denominada Online Boutique no cluster do GKE. A Online Boutique está implementada num espaço de nomes com o Istio ativado. Verifica se a aplicação está a funcionar e se o Istio no GKE está a injetar os proxies sidecar em todos os pods.

Se já tiver clusters existentes com aplicações, pode ignorar a criação de um novo espaço de nomes e a implementação da Online Boutique. Pode seguir o mesmo processo para todos os espaços de nomes na secção Migre cargas de trabalho para a malha de serviços na nuvem.

  1. Implemente a 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 implementaçõ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. Certifique-se de que existem dois contentores por Pod: o contentor da aplicação e o proxy sidecar do Istio que o Istio no GKE injeta automaticamente no Pod:

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

    O resultado é semelhante ao seguinte:

    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 pode verificar a versão do proxy Envoy do sidecar a partir de qualquer um dos pods para confirmar que tem proxies Envoy do Istio no GKE v1.4 implementados:

    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'

    O resultado é semelhante ao seguinte:

    "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

  5. Aceda à aplicação navegando para o endereço IP do istio-ingressgateway endereço IP do serviço:

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

Perguntas frequentes

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

Por que motivo estou a ser migrado do Istio no GKE para o Cloud Service Mesh?

O Istio no Google Kubernetes Engine é uma funcionalidade beta que implementa o Istio gerido pela Google num cluster do Google Kubernetes Engine (GKE). O Istio no GKE implementa uma versão não suportada (versão 1.4 do Istio). Para lhe oferecer as funcionalidades mais recentes da malha de serviços e uma implementação suportada da malha de serviços, estamos a atualizar todos os utilizadores do Istio no GKE para a malha de serviços na nuvem.

O Cloud Service Mesh é o produto de service mesh gerido e suportado da Google com tecnologia das APIs Istio. O Cloud Service Mesh é para o Istio o que o GKE é para o Kubernetes. Uma vez que a Cloud Service Mesh se baseia nas APIs Istio, pode continuar a usar as suas configurações do Istio quando migrar para a Cloud Service Mesh. Além disso, não existe dependência de fornecedor proprietário.

O Cloud Service Mesh oferece as seguintes vantagens:

  • Uma malha de serviço gerida e suportada pela Google.
  • APIs Istio sem dependência de fornecedores.
  • Painéis de controlo de telemetria prontos a usar e gestão de SLOs sem requisitos para gerir soluções de terceiros adicionais.
  • Opções de autoridade de certificação alojadas pela Google.
  • Integração com Google Cloud redes e Identity-Aware Proxy (IAP).
  • Suporte de plataformas híbridas e de várias nuvens.

Para saber mais sobre as funcionalidades e as capacidades do Cloud Service Mesh, consulte o artigo Funcionalidades suportadas do plano de controlo gerido pela Google.

Existe algum tempo de inatividade associado a esta migração?

O script de migração foi concebido para evitar o tempo de inatividade. O script instala o Cloud Service Mesh como um plano de controlo canário juntamente com o seu plano de controlo do Istio existente. O istio-ingressgateway é atualizado no local. Em seguida, reetiqueta os espaços de nomes ativados para o Istio para começar a usar o Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh.

Certifique-se de que tem os PodDisruptionBudgets corretamente configurados para as suas aplicações, para não ter qualquer tempo de inatividade da aplicação. Embora possa evitar o tempo de inatividade, se estiver a fazer esta migração sozinho, recomendamos que a faça durante um período de manutenção agendado. As migrações conduzidas pela Google são realizadas durante um período de manutenção do GKE. Certifique-se de que os seus clusters do GKE têm janelas de manutenção configuradas.

Existe algum custo associado à utilização da Cloud Service Mesh?

Existem duas formas de usar o Cloud Service Mesh no GKE:

Existem funcionalidades ou configurações que não são suportadas na versão mais recente do Cloud Service Mesh?

O script verifica todas as configurações do Istio e migra-as para a versão mais recente do Cloud Service Mesh. Existem determinadas configurações que podem exigir passos adicionais para serem migradas da versão 1.4 do Istio para a versão 1.10 do Cloud Service Mesh. O script executa uma verificação da configuração e informa se alguma configuração requer passos adicionais.

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

Não, as suas configurações do Istio funcionam no Cloud Service Mesh sem necessidade de alterações.

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

Sim, não existe qualquer compromisso de usar o Cloud Service Mesh. Pode desinstalar o Cloud Service Mesh e reinstalar o Istio em qualquer altura.

Se a migração falhar, é possível reverter?

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

Que versão do Istio posso migrar através deste script?

O script ajuda a migrar do Istio no GKE versão 1.4 para o Cloud Service Mesh versão 1.10. O script valida a sua versão do Istio durante a fase de pré-migração e informa se a sua versão do Istio pode ser migrada.

Como posso receber ajuda adicional com esta migração?

A nossa equipa de apoio técnico tem todo o gosto em ajudar. Pode abrir um registo de apoio ao cliente a partir da Google Cloud consola. Para saber mais, consulte o artigo Gerir registos de apoio técnico.

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

Os seus componentes do Istio continuam a funcionar, mas a Google já não gere a sua instalação do Istio. Deixa de receber atualizações automáticas e não é garantido que a instalação funcione à medida que a versão do cluster Kubernetes é atualizada.

Para mais informações, consulte o artigo Suporte do Istio.