Migrar de Istio en GKE a Cloud 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) de la versión 1.4 o 1.6 (beta) a Cloud Service Mesh gestionado con el plano de control gestionado por Google y la autoridad de certificación de Cloud Service Mesh.

Requisitos previos

Para completar esta guía, debes cumplir los siguientes requisitos previos:

  • Un clúster de GKE con Istio on GKE habilitado. Si tienes varios clústeres de GKE, sigue los mismos pasos para todos ellos.

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

  • Asegúrate de que estás usando GKE 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ o una versión posterior.

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

  • El usuario o la cuenta de servicio que ejecute esta secuencia de comandos debe tener los permisos de IAM que se describen en Configurar el proyecto.

  • Esta guía se ha probado en Cloud Shell, por lo que te recomendamos que lo utilices para seguir los pasos que se indican en ella.

Objetivos

  • Despliega el plano de control gestionado por Google de Cloud Service Mesh en el canal normal. Esta guía es específica para el canal normal. Los canales estable o rápido requieren instrucciones ligeramente modificadas. Para obtener más información sobre los canales de lanzamiento, consulta este enlace.
  • Migra las configuraciones de Istio a Cloud Service Mesh.
  • Configura la autoridad de certificación de Cloud Service Mesh.
  • Migra aplicaciones a Cloud Service Mesh.
  • Actualiza istio-ingressgateway de Istio on GKE a Cloud Service Mesh.
  • Finaliza la migración a Cloud Service Mesh o vuelve a Istio en GKE.

Configurar un entorno

Para configurar tu entorno, sigue estos pasos:

  1. En la Google Cloud consola, 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 un mensaje de la línea de comandos. Google Cloud Cloud Shell es un entorno de shell con la CLI de Google Cloud ya instalada y con los valores ya definidos 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 WORKDIR. Todos los archivos asociados a esta guía se guardan en WORKDIR para que puedas eliminarlo cuando termines.WORKDIR

    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 que ya tengas y que contenga el contexto del clúster de GKE que quieras migrar a Cloud Service Mesh.

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. Obtén las credenciales del 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 por separado antes de la instalación o como parte de la instalación. Para ello, debes incluir las marcas --fleet-id y --enable-all o --enable-registration.

  7. Tu proyecto debe tener habilitada la función Service Mesh. Puedes habilitarlo como parte de la instalación pasando una de las marcas --enable-all o --enable-registration, o ejecutando el siguiente comando antes de la instalación:

      gcloud container hub mesh enable --project=FLEET_PROJECT_ID

    donde 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), añade tu $SHELL_IP a la lista de permitidos de master-authorized-networks. Si ya tienes acceso a tu clúster, puede que no sea necesario que sigas este paso.

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

Instalar Cloud Service Mesh

En esta sección, desplegarás Cloud Service Mesh con el plano de control gestionado por Google del canal normal en el clúster de GKE. Este plano de control se implementa inicialmente junto con otro plano de control secundario (o canary).

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

    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 para instalar Cloud Service Mesh con el plano de control gestionado por Google del canal normal:

    ./asmcli install \
-p ${PROJECT_ID} \
-l ${CLUSTER_1_LOCATION} \
-n ${CLUSTER_1} \
--fleet_id ${FLEET_PROJECT_ID} \
--managed \
--verbose \
--output_dir ${CLUSTER_1} \
--enable-all \
--channel regular

    Este paso puede tardar unos minutos.

  3. Verificar el plano de control gestionado por Google

  4. Copia istioctl en la carpeta WORKDIR:

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

En la siguiente sección, descargará y ejecutará la secuencia de comandos migrate_addon para ayudarle a migrar a Cloud Service Mesh. La utilidad de línea de comandos istioctl debe estar en la misma carpeta que la secuencia de comandos migrate_addon. Utiliza la carpeta WORKDIR tanto para la utilidad de línea de comandos istioctl como para la secuencia de comandos migrate_addon.

Migrar configuraciones a Cloud Service Mesh

