Migra de Istio on GKE a Anthos Service Mesh

En esta guía, se muestra cómo actualizar un clúster de Google Kubernetes Engine (GKE) con la versión 1.4 o 1.6 (Beta) de Google Kubernetes Engine (Istio on GKE) a Anthos. Versión 1.10 de Service Mesh con el plano de control administrado por Google del servicio de Anthos Mesh y la autoridad certificada de Anthos Service Mesh (CA de Mesh).

Requisitos previos

Para completar esta guía, se requieren los siguientes requisitos:

  • Un clúster de GKE con Istio en GKE habilitado Si tienes varios clústeres de GKE, sigue los mismos pasos para todos los clústeres. Si no tienes un clúster de GKE, o si primero deseas probar esta guía en un clúster nuevo (de prueba), puedes seguir los pasos del Apéndice A. para crear un clúster de GKE nuevo con Istio habilitado en GKE e implementar una aplicación de prueba.

  • Istio en GKE debe ser la versión 1.4 o 1.6.

  • Asegúrate de ejecutar la versión 1.17.17-gke.3100+, GKE 1.18.16-gke.1600+, 1.19.8-gke.1600+ o una posterior de GKE.

  • El clúster de GKE debe ejecutarse en una de estas ubicaciones.

  • El usuario o la cuenta de servicio que ejecuta esta secuencia de comandos requiere los permisos de IAM documentados en Configura tu proyecto.

  • Esta guía se prueba en Cloud Shell, por lo que te recomendamos que uses Cloud Shell para realizar los pasos de esta guía.

Objetivos

  • Implementa la versión 1.10 del plano de control administrado por Google de Anthos Service Mesh.
  • Migra la configuración de Istio a Anthos Service Mesh
  • Configura la CA de Mesh.
  • Migra aplicaciones a Anthos Service Mesh.
  • Actualiza istio-ingressgateway de Istio on GKE a Anthos Service Mesh.
  • Finaliza la migración de Anthos Service Mesh o revierte a Istio on GKE.

Configure su entorno

Para configurar tu entorno, sigue estos pasos:

  1. En Google Cloud Console, activa Cloud Shell.

    Activa Cloud Shell.

    En la parte inferior de Cloud Console, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con el SDK de Cloud y la herramienta de línea de comandos de gcloud ya instalados, y con valores ya establecidos para tu proyecto actual. La sesión puede tardar unos segundos en inicializarse.

  2. Crea las variables de entorno que se usan en esta guía:

    # 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. Crea una carpeta de WORKDIR. Todos los archivos asociados con esta guía terminan en WORKDIR para que puedas borrar WORKDIR cuando termines.

    mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
    
  4. Crea un archivo KUBECONFIG para esta guía. También puedes usar el archivo KUBECONFIG existente que contiene el contexto del clúster para el clúster de GKE que se migrará a Anthos Service Mesh.

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
    
  5. Obtén credenciales para el clúster de GKE y almacena el contexto en una variable:

    Clústeres zonales

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

    Clústeres regionales

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

Paso opcional

Si el clúster es un clúster privado (con master-authorized-networks habilitado), agrega el $SHELL_IP a la lista de anunciantes permitidos master-authorized-networks. Si ya tienes acceso a tu clúster, es posible que este paso no sea necesario.

Clústeres zonales

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

Clústeres regionales

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 Anthos Service Mesh

En esta sección, implementarás la versión 1.10 de Anthos Service Mesh con el plano de control administrado por Google en el clúster de GKE. Este plano de control se implementa junto con Istio on GKE como un segundo plano de control (o versión canary).

  1. Descarga la última versión de la secuencia de comandos que instala Anthos Service Mesh v1.10 en el directorio de trabajo actual y haz que la secuencia de comandos sea ejecutable:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asm_1_10
    chmod +x install_asm_1_10
    
  2. Para configurar el clúster de GKE, ejecuta la secuencia de comandos de instalación a fin de instalar Anthos Service Mesh con el plano de control administrado por Google:

    ./install_asm_1_10 --mode install --managed \
    -p ${PROJECT_ID} \
    -l ${CLUSTER_1_LOCATION} \
    -n ${CLUSTER_1} \
    --verbose \
    --output_dir ${CLUSTER_1} \
    --enable-all \
    --enable-registration \
    --option cni-managed
    

    Esta operación puede tardar unos minutos en completarse.

  3. Copia la versión 1.10 de istioctl en la carpeta WORKDIR:

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

