Como migrar do Istio no GKE para o Anthos Service Mesh

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

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 Anthos 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.
  • Migre as configurações do Istio para o Anthos Service Mesh.
  • Configurar CA da malha.
  • Migre aplicativos para o Anthos Service Mesh.
  • Faça upgrade do istio-ingressgateway no Istio no GKE para o Anthos Service Mesh.
  • Finalize a migração do Anthos Service Mesh ou reverta para o Istio no GKE.

configure o ambiente

Para configurar o ambiente, siga estas etapas:

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

    Ativar o Cloud Shell

    Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com o Google Cloud CLI e o Google Cloud CLI já instalados e com 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 para o cluster do GKE a ser migrado para o Anthos 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

Instale o Anthos Service Mesh

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

  1. Faça o download da versão mais recente do script que instala o Anthos 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 Anthos 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, você fará o download e executará o script migrate_addon para ajudar na migração para o Anthos 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 Anthos Service Mesh

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

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

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

  2. Desative o webhook de validação do Galley. Essa etapa é necessária para migrar algumas das configurações 1.4 para o Anthos 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 Anthos 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 Anthos 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 Anthos 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. Todas as cargas de trabalho usam certificados assinados pela CA do Google Mesh. Os certificados de plug-in não são compatíveis com a CA da malha. Esta mensagem é informativa e nenhuma ação é necessária.

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

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

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

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

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

Para migrar configurações, siga estas etapas:

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

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

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

    O resultado será assim:

    Converting authentication CRs...
2021/06/25 20:44:58 found root namespace: istio-system
2021/06/25 20:44:59 SUCCESS converting policy /default
Running: kubectl apply --dry-run=client -f beta-policy.yaml
peerauthentication.security.istio.io/default created (dry run)

Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y
Running: kubectl apply -f beta-policy.yaml
peerauthentication.security.istio.io/default created
OK

  3. Aplicar a confiança raiz da CA da malha. Isso permite que você migre da Citadel CA atual para a CA da malha sem incorrer em inatividade nos seus 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

    Essa etapa leva alguns minutos para que o certificado raiz do Anthos 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 CA do 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 CA da malha a istio-citadel para distribuir o ConfigMap a todos os namespaces.
    • Como adicionar a raiz de confiança da CA da malha 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).

Migre cargas de trabalho para o Anthos Service Mesh

Nesta seção, você migra cargas de trabalho em execução no Istio no GKE para o Anthos Service Mesh. Após a migração, verifique se os proxies sidecar corretos (Anthos 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. Definir o namespace como uma variável; esse namespace é migrado para o Anthos Service Mesh:

    export NAMESPACE=NAMESPACE_NAME

  2. Para migrar cargas de trabalho para o Anthos Service Mesh, é preciso rotular novamente o namespace para o Anthos Service Mesh. A rotulagem do namespace permite que o Anthos Service Mesh injete automaticamente sidecars 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 sidecar do Envoy de qualquer um dos pods de qualquer implantação no namespace para confirmar que agora você tem proxies do Anthos Service Mesh Envoy implantados:

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

    O resultado será assim:

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

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

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

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

Ver o status da migração

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

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

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

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Se migrationStatus gerar SUCCESS, o plano de controle foi atualizado para o Anthos 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 Anthos Service Mesh

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

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

    Acesse o Anthos Service Mesh

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

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

Concluir uma migração

Nesta seção, você finaliza o Istio no GKE na migração do Anthos Service Mesh. Antes de prosseguir com esta seção, verifique se você quer continuar com o Anthos 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 todos os namespaces com o rótulo do Anthos Service Mesh e execute uma reinicialização contínua de todas as cargas de trabalho para colocá-las no plano de controle gerenciado pelo Google:

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

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

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

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

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

    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ê verá apenas o serviço e a implantação do gateway de entrada do Anthos Service Mesh.

Parabéns! Você migrou do Istio no GKE para o Anthos Service Mesh com o plano de controle gerenciado pelo Google e a CA do Mesh sem qualquer tempo de inatividade para seus aplicativos.

Reverter mudanças

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

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

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

  2. Rotule os namespaces para usar o Istio na injeção de arquivo secundário do GKE em vez do Anthos 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 CA da malha:

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

  8. Reative o webhook do Istio Galley:

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

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

Implantar Boutique on-line

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

Se você já tiver clusters com aplicativos, poderá ignorar a criação de um novo namespace e a implantação do Online Boutique. Siga o mesmo processo para todos os namespaces na seção Migrar cargas de trabalho para o Anthos 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 perguntas frequentes e respostas relacionadas sobre a migração do Istio no GKE para o Anthos Service Mesh.

Por que estou migrando do Istio no GKE para o Anthos 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 Anthos Service Mesh.

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

O Anthos 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 funcionalidades do Anthos 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 Mesh 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 Anthos Service Mesh com a autoridade de certificação do Anthos Service Mesh (CA Mesh).

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

Há algum custo associado ao uso do Anthos Service Mesh?

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

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

O script verifica todas as configurações do Istio e as migra para a versão mais recente do Anthos Service Mesh. Há determinadas configurações que podem exigir outras etapas da migração da versão 1.4 do Istio para o Anthos Service Mesh versão 1.10. O script executa uma verificação de configuração e informa se alguma configuração requer etapas adicionais.

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

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

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

Sim, não há obrigatoriedade de uso o Anthos Service Mesh. É possível desinstalar o Anthos 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 o Anthos Service Mesh versão 1.10. O script valida a versão do Istio durante o estágio de pré-migração e informa se ela pode ser migrada.

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

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

O que acontece se eu não migrar para o Anthos 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).