En esta sección, migrarás las configuraciones de Istio en GKE a Cloud Service Mesh. La secuencia de comandos guiada identifica qué configuraciones 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/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
chmod +x ${WORKDIR}/migrate_addon

  2. Inhabilita el webhook de validación de Galley. Este paso es obligatorio para migrar algunas de las configuraciones de la versión 1.4 a Cloud Service Mesh. Responde Y a ambas preguntas:

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

    El resultado debería ser similar al siguiente:

    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 manualmente la configuración. Este paso ayuda a identificar algunas de las configuraciones que deben migrarse manualmente antes de migrar las cargas de trabajo al plano de control gestionado por Google.

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

    El resultado debería ser similar al siguiente:

    Installing the authentication CR migration tool...
OK

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

Migrar configuraciones personalizadas

Es posible que tengas que migrar manualmente las configuraciones personalizadas antes de migrar a Cloud Service Mesh. La secuencia de comandos anterior identifica las configuraciones personalizadas e imprime información sobre lo que se necesita. Estas personalizaciones son las siguientes:

  • Cloud Service Mesh no admite los filtros de Envoy personalizados detectados. Si es posible, quítalos. Actualmente, los filtros de Envoy no se admiten en el plano de control gestionado por Google.

  • Se ha detectado un certificado de complemento personalizado. Los certificados del complemento no se migrarán a Cloud Service Mesh. Si se usan certificados de complementos con Istio en GKE, estos certificados no se usarán después de que las cargas de trabajo migren al plano de control gestionado por Google. Todas las cargas de trabajo usan certificados firmados por la autoridad de certificación de Google Cloud Service Mesh. La autoridad de certificación de Cloud Service Mesh no admite certificados de complementos. Este mensaje es informativo y no es necesario que hagas nada.

  • Se han detectado políticas de seguridad que no se han podido migrar. <Error reason>. Este error suele producirse debido a políticas de autorización alfa que deben migrarse manualmente. Para obtener más contexto e información sobre cómo migrar políticas, consulta Migrar la política de seguridad de la versión alfa anterior a Istio 1.4 a las APIs actuales. Para obtener más información sobre el mensaje de error, consulta security-policy-migrate.

  • Se ha detectado una configuración de VirtualService posiblemente incompatible. <Specific deprecated config>. Debe actualizar las siguientes VirtualService configuraciones:

    • No se admite el uso de appendHeaders. En su lugar, usa spec.http.headers.
    • No es necesario usar websocketUpgrade. Esta opción está activada de forma predeterminada.
    • Sustituye el campo abort.percent por abort.percentage.

  • Se ha detectado una instalación personalizada de recursos de mezclador que no se ha podido migrar. Requiere una migración manual a telemetryv2. Si se configuran políticas de mezclador personalizadas además de la instalación predeterminada de Istio en GKE, debe migrar manualmente estas políticas a la telemetría v2. Para obtener más información sobre cómo hacerlo, consulta Personalizar métricas de Istio.

  • El despliegue <deploymentName> podría ser una pasarela personalizada. Migra esto manualmente. Debe migrar manualmente todas las implementaciones de la pasarela, excepto la istio-ingressgateway (que se instala de forma predeterminada). Para obtener información sobre cómo actualizar las pasarelas del plano de control gestionado por Google, consulta Configurar el plano de control gestionado por Google.

Para migrar las configuraciones, sigue estos pasos:

  1. Migra manualmente todas las configuraciones personalizadas (excepto la última de la lista) antes de ir al paso 2.

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

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

    El resultado debería ser similar al siguiente:

    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 autoridad de certificación de Cloud Service Mesh. De esta forma, puedes migrar de la AC de Citadel actual a la autoridad de certificación de Cloud Service Mesh sin que tus aplicaciones sufran ningún tiempo de inactividad.

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

    El resultado debería ser similar al siguiente:

    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 distribuir el certificado raíz de Cloud Service Mesh a todos los espacios de nombres. Espera a que la secuencia de comandos termine con un mensaje OK.