En la siguiente sección, descargarás y ejecutarás la secuencia de comandos migrate_addon para ayudar en la migración a Anthos Service Mesh. La utilidad de la línea de comandos de istioctl debe estar en la misma carpeta que la secuencia de comandos migrate_addon. Usa la carpeta WORKDIR para la utilidad de línea de comandos de istioctl y la secuencia de comandos migrate_addon.

Migra la configuración a Anthos Service Mesh

En esta sección, migrarás las opciones de configuración de Istio on GKE a Anthos Service Mesh. La secuencia de comandos guiada identifica qué opciones de configuración se pueden migrar y cuáles no.

  1. Descarga la herramienta de migración y haz que sea ejecutable:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
    chmod +x ${WORKDIR}/migrate_addon
    
  2. Inhabilita el webhook de validación de Galería. Este paso es necesario para migrar algunas de las configuraciones de 1.4 a Anthos Service Mesh. Responde Y a ambas preguntas:

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

    El resultado es similar a este:

    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. Verifica y migra la configuración de forma manual. Este paso ayuda a identificar algunas de las opciones de configuración que deben migrarse de forma manual antes de migrar las cargas de trabajo al plano de control administrado por Google.

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

    El resultado es similar a este:

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

Cómo migrar configuraciones personalizadas

Es posible que debas migrar las configuraciones personalizadas de forma manual antes de migrar a Anthos Service Mesh. La secuencia de comandos anterior identifica las configuraciones personalizadas y, luego, imprime información sobre lo que se requiere. Estas personalizaciones son las siguientes:

  • Anthos Service Mesh no admite los filtros personalizados de Envoy que se detectaron. Si es posible, quítalas. Por el momento, los filtros de Envoy no son compatibles con el plano de control administrado por Google.

  • Se detectó un certificado de complemento personalizado detectado. Los certificados de complementos no se migrarán a Anthos Service Mesh. Si se usan certificados de complemento con Istio on GKE, estos certificados no se usan después de que las cargas de trabajo migren al plano de control administrado por Google. Todas las cargas de trabajo usan certificados firmados por la CA de Google Mesh. Los certificados de complementos no son compatibles con la CA de Mesh. Este mensaje es informativo y no se requiere ninguna acción.

  • Se detectaron políticas de seguridad que no se pudieron migrar. <Motivo de error>. Por lo general, esto falla debido a las políticas Alfa de AuthZ que se deben migrar de forma manual. Para obtener más información y contexto sobre cómo migrar las políticas, consulta Migra la política de seguridad Alfa de Istio 1.4 a las API actuales. Para obtener más información sobre el mensaje de error, consulta security-policy-migrate.

  • Se detectó una configuración de VirtualService posiblemente incompatible. <Configuración obsoleta específica>: debes actualizar las siguientes opciones de configuración VirtualService:

    • No se admite el uso de appendHeaders. En su lugar, usa spec.http.headers.
    • No es necesario usar websocketUpgrade. Está activada de forma predeterminada.
    • Reemplaza el campo abort.percent por abort.percentage.
  • Se detectó la instalación personalizada de recursos de mezcladores que no se pudieron migrar. Requiere migración manual a telemetríav2. Si las políticas de mezclador personalizado se configuran, además de la instalación predeterminada de Istio on GKE, debes migrar de forma manual estas políticas a la telemetría v2. Para obtener más información sobre cómo hacer esto, consulta Personaliza métricas de Istio.

  • La implementación <deploymentName> podría ser una puerta de enlace personalizada. Migra esto de forma manual. Debes migrar de forma manual todas las implementaciones de puertas de enlace que no sean istio-ingressgateway (que se instala de forma predeterminada). Si deseas obtener información sobre cómo actualizar las puertas de enlace del plano de control administrado por Google, consulta Configura el plano de control administrado por Google.

