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

Requisitos previos

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.

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

  • Asegúrate de ejecutar las versiones de GKE 1.17.17-gke.3100, 1.18.16-gke.1600 y 1.19.8-gke.1600 (o una posterior).

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

  • Implementar el plano de control de Cloud Service Mesh administrado por Google en el canal regular Esta guía es específica para el canal normal. Los canales estables o rápidos requieren instrucciones ligeramente modificadas. Para obtener más información sobre los canales de versiones, consulta este vínculo.
  • Migrar los parámetros de configuración de Istio a Cloud Service Mesh
  • Configura la autoridad certificadora de Cloud Service Mesh.
  • Migrar aplicaciones a Cloud Service Mesh
  • Actualiza istio-ingressgateway de Istio en GKE a Cloud Service Mesh.
  • Finalizar la migración de Cloud Service Mesh o revertir a Istio on GKE

Configura tu entorno.

Para configurar tu entorno, sigue estos pasos:

  1. En la consola de Google Cloud, activa Cloud Shell.

    Activa Cloud Shell

    En la parte inferior de la página de la consola de Google Cloud, 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 Google Cloud CLI y Google Cloud CLI 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 WORKDIR. Todos los archivos asociados con esta guía se encuentran 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 Cloud 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 por separado antes de la instalación o como parte de ella pasando el parámetro --fleet-id y una de las marcas --enable-all o --enable-registration.

  7. Tu proyecto debe tener habilitada la función de Malla de servicios. Puedes habilitarlo como parte de la instalación si pasas una de las marcas --enable-all o --enable-registration, o bien 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 tienes acceso a tu 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

Instala Cloud Service Mesh

En esta sección, implementarás Cloud 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 en un principio al mismo tiempo que un segundo plano de control (o versión 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 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 Cloud 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 los parámetros de configuración 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 qué 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 necesario para migrar algunas de las configuraciones 1.4 a Cloud Service Mesh. Responde Y a ambas preguntas:

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

    El resultado es 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 la configuración de forma manual. Este paso ayuda a identificar algunas de las opciones de configuración 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 al siguiente:

    Installing the authentication CR migration tool...
OK

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

Migra configuraciones personalizadas

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

  • Cloud Service Mesh no admite los filtros de Envoy personalizados detectados. 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. Los certificados del complemento no se migrarán a Cloud Service Mesh. Si se usan certificados de complemento con Istio on GKE, estos 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 autoridad certificadora de la malla de servicios de Google Cloud. La autoridad certificadora de Cloud Service Mesh no admite los certificados de complementos. Este mensaje es informativo y no se requiere ninguna acción.

  • Se detectaron políticas de seguridad que no se pudieron migrar. <Motivo del error>. Esto suele fallar debido a las políticas de AuthZ Alfa que deben migrarse de forma manual. Para obtener más información y contexto sobre cómo migrar políticas, consulta Migra la política de seguridad previa a Istio 1.4 Alfa a las APIs 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 configuraciones de VirtualService:

    • No se admite el uso de appendHeaders. Utiliza spec.http.headers en lugar de esta función.
    • No es necesario usar websocketUpgrade. Esta función está activada de forma predeterminada.
    • Reemplaza el campo abort.percent por abort.percentage.

  • Se detectó una instalación personalizada de recursos del mezclador que no se pudieron migrar. Requiere migración manual a telemetryv2. Si se configuran políticas de mezclador personalizadas además de la instalación predeterminada de Istio en GKE, debes migrarlas de forma manual a telemetría v2. Para obtener más información sobre cómo hacerlo, consulta Personaliza las métricas de Istio.

  • La implementación <deploymentName> puede ser una puerta de enlace personalizada. Migra esto de forma manual. Debes migrar de forma manual todas las implementaciones de la 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 enumerada) antes de continuar con el paso 2.

  2. Usa la herramienta de migración para migrar los parámetros de configuración que se pueden migrar de forma automática (o ignorarse).

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

    El resultado es 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 certificadora de Cloud Service Mesh. Esto te permite migrar de la CA de Citadel actual a la autoridad certificadora de Cloud Service Mesh sin incurrir en tiempo de inactividad en tus aplicaciones.

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

    El resultado es 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 para que el certificado raíz de Cloud 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 autoridad certificadora de Cloud Service 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. Entre los cambios, se incluyen los siguientes:

    • Actualiza las imágenes a las compilaciones más recientes.
    • Inhabilitando la verificación de trust-domain mediante la configuración de PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
    • Agrega la raíz de confianza de la autoridad certificadora de Cloud Service Mesh a istio-citadel para distribuir ConfigMap a todos los espacios de nombres.
    • Agrega la raíz de confianza de la autoridad certificadora de Cloud Service 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 documentan más adelante).