En el paso anterior se hace lo siguiente:

  • Instala la raíz de confianza de la autoridad de certificación de Cloud Service Mesh para todas las cargas de trabajo del clúster.

  • Cambia las configuraciones de los Deployments del plano de control istio-pilot, istiod y istio-citadel. Entre los cambios se incluyen los siguientes:

    • Actualizar las imágenes a las compilaciones más recientes.
    • Inhabilitar la verificación trust-domain mediante la configuraciónPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
    • Añadir la raíz de confianza de la autoridad de certificación de Cloud Service Mesh a istio-citadel para distribuir ConfigMap a todos los espacios de nombres.
    • Añadir la raíz de confianza de la autoridad de certificación de Cloud Service Mesh a istio-ca-secret para distribuir el certificado raíz.

  • Almacena los manifiestos de configuración antiguos en tmpdir.

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

Migrar cargas de trabajo a Cloud Service Mesh

En esta sección, migrará las cargas de trabajo que se ejecutan en Istio en GKE a Cloud Service Mesh. Después de la migración, comprueba que los proxies sidecar correctos (Cloud Service Mesh) se hayan insertado en todos los pods y que la aplicación funcione correctamente.

Si vas a realizar este procedimiento en un clúster, selecciona un espacio de nombres que quieras migrar.

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

    export NAMESPACE=NAMESPACE_NAME

  2. Para migrar cargas de trabajo a Cloud Service Mesh, debes volver a etiquetar el espacio de nombres de Cloud Service Mesh. Etiquetar el espacio de nombres permite que Cloud Service Mesh inserte automáticamente sidecars en todas las cargas de trabajo. Para etiquetar el espacio de nombres, ejecuta el siguiente comando y asigna la etiqueta asm-managed:

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

  3. Realiza un reinicio gradual de todos los Deployments del espacio de nombres:

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

    El resultado debería ser similar al siguiente:

    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 debería ser similar al siguiente:

    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 consultar el AGE de los pods. Asegúrate de que el valor sea breve (por ejemplo, unos minutos).

  5. Comprueba la versión del proxy sidecar de Envoy de cualquiera de los pods de cualquier implementación del espacio de nombres para confirmar que ahora tienes proxies de Envoy de Cloud Service Mesh implementados:

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

    El resultado debería ser similar al siguiente:

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

  6. Verifica y prueba tus aplicaciones después de reiniciar.

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

  7. (Opcional) Si quieres que Google gestione las actualizaciones de los proxies, habilita la opción Plano de datos gestionado por Google.

Ver el estado de la migración

Ejecuta 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 se han completado, están pendientes o han fallado:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Si migrationStatus devuelve SUCCESS, el plano de control se ha actualizado correctamente a Cloud Service Mesh. Para actualizar manualmente el plano de datos, sigue los pasos que se indican en Migrar cargas de trabajo.

Si migrationStatus devuelve un estado distinto de SUCCESS, puedes hacer lo siguiente:

Puede ver las métricas del plano de control en el explorador de métricas después de completar la migración. Consulte verify_control_plane_metrics.

Acceder a los paneles de control de Cloud Service Mesh

En esta sección, accederás a los paneles de control de Cloud Service Mesh y te asegurarás de que recibes las señales de oro de todos los servicios. También deberías poder ver la topología de tu aplicación.

  1. En la Google Cloud consola, ve a la página Cloud Service Mesh.

    Ir a Cloud Service Mesh

  2. Deberías poder ver las métricas y la topología de tus servicios.

Para obtener más información sobre los paneles de Cloud Service Mesh, consulta el artículo sobre cómo explorar Cloud Service Mesh en la consola Google Cloud .

Completar una migración correcta