Para migrar configuraciones, sigue estos pasos:

  1. Migra de forma manual todas las configuraciones personalizadas (excepto la última configuración enumerada) antes de continuar con el paso 2.

  2. Usa la herramienta de migración para migrar las opciones de configuración que pueden migrarse automáticamente (o ignorarse).

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

    El resultado es similar a este:

    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. Aplica la confianza raíz de la CA de Mesh. Esto te permite migrar de la CA actual de Citadel a la CA de Mesh sin incurrir en ningún tiempo de inactividad en tus aplicaciones.

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

    El resultado es similar a este:

    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 paso toma unos minutos para que el certificado raíz de Anthos Service Mesh se distribuya a todos los espacios de nombres. Espera hasta que la secuencia de comandos finalice con un mensaje OK.

En el paso anterior, se hace lo siguiente:

  • Instala la raíz de confianza de la CA de Mesh para todas las cargas de trabajo en el clúster.
  • Cambia la configuración de las implementaciones del plano de control istio-pilot, istiod y istio-citadel. Los cambios incluyen lo siguiente:

    • Actualiza las imágenes a las compilaciones más recientes.
    • Inhabilita la verificación de trust-domain mediante la configuración de PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
    • Agrega la raíz de confianza de CA de Mesh a istio-citadel para distribuir ConfigMap a todos los espacios de nombres.
    • Agrega la raíz de confianza de CA de Mesh a istio-ca-secret para distribuir el certificado raíz.
  • Almacena los manifiestos de configuración más antiguos en el tmpdir.

  • Proporciona pasos para la función de reversión (se documenta más adelante).

Migra cargas de trabajo a Anthos Service Mesh

En esta sección, migrarás las cargas de trabajo que se ejecutan en Istio on GKE a Anthos Service Mesh. Después de la migración, verifica que los proxies de sidecar correctos (Anthos Service Mesh) se inserten en cada Pod y que la aplicación funcione según lo esperado.

Si creaste un clúster de prueba mediante los pasos del Apéndice A, usa el espacio de nombres online-boutique como ejemplo. Si realizas este procedimiento en un clúster existente, selecciona un espacio de nombres para migrar.

  1. Definir el espacio de nombres como una variable Este espacio de nombres se migra a Anthos Service Mesh:

    export NAMESPACE=NAMESPACE_NAME # or online-boutique if using the test cluster in Appendix A
    
  2. Para migrar las cargas de trabajo a Anthos Service Mesh, debes volver a etiquetar el espacio de nombres para Anthos Service Mesh. Si etiquetas el espacio de nombres, permites que Anthos Service Mesh inserte automáticamente sidecars en todas las cargas de trabajo. Para etiquetar el espacio de nombres, ejecuta el siguiente comando y establece la etiqueta en asm-managed-rapid:

    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed-rapid istio-injection- --overwrite
    
  3. Realiza un reinicio progresivo de todos los objetos Deployment en el espacio de nombres:

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

    El resultado es similar a este:

    deployment.apps/deploymentName1 restarted
    deployment.apps/deploymentName2 restarted
    ...
    
  4. Asegúrate de que todos los pods se reinicien y se ejecuten con dos contenedores por pod:

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

    El resultado es similar a este:

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

    Una buena forma de verificar este paso es observar el AGE de los Pods. Asegúrate de que el valor sea corto, por ejemplo, unos minutos.

  5. Verifica la versión del proxy de Envoy del sidecar de cualquiera de los Pods de cualquier implementación en el espacio de nombres para confirmar que ahora tengas implementados los proxies de Envoy de Anthos Service Mesh v1.10:

    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'
    

    El resultado es similar a este:

    "gcr.io/gke-release/asm/proxyv2:1.10.2-asm.2"
    "appContainerImage"
    
  6. Verifica y prueba tus aplicaciones después de reiniciar.