Migra cargas de trabajo a Cloud Service Mesh

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

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 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 para Cloud Service Mesh. El etiquetado del 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 configura la etiqueta como asm-managed:

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

  5. Verifica la versión del archivo adicional del proxy de Envoy desde cualquiera de los Pods de cualquier objeto Deployment en el espacio de nombres para confirmar que ahora tienes los 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 es 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 deseas que Google administre las actualizaciones de los proxies, habilita el plano de datos administrado por Google.

Consulta 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 completaron, están pendientes o fallaron:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Si migrationStatus muestra SUCCESS, el plano de control se actualizó de forma correcta a Cloud 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 estado distinto de SUCCESS, puedes elegir una de las siguientes opciones:

  • No debes realizar ninguna acción adicional si el error de migración no afecta a tus cargas de trabajo existentes de Istio en GKE. De lo contrario, se debe rollback si es necesario.
  • Actualiza los parámetros de configuración personalizados en el clúster y vuelve a ejecutar la migración de forma manual si migrationStatus muestra MIGRATION_CONFIG_ERROR.

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

Accede a los paneles de la malla de servicios de Cloud

En esta sección, ve a los paneles de la malla de servicios de Cloud y asegúrate de recibir los indicadores dorados para todos los servicios. También deberías poder ver la topología de tu aplicación.

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

    Ir a Cloud 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 Cloud Service Mesh, consulta Explora Cloud Service Mesh en la consola de Google Cloud.

