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

  • Implantar o plano de controle do Cloud Service Mesh gerenciado pelo Google 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.
  • Configurar a autoridade de certificação do Cloud Service Mesh
  • Migrar aplicativos para o Cloud Service Mesh.
  • Faça upgrade do 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.

Configure seu ambiente

Para configurar o ambiente, siga estas etapas:

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

    Ativar o Cloud Shell

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

  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. Também é possível usar o arquivo KUBECONFIG atual que contém o contexto do 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 de 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 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

    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, faça o download e execute 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ê migrará 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. Esta etapa é necessária para migrar algumas 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-webhook

    O resultado 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

    O resultado 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 manualmente as configurações personalizadas antes de migrar para o 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 envoy 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 migrados para o Cloud Service Mesh. Se os certificados de plug-in forem usados com o Istio no GKE, eles não serão usados após a migração das cargas de trabalho para o plano de controle gerenciado pelo Google. Todas as cargas de trabalho usam certificados assinados pela autoridade de certificação do Google Cloud Service Mesh. Os certificados de plug-in não são compatíveis com a 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. Aplique a confiança raiz da autoridade de certificação do Cloud Service Mesh. Isso permite que você migre da AC atual do Citadel para a autoridade de certificação do Cloud Service Mesh sem causar inatividade nos 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 que o certificado raiz do Cloud Service Mesh seja distribuído 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 de certificação do Cloud Service Mesh para todas as cargas de trabalho no 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.
    • Adicione a raiz de confiança da autoridade de certificação do Cloud Service Mesh a istio-ca-secret para distribuir o certificado raiz.

  • 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 de arquivo secundário 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.

  1. Defina 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 injete 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}

    O resultado 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

    O resultado 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 do Envoy do arquivo secundário de qualquer um dos pods de qualquer implantação no namespace para confirmar que você agora 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"

  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, significa que 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, rollback, 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 os painéis do Cloud Service Mesh

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

  1. No console do Google Cloud, acesse a página do 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 conhecer 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 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.

  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

    O resultado 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 novamente todos os namespaces com o rótulo do Cloud Service Mesh e execute uma reinicialização gradual de todas as cargas de trabalho para que elas sejam recebidas 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 anteriormente o rótulo istio-injection, que é esperado em novas instalações do Cloud Service Mesh ou 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

    O resultado 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ó verá 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 inatividade nos aplicativos.

Reverter mudanças

Nesta seção, se você não quiser continuar com o Cloud Service Mesh, poderá reverter as alterações do Cloud Service Mesh. Depois de concluir esta seção, suas cargas de trabalho serão movidas para o Istio no GKE.

  1. Reverta as alterações do webhook mutável:

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

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

    O resultado 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. É possível seguir 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

    O resultado será assim:

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

  4. Também é possível verificar a versão do proxy sidecar do Envoy de qualquer um dos pods para confirmar 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'

    O resultado 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

Nesta seção, descrevemos as perguntas frequentes e respostas relacionadas sobre a migração do Istio no GKE para o Cloud Service Mesh.

Por que estou sendo migrado 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 a você os recursos mais recentes e uma implementação de malha de serviço compatível, estamos fazendo upgrade de 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 suportado do Google com a tecnologia das APIs do Istio. 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 suas 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:

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

Saiba mais sobre os recursos do Cloud Service Mesh em 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 com o plano de controle atual do Istio. O istio-ingressgateway é atualizado no local. Em seguida, rotule os namespaces ativados pelo Istio para começar a usar o Cloud Service Mesh com a autoridade de certificação do Cloud Service Mesh.

Verifique se você configurou o PodDisruptionBudgets (em inglês) corretamente para os aplicativos. Assim, não haverá 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.

O uso do Cloud Service Mesh tem algum custo?

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

Há recursos ou configurações que não são compatí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 do Cloud Service Mesh. Há determinadas configurações que podem exigir mais etapas para migrar da versão 1.4 do Istio para a versão 1.10 do Cloud Service Mesh. 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.

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. É 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. Abra um caso de suporte no console do Google Cloud. Para saber mais, consulte Como gerenciar casos de suporte.

O que vai 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).