En esta sección, finalizarás la migración de Istio en GKE a Cloud Service Mesh. Antes de continuar con esta sección, asegúrate de que quieres usar Cloud Service Mesh. En esta sección también se explica cómo limpiar los artefactos de Istio on GKE. Si quieres volver a Istio en GKE, ve a la siguiente sección.

  1. Sustituye istio-ingressgateway (que forma parte de Istio estándar en GKE) por la versión del gateway con control de versiones del plano de control gestionado por Google:

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

    El resultado debería ser similar al siguiente:

    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 que use el plano de control gestionado por Google. Todas las cargas de trabajo empiezan a usar el plano de control gestionado por Google:

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

    El resultado debería ser similar al siguiente:

    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 Cloud Service Mesh y reinicia todas las cargas de trabajo para que se ejecuten en el plano de control gestionado 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 la salida. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones o implementaciones de Cloud Service Mesh. Como la inyección automática falla si un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Istio en GKE incluyen la eliminación de la etiqueta istio-injection.

  4. Para finalizar la migración, ejecuta el siguiente comando:

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

    El resultado debería ser similar al siguiente:

    Current migration state: SUCCESS
Running: kubectl apply -f -
configmap/asm-addon-migration-state created
OK

  5. Inhabilita Istio on 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 las configuraciones, ejecuta el siguiente comando:

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

    El resultado debería ser similar al siguiente:

    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 en GKE se hayan eliminado correctamente del clúster:

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

    El resultado debería ser similar al siguiente:

    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 el deployment de la puerta de enlace de entrada de Cloud Service Mesh.

¡Enhorabuena! Has migrado correctamente de Istio en GKE a Cloud Service Mesh con el plano de control gestionado por Google y la autoridad de certificación de Cloud Service Mesh sin que tus aplicaciones hayan sufrido ningún tiempo de inactividad.

Deshacer cambios

En esta sección, si no quieres continuar con Cloud Service Mesh, puedes deshacer los cambios de Cloud Service Mesh. Después de completar esta sección, tus cargas de trabajo volverán a Istio on GKE.

  1. Revierte los cambios del webhook de mutación: 

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

  2. Vuelve a etiquetar los espacios de nombres para usar la inyección de sidecar de Istio en GKE en lugar de Cloud Service Mesh ejecutando el siguiente comando:

    En el caso de los 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

    En el caso de los 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

  3. Realiza un reinicio gradual de todos los Deployments del espacio de nombres:

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

  4. 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 debería ser similar al siguiente:

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

  5. Verifica la versión del proxy Envoy adicional de cualquiera de los pods para confirmar que tienes proxies Envoy de Istio en 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 debería ser similar al siguiente:

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

    o

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

  6. Verifica y prueba tus aplicaciones después de reiniciar.

  7. Revierte los cambios de la autoridad de certificación de Cloud Service Mesh:

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

  8. Vuelve a habilitar el webhook de Istio Galley:

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

Has revertido correctamente los cambios en Istio on GKE.

Desplegar Online Boutique

En esta sección, desplegarás una aplicación de ejemplo basada en microservicios llamada Online Boutique en el clúster de GKE. Online Boutique se ha desplegado en un espacio de nombres habilitado para Istio. Verifica que la aplicación funciona y que Istio en GKE inserta los proxies adicionales en cada pod.

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

  1. Despliega 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 todas las implementaciones estén listas:

    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 sidecar de Istio que Istio en GKE inserta automáticamente en el pod:

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

    El resultado debería ser similar al siguiente:

    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 comprobar la versión del proxy sidecar de Envoy desde cualquiera de los pods para confirmar que tienes proxies de Envoy de Istio en GKE v1.4 implementados:

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

    El resultado debería ser similar al siguiente:

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

  5. Accede a la aplicación desplazándote hasta la dirección IP del servicio istio-ingressgateway:

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

Preguntas frecuentes

En esta sección se describen las preguntas frecuentes y las respuestas relacionadas sobre la migración de Istio en GKE a Cloud Service Mesh.

¿Por qué se me está migrando de Istio en GKE a Cloud Service Mesh?

Istio en Google Kubernetes Engine es una función beta que despliega Istio gestionado por Google en un clúster de Google Kubernetes Engine (GKE). Istio on GKE implementa una versión no compatible (versión 1.4 de Istio). Para ofrecerte las funciones más recientes de service mesh y una implementación compatible de service mesh, vamos a actualizar todos los usuarios de Istio en GKE a Cloud Service Mesh.