Ver estado de migración

Ejecute el siguiente comando para ver el estado de la migración:

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

El resultado indica si las migraciones están completas, pendientes o fallidas:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Si migrationStatus genera SUCCESS, el plano de control se actualizó de forma correcta a Anthos Service Mesh. Para actualizar el plano de datos de forma manual, completa los pasos en Migra cargas de trabajo.

Si migrationStatus genera cualquier otro estado que no sea SUCCESS, puedes elegir una de las siguientes opciones:

  • No realice ninguna acción adicional. El error de migración no debe afectar tus cargas de trabajo existentes de Istio on GKE, y Google volverá a intentar la migración durante la próxima versión.

  • Actualiza la configuración personalizada en el clúster y vuelve a ejecutar la migración de forma manual si migrationStatus muestra MIGRATION_CONFIG_ERROR.

Accede a los paneles de Anthos Service Mesh

En esta sección, ve a los paneles de Anthos Service Mesh y asegúrate de recibir los indicadores de oro para todos los objetos Service. También deberías poder ver la topología de tu aplicación.

  1. En Cloud Console, ve a la página Anthos Service Mesh.

    Ir a Anthos Service Mesh

  2. Debería poder ver las métricas y la topología de los objetos Service.

Para obtener más información sobre los paneles de Anthos Service Mesh, consulta Explora Anthos Service Mesh en Cloud Console.

Completa una migración exitosa