Completa una migración exitosa

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 continuar con Cloud Service Mesh. Esta sección también te ayuda a limpiar tus artefactos de Istio en GKE. Si quieres revertir a Istio en GKE, continúa con la siguiente sección.

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

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

    El resultado es 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 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 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 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 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, como se espera en las instalaciones nuevas de Cloud Service Mesh o en implementaciones nuevas. Debido a que la inserción automática falla si un espacio de nombres tiene la etiqueta istio-injection y la de revisión, todos los comandos kubectl label en la documentación de Istio on GKE incluyen quitar la etiqueta istio-injection.

  4. Finaliza la migración ejecutando el siguiente comando:

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

    El resultado es similar al siguiente:

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

  5. Inhabilita Istio on GKE con 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. Ejecuta el siguiente comando para limpiar los parámetros de configuración:

    ${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 en 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 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 ves el servicio y la Deployment de la puerta de enlace de entrada de Cloud Service Mesh.

Felicitaciones. Migraste de forma correcta de Istio en GKE a Cloud Service Mesh con el plano de control administrado por Google y la autoridad certificadora de Cloud Service Mesh sin tiempo de inactividad en tus aplicaciones.

Revertir cambios

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

  1. Revierte los cambios cambiantes del webhook:

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

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

    para 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

    para 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 progresivo de todos los objetos Deployment en el 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 es 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 de archivo adicional del proxy de Envoy desde cualquiera de los Pods para confirmar que tienes los proxies de 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 es 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 certificadora de Cloud Service Mesh:

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

  8. Vuelve a habilitar el webhook de Galley de Istio:

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

Revirtió correctamente sus cambios a Istio en GKE.

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 Cloud 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 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 verificar la versión de archivo adicional del proxy de Envoy desde cualquiera de los Pods para confirmar que tienes los proxies de Envoy de Istio on 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 es similar al siguiente:

    "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}'

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 implementa Istio administrado 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 proporcionarte las funciones más recientes de la malla de servicios y una implementación de malla de servicios compatible, actualizaremos todos los usuarios de Istio en GKE a Cloud Service Mesh.

Cloud Service Mesh es el producto de malla de servicios administrado y compatible de Google con la tecnología de las APIs de Istio. Cloud Service Mesh es para Istio lo que GKE es para Kubernetes. Debido a que Cloud Service Mesh se basa en las API de Istio, puedes seguir usando tus configuraciones de Istio cuando migres a Cloud Service Mesh. Además, no existe una dependencia de propiedad exclusiva de un proveedor.

Cloud Service Mesh proporciona los siguientes beneficios:

  • Una malla de servicios administrada por Google y compatible con Google.
  • API de Istio sin dependencia con un proveedor
  • Paneles de telemetría listos para usar y administración de los SLO sin la necesidad de administrar soluciones de terceros adicionales.
  • Opciones de autoridades certificadoras alojadas en Google.
  • Integración con las herramientas de redes de Google Cloud e Identity-Aware Proxy (IAP)
  • Compatibilidad con plataformas híbridas y de múltiples nubes.

Para obtener más información sobre las características y funciones de Cloud Service Mesh, consulta Funciones compatibles del plano de control administrado por Google.

¿Hay algún tiempo de inactividad asociado con esta migración?

La secuencia de comandos de migración está diseñada para evitar el tiempo de inactividad. La secuencia de comandos instala Cloud Service Mesh como un plano de control de versión canary junto con tu plano de control de Istio existente. El istio-ingressgateway se actualiza en el lugar. Luego, vuelve a etiquetar los espacios de nombres habilitados para Istio para comenzar a usar Cloud Service Mesh con la autoridad certificadora de Cloud Service Mesh.

Asegúrate de tener PodDisruptionBudgets de forma correcta para tus aplicaciones, de modo que no experimentes ningún tiempo de inactividad. Aunque puedes evitar el tiempo de inactividad, si realizas esta migración por tu cuenta, te recomendamos que la realices durante un período de mantenimiento programado. Las migraciones impulsadas por Google se realizan durante un período de mantenimiento de GKE. Asegúrate de que los clústeres de GKE tengan configurados períodos de mantenimiento.

¿Existe algún costo asociado al uso de Cloud Service Mesh?

Hay dos formas de usar Cloud Service Mesh en GKE:

¿Hay funciones o parámetros de configuración que no son compatibles con la versión más reciente de Cloud Service Mesh?

La secuencia de comandos verifica todas las configuraciones de Istio y las migra a la versión más reciente de Cloud Service Mesh. Hay ciertas 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 verificación de configuración y te informa si alguna configuración requiere pasos adicionales.

¿Cambia la migración mis configuraciones actuales de Istio?

No, tus parámetros de configuración de Istio funcionan en Cloud Service Mesh sin necesidad de cambios.

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

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

Si la migración falla, ¿es posible revertirla?

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

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

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

¿Cómo puedo obtener ayuda adicional con esta migración?

Nuestro equipo de asistencia al cliente te ayudará con gusto. Puedes abrir un caso de asistencia desde la consola de Google Cloud. Para obtener más información, consulta Administra casos de asistencia.

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

Tus componentes de Istio siguen funcionando, pero Google ya no administra tu instalación de Istio. Ya no recibirás actualizaciones automáticas, y no se garantiza que la instalación funcione mientras se actualiza la versión del clúster de Kubernetes.

Para obtener más información, consulta Asistencia de Istio.