Cloud Service Mesh es el producto de malla de servicios gestionado y compatible de Google que se basa en las APIs de Istio. Cloud Service Mesh es a Istio lo que GKE es a Kubernetes. Como Cloud Service Mesh se basa en las APIs de Istio, puedes seguir usando tus configuraciones de Istio al migrar a Cloud Service Mesh. Además, no hay dependencia de proveedores.

Cloud Service Mesh ofrece las siguientes ventajas:

  • Una malla de servicios gestionada y compatible con Google.
  • APIs de Istio sin dependencia de proveedores.
  • Paneles de control de telemetría y gestión de SLOs listos para usar sin necesidad de gestionar soluciones de terceros adicionales.
  • Opciones de autoridad de certificación alojada en Google.
  • Integración con Google Cloud redes y Identity-Aware Proxy (IAP).
  • Compatibilidad con plataformas híbridas y multinube.

Para obtener más información sobre las funciones y las capacidades de Cloud Service Mesh, consulta las funciones compatibles con el plano de control gestionado por Google.

¿Hay algún periodo de inactividad asociado a esta migración?

La secuencia de comandos de migración se ha diseñado para evitar el tiempo de inactividad. La secuencia de comandos instala Cloud Service Mesh como un plano de control canary junto con el plano de control de Istio que ya tengas. La istio-ingressgateway se actualiza in situ. A continuación, vuelve a etiquetar los espacios de nombres habilitados para Istio para empezar a usar Cloud Service Mesh con la autoridad de certificación de Cloud Service Mesh.

Asegúrate de que los PodDisruptionBudgets estén configurados correctamente en tus aplicaciones para que no se produzcan periodos de inactividad. Aunque puedes evitar el tiempo de inactividad, si vas a realizar esta migración por tu cuenta, te recomendamos que lo hagas durante una ventana de mantenimiento programada. Las migraciones controladas por Google se realizan durante una ventana de mantenimiento de GKE. Asegúrate de que tus clústeres de GKE tengan configuradas ventanas de mantenimiento.

¿Tiene algún coste asociado el uso de Cloud Service Mesh?

Hay dos formas de usar Cloud Service Mesh en GKE:

¿Hay alguna función o configuración que no sea compatible con la última versión de Cloud Service Mesh?

La secuencia de comandos comprueba todas las configuraciones de Istio y las migra a la versión más reciente de Cloud Service Mesh. Hay determinadas configuraciones que pueden requerir pasos adicionales para migrar de la versión 1.4 de Istio a la versión 1.10 de Cloud Service Mesh. La secuencia de comandos realiza una comprobación de la configuración y te informa si alguna configuración requiere pasos adicionales.

¿La migración cambia mis configuraciones actuales de Istio?

No, tus configuraciones de Istio funcionan en Cloud Service Mesh sin necesidad de hacer ningún cambio.

Después de migrar a Cloud Service Mesh, ¿puedo volver a Istio?

Sí, no hay ningún compromiso para usar Cloud Service Mesh. Puedes desinstalar Cloud Service Mesh y volver a instalar Istio en cualquier momento.

Si la migración falla, ¿se puede revertir?

Sí, la secuencia de comandos te permite volver a tu versión anterior de Istio on GKE.

¿A qué versión de Istio puedo migrar con esta secuencia de comandos?

La secuencia de comandos te ayuda a migrar de Istio on GKE versión 1.4 a Cloud Service Mesh versión 1.10. La secuencia de comandos valida tu versión de Istio durante la fase previa a la migración y te informa de si se puede migrar.

¿Cómo puedo obtener más ayuda con esta migración?

Nuestro equipo de Asistencia estará encantado de ayudarte. Puedes abrir un caso de asistencia desde la consola Google Cloud . Para obtener más información, consulta Gestionar casos de asistencia.

¿Qué ocurre si no migro a Cloud Service Mesh?

Tus componentes de Istio seguirán funcionando, pero Google ya no gestionará tu instalación de Istio. Ya no recibirás actualizaciones automáticas y no se garantiza que la instalación funcione a medida que se actualice la versión del clúster de Kubernetes.

Para obtener más información, consulta la página sobre la asistencia de Istio.