En esta sección, finalizarás la migración de Istio on GKE a Anthos Service Mesh. Antes de continuar con esta sección, asegúrate de que deseas continuar con Anthos Service Mesh. Esta sección también te ayuda a limpiar los artefactos de Istio on GKE. Si deseas revertir a Istio on GKE, continúa con la siguiente sección.

  1. Reemplaza istio-ingressgateway (parte de Istio estándar en GKE) por la puerta de enlace con versión del plano de control administrado por Google:

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

    El resultado es similar a este:

    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. Volver a configurar el webhook para usar el plano de control administrado por Google Todas las cargas de trabajo comienzan mediante el plano de control administrado por Google:

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

    El resultado es similar a este:

    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. Vuelve a etiquetar todos los espacios de nombres con la etiqueta de Anthos Service Mesh y realiza un reinicio progresivo de todas las cargas de trabajo para colocarlas en el plano de control administrado por Google:

    export NAMESPACE=NAMESPACE_NAME \
        kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
        istio.io/rev=asm-managed-rapid istio-injection- --overwrite`
    
        kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
    ${NAMESPACE}
    
  4. Para finalizar la migración, ejecuta el siguiente comando:

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

    El resultado es similar a este:

    Current migration state: COMPLETE
    Running: kubectl apply -f -
    configmap/asm-addon-migration-state created
    OK
    
    
  5. Inhabilita Istio on GKE mediante la ejecución del siguiente comando:

    Clústeres zonales

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

    Clústeres regionales

    gcloud beta container clusters update ${CLUSTER_1} \
        --project=$PROJECT_ID \
        --region=${CLUSTER_1_LOCATION} \
        --update-addons=Istio=DISABLED
    
  6. Borra los parámetros de configuración mediante la ejecución del siguiente comando:

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

    El resultado es similar a este:

    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. Asegúrate de que las implementaciones y los servicios de Istio on GKE se hayan quitado de forma correcta del clúster:

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

    El resultado es similar a este:

    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
    
    

    Solo verás el servicio y la implementación de la puerta de enlace de entrada de Anthos Service Mesh.

Felicitaciones. Migraste con éxito de Istio on GKE a Anthos Service Mesh v1.10 con el plano de control administrado por Google y la CA de Mesh sin interrupciones en las aplicaciones.

Revertir cambios

En esta sección, si no deseas continuar con Anthos Service Mesh, puedes revertir los cambios de Anthos Service Mesh. Después de completar esta sección, tus cargas de trabajo vuelven a Istio on GKE.

  1. Vuelve a etiquetar los espacios de nombres para usar la inserción de sidecar de Istio on GKE en lugar de Anthos Service Mesh mediante la ejecución del siguiente comando:

    export NAMESPACE=NAMESPACE_NAME
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
    
  2. Realiza un reinicio progresivo de todos los objetos Deployment en el espacio de nombres:

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
    
  3. Espera unos minutos y asegúrate de que todos los Pods estén en ejecución:

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

    El resultado es similar a este:

    NAME                       READY   STATUS    RESTARTS   AGE
    deploymentName1-PodName    2/2     Running   0          101s
    deploymentName2-PodName    2/2     Running   2          100s
    ...
    
    
  4. Verifica la versión del proxy de Envoy del sidecar de cualquiera de los Pods para confirmar que tengas proxies de Envoy de Istio on GKE v1.4 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'
    

    El resultado es similar a este:

    "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
    "appContainerImage"
    
  5. Verifica y prueba tus aplicaciones después de reiniciar.

  6. Revierte los cambios de la CA de Mesh:

    ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
    
  7. Vuelve a habilitar el webhook de Galería de Istio:

    ${WORKDIR}/migrate_addon -d tmpdir enable-galley-webook
    

Revirtiste correctamente tus cambios a Istio on GKE.

Apéndice A

Crea un clúster de GKE con Istio on GKE

En esta sección, implementarás un clúster de GKE con Istio en GKE habilitado. Puedes usar un clúster de GKE privado o no privado. Los clústeres de GKE privados deben tener un extremo de GKE público. También debes verificar la instalación de Istio on GKE.

Si ya tienes un clúster de GKE existente, puedes omitir el paso de creación y asegurarte de tener acceso al clúster que usa el archivo KUBECONFIG. El contexto que usa esta guía se define en la variable ${CLUSTER_1_CTX}. Puedes configurar el contexto de tu clúster para esta variable.

  1. Crea las variables de entorno que se usan en esta guía:

    # 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.
    
  2. Crea un clúster de GKE con Istio en GKE habilitado (este es un clúster privado). También puedes realizar estos pasos con un clúster de GKE no privado.

    Clústeres zonales

    gcloud beta container clusters create ${CLUSTER_1} \
      --project ${PROJECT_ID} \
      --zone=${CLUSTER_1_LOCATION} \
      --machine-type "e2-standard-4" \
      --num-nodes "4" --min-nodes "2" --max-nodes "5" \
      --addons=Istio --istio-config=auth=MTLS_STRICT \
      --enable-master-authorized-networks \
      --master-authorized-networks ${SHELL_IP}/32 \
      --enable-private-nodes \
      --master-ipv4-cidr 172.16.0.32/28 \
      --enable-ip-alias \
      --enable-autoscaling
    

    Clústeres regionales

    gcloud beta container clusters create ${CLUSTER_1} \
      --project ${PROJECT_ID} \
      --region=${CLUSTER_1_LOCATION} \
      --machine-type "e2-standard-4" \
      --num-nodes "4" --min-nodes "2" --max-nodes "5" \
      --addons=Istio --istio-config=auth=MTLS_STRICT \
      --enable-master-authorized-networks \
      --master-authorized-networks ${SHELL_IP}/32 \
      --enable-private-nodes \
      --master-ipv4-cidr 172.16.0.32/28 \
      --enable-ip-alias \
      --enable-autoscaling
    
  3. Confirma que el clúster sea RUNNING:

    gcloud container clusters list
    

    El resultado es similar al siguiente:

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING
    
  4. Conéctese al clúster:

    Clústeres zonales

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

    Clústeres regionales

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

    Paso opcional

    Si usas Cloud Shell para estos pasos, tu SHELL_IP podría cambiar. Si eso sucede, puedes ejecutar el siguiente comando para actualizar el valor master-authorized-networks con tu nueva dirección IP de Cloud Shell.

    Para actualizar el valor master-authorized-networks de tu clúster, ejecuta los siguientes comandos. Solo necesitas ejecutar los siguientes comandos cuando cambie la dirección IP de Cloud Shell.

    Clústeres zonales

    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
    

    Clústeres regionales

    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
    
  5. Asegúrate de que Istio esté implementado en el clúster. Verifica para asegurarte de que todos los servicios estén implementados:

    kubectl --context=${CLUSTER_1_CTX} get service -n istio-system
    

    El resultado es similar a este:

    NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                                                                                      AGE
    istio-citadel            ClusterIP      10.64.7.167    <none>        8060/TCP,15014/TCP                                                                                                                           90s
    istio-galley             ClusterIP      10.64.15.216   <none>        443/TCP,15014/TCP,9901/TCP                                                                                                                   90s
    istio-ingressgateway     LoadBalancer   10.64.9.36     <pending>     15020:31962/TCP,80:31663/TCP,443:31658/TCP,31400:32022/TCP,15029:31829/TCP,15030:30063/TCP,15031:32466/TCP,15032:30649/TCP,15443:30807/TCP   90s
    istio-pilot              ClusterIP      10.64.10.175   <none>        15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                                       90s
    istio-policy             ClusterIP      10.64.1.82     <none>        9091/TCP,15004/TCP,15014/TCP                                                                                                                 90s
    istio-sidecar-injector   ClusterIP      10.64.13.43    <none>        443/TCP,15014/TCP                                                                                                                            90s
    istio-telemetry          ClusterIP      10.64.7.76     <none>        9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                                       90s
    promsd                   ClusterIP      10.64.5.236    <none>        9090/TCP
    
  6. Asegúrate de que todos los Pods estén en ejecución y que los trabajos se completen:

    kubectl --context=${CLUSTER_1_CTX} get pods -n istio-system
    

    El resultado es similar a este:

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-f5586dffb-8c9sm                    1/1     Running     0          10m
    istio-galley-7975f77bbf-zxccq                    1/1     Running     0          10m
    istio-ingressgateway-b9477dcdb-gr7wb             1/1     Running     0          10m
    istio-pilot-59d4884d67-v6zh6                     2/2     Running     0          10m
    istio-policy-6885cb4644-h5pnv                    2/2     Running     1          10m
    istio-security-post-install-1.4.10-gke.8-q9w5s   0/1     Completed   0          10m
    istio-sidecar-injector-649d664b99-555dx          1/1     Running     0          10m
    istio-telemetry-59b6bf55c7-r2q57                 2/2     Running     1          10m
    istiod-istio-1611-6895859f65-zvlzq               1/1     Running     0          9m21s
    prometheus-6655946b9f-hdsrd                      2/2     Running     0          9m21s
    promsd-574ccb9745-w65pl                          2/2     Running     1          10m
    

Implementa Online Boutique

En esta sección, implementarás una aplicación de muestra basada en microservicios llamada Online Boutique en el clúster de GKE. Online Boutique se implementa en un espacio de nombres habilitado para Istio. Verifica que la aplicación funcione y que Istio on GKE inserte los proxies de sidecar a cada Pod.

Si ya tienes clústeres existentes con aplicaciones, puedes omitir la creación de un espacio de nombres nuevo y la implementación de Online Boutique. Puedes seguir el mismo proceso para todos los espacios de nombres en la sección Migra cargas de trabajo a Anthos Service Mesh.

  1. Implementa Online Boutique en el clúster de 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. Espera hasta que todos los objetos Deployment estén listos:

    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. Asegúrate de que haya dos contenedores por pod: el contenedor de la aplicación y el proxy de sidecar de Istio que Istio on GKE inserta de forma automática en el Pod:

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

    El resultado es similar a este:

    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. También puedes verificar la versión del proxy de sidecar de Envoy desde cualquiera de los Pods para confirmar que tienes implementado los proxies de Envoy de Istio on GKE v1.4:

    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'
    

    El resultado es similar a este:

    "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
    "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
    
  5. Para acceder a la aplicación, navega a la dirección IP de la dirección IP del objeto Service istio-ingressgateway:

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

¿Qué sigue?