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 Istio en Google Kubernetes Engine (Istio en GKE) versión 1.4 o 1.6 (Beta) a Anthos Service Mesh administrado con el plano de control administrado por Google y la autoridad certificadora de Anthos Service Mesh (CA de Mesh).

Prerequisites

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

  • Un clúster de GKE con Istio on 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 quieres probar primero 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 en GKE habilitado e implementar una aplicación de prueba.

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

  • Asegúrate de ejecutar la versión 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ o 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 Cómo configurar tu proyecto.

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

Objetivos

  • Implementa el plano de control administrado por Google de Anthos Service Mesh en el canal regular. Esta guía es específica para el canal regular, los canales estables o rápidos requieren instrucciones ligeramente modificadas. Para obtener más información sobre los canales de versiones, visita este vínculo.
  • Migrar la configuración de Istio a Anthos Service Mesh
  • Configura la CA de la malla.
  • Migrar 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 la consola de Google Cloud, activa Cloud Shell.

    Activar Cloud Shell

    En la parte inferior de la página de la consola, se inicia una sesión de Cloud Shell y se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con la CLI de Google Cloud y la CLI de Google Cloud ya instaladas, y con valores ya establecidos para el 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 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 que el clúster de GKE se migre 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}
    
  6. Tus clústeres deben estar registrados en una flota. Este paso se puede realizar de forma separada antes de la instalación o como parte de la instalación mediante el pase de las marcas --fleet-id y --enable-all o --enable-registration.

  7. Tu proyecto debe tener habilitada la función de Malla de servicios. Para habilitarlo, como parte de la instalación, pasa una de las marcas --enable-all o --enable-registration o ejecuta el siguiente comando antes de la instalación:

      gcloud container hub mesh enable --project=FLEET_PROJECT_ID
    

    en el que FLEET_PROJECT_ID es el ID del proyecto host de la flota.

Paso opcional

Si el clúster es privado (con master-authorized-networks habilitado), agrega tu $SHELL_IP a la lista de entidades permitidas master-authorized-networks. Si ya tiene acceso a su clúster, es posible que este paso no sea obligatorio.

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 Anthos Service Mesh con el plano de control administrado por Google del canal regular en el clúster de GKE. Este plano de control se implementa inicialmente como un segundo plano (o una versión canary).

  1. Descarga la versión más reciente de la secuencia de comandos que instala Anthos Service Mesh en el directorio de trabajo actual y haz que la secuencia de comandos sea ejecutable con el siguiente comando:

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

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

    Esta operación puede tardar unos minutos en completarse.

  3. Verifica el plano de control administrado por Google

  4. Copia 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 a migrar a Anthos Service Mesh. La utilidad de 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 las opciones de configuración a Anthos Service Mesh

En esta sección, migrarás los parámetros de configuración de Istio on GKE en Anthos Service Mesh. La secuencia de comandos guiada identifica qué configuraciones se pueden migrar y cuáles no.

  1. Descargue la herramienta de migración y haga que sea ejecutable:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
    chmod +x ${WORKDIR}/migrate_addon
    
  2. Inhabilitar el webhook de validación de Galley Este paso es obligatorio para migrar algunas de las configuraciones 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. Verificar y migrar la configuración de forma manual En este paso, se ayuda a identificar algunas de las configuraciones que se deben migrar 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, además, imprime la información sobre lo que se requiere. Estas personalizaciones son las siguientes:

  • Los filtros de Envoy personalizados detectados no son compatibles con Anthos Service Mesh. Quítalos si es posible. 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. Los certificados del complemento no se migrarán a Anthos Service Mesh. Si se usan certificados de complementos con Istio on GKE, estos certificados no se usan después de que las cargas de trabajo migran 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. <Error reason&gt.. 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 políticas, consulta Migra la política de seguridad de la versión alfa anterior a 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 posiblemente incompatible. <Specific configuración obsoleta&gt.. Debes actualizar las siguientes configuraciones VirtualService:

    • No se admite el uso de appendHeaders. Usa spec.http.headers en su lugar.
    • 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 combinación que no se pudieron migrar. Requiere migración manual a telemetryv2. Si se configuran políticas de batidora personalizadas 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 las métricas de Istio.

  • Deployment <deploymentName> podría ser una puerta de enlace personalizada. Migrarlo de forma manual. Debes migrar de forma manual todas las implementaciones de puerta 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 mencionada) antes de continuar con el paso 2.

  2. Usa la herramienta de migración para migrar las configuraciones que se pueden migrar de manera automática (o ignorar).

    ${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 de raíz de la CA de Mesh. Esto te permite migrar de la CA de Citadel actual 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 tarda unos minutos en 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 del clúster.
  • Cambia la configuración de las implementaciones del plano de control istio-pilot, istiod y istio-citadel. Los cambios incluyen lo siguiente:

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

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

Migra las cargas de trabajo a Anthos Service Mesh

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

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

  1. Define 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. Etiquetar el espacio de nombres permite que Anthos Service Mesh inserte sidecars de forma automática en todas las cargas de trabajo. Para etiquetar el espacio de nombres, ejecuta el siguiente comando y configura la etiqueta en asm-managed:

    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
    
  3. Reinicia 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 manera de verificar este paso es observar el AGE de los Pods. Asegúrate de que el valor sea corto, por ejemplo, unos minutos.

  5. Verifique la versión del proxy de Envoy de sidecar desde cualquiera de los Pods de cualquier Deployment en el espacio de nombres para confirmar que ahora tenga implementados los proxies de Envoy de Anthos Service Mesh:

    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.11.5-asm.3"
    "appContainerImage"
    
  6. Verifica y prueba tus aplicaciones después de reiniciar.

  7. (Opcional) Si quiere que Google administre las actualizaciones de los proxies, habilite el plano de datos administrado por Google.

Consulta el estado de la 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 con errores:

{"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 que se indican en Migra cargas de trabajo.

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

  • No realizar ninguna acción adicional si el error de migración no afecta a sus cargas de trabajo existentes de Istio on GKE. De lo contrario, realice la reversión, si es necesario.
  • 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.

Puede ver las métricas del plano de control en el Explorador de métricas después de una migración exitosa. Consulte verify_control_plane_metrics

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 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 la consola.

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 quieras continuar con Anthos Service Mesh. En esta sección, también se ayuda a limpiar los artefactos Istio on GKE. Si desea revertir a Istio on GKE, continúe con la siguiente sección.

  1. Reemplaza istio-ingressgateway (parte de Istio on GKE) estándar por la puerta de enlace de versión con plano de control administrada 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. Vuelve a configurar el webhook para usar el plano de control administrado por Google. Todas las cargas de trabajo comienzan con 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. Reetiqueta todos los espacios de nombres con la etiqueta de Anthos Service Mesh y realiza un reinicio progresivo de todas las cargas de trabajo para obtenerlas 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 istio-injection- --overwrite`
    
        kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
    ${NAMESPACE}
    

    Puedes ignorar el mensaje "istio-injection not found" en el resultado. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones de Anthos Service Mesh o en implementaciones nuevas. Debido a que la inserción automática falla si un espacio de nombres tiene la etiqueta de revisión istio-injection y otra, todos los comandos kubectl label en la documentación de Istio on GKE incluyen quitar la etiqueta istio-injection.

  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: SUCCESS
    Running: kubectl apply -f -
    configmap/asm-addon-migration-state created
    OK
    
    
  5. Inhabilita Istio en GKE ejecutando el 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. Para limpiar configuraciones, ejecuta el 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úrese de que las implementaciones y los servicios de Istio on GKE se hayan quitado correctamente 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 ve el objeto Service y la implementación de la puerta de enlace de entrada de Anthos Service Mesh.

Felicitaciones. Migraste correctamente de Istio on GKE a Anthos Service Mesh con el plano de control administrado por Google y la CA de Mesh sin ningún tiempo de inactividad en tus 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, sus cargas de trabajo regresarán a Istio on GKE.

  1. Vuelva a etiquetar los espacios de nombres para que usen la inyección del archivo adicional de Istio on GKE en lugar de Anthos Service Mesh. Para ello, ejecute el siguiente comando:

    para espacios de nombres con cargas de trabajo de la versión 1.4:

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

    para espacios de nombres con cargas de trabajo de la versión 1.6:

    export NAMESPACE=NAMESPACE_NAME
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
    

  2. Reinicia todos los objetos Deployment en el espacio de nombres:

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
    
  3. Espere unos minutos y asegúrese 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. Verifique la versión del proxy de Envoy de sidecar desde cualquiera de los Pods para confirmar que haya implementados los proxies de Envoy de Istio on GKE v1.4:

    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"
    

    o

    "gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
    "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. Vuelva a habilitar el webhook de la Galería de Istio:

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

Revirtió correctamente sus cambios a Istio on GKE.

Apéndice A

Cree un clúster de GKE con Istio on GKE

En esta sección, implementará un clúster de GKE con Istio on 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 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 on 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 a este:

    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 puede cambiar. Si esto sucede, puedes ejecutar el siguiente comando para actualizar el valor de master-authorized-networks con tu nueva dirección IP de Cloud Shell.

    Para actualizar el valor de 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úrese de que Istio esté implementado en el clúster. Verifica que se implementen todos los objetos Service:

    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úrese de que todos los Pods estén en ejecución y de que los trabajos estén completos:

    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 puede verificar la versión del proxy de Envoy de sidecar desde cualquiera de los Pods para confirmar que haya 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?