Migrar desde Istio

En esta página, se explica cómo ejecutar la secuencia de comandos para migrar de Istio a Anthos Service Mesh 1.10.6 en un clúster de GKE para una malla que contiene uno o más clústeres que se encuentran en el mismo proyecto de Google Cloud. Si tienes Istio 1.6 o una versión anterior, primero debes actualizar antes de migrar a Anthos Service Mesh. Si tienes Istio 1.7 o una versión posterior, es posible que puedas usar Migra de Istio 1.7 o posterior a la CA de Mesh y Anthos Service Mesh. Si necesitas realizar una actualización, ve a la página Actualiza Istio en la versión de Istio aplicable. Ten en cuenta que no se prueba ni se recomienda de forma oficial la actualización de Istio en más de una versión secundaria (por ejemplo, de 1.6.x a 1.8.x) en un paso.

Antes de comenzar

Antes de comenzar la migración, asegúrate de tener lo siguiente:

La secuencia de comandos requiere que tengas los permisos necesarios o que incluyas las marcas --enable_all o --enable_gcp_iam_roles para permitir que la secuencia de comandos habilite el permiso para ti. Del mismo modo, para permitir que la secuencia de comandos habilite las API requeridas y actualice el clúster, especifique la marca --enable_all o más marcas de habilitación más detalladas.

Prepárate para una migración

Asegúrate de revisar la sección Prepara la migración desde Istio.

Si personalizaste la instalación anterior, necesitas las mismas personalizaciones cuando actualices a una versión nueva de Anthos Service Mesh o si migras desde Istio. Si personalizaste la instalación agregando la marca --set values a istioctl install, debes agregar esa configuración a un archivo YAML IstioOperator, denominado archivo de superposición. Especifica el archivo de superposición mediante la opción --custom_overlay con el nombre del archivo cuando ejecutes la secuencia de comandos. La secuencia de comandos pasa el archivo de superposición a istioctl install.

La secuencia de comandos sigue el proceso de actualización de revisión (denominado actualización “canary” en la documentación de Istio). Con una actualización basada en revisión, la secuencia de comandos instala una versión nueva del plano de control junto con el plano de control existente. Cuando se instala la versión nueva, la secuencia de comandos incluye una etiqueta revision que identifica el nuevo plano de control.

Luego, migras a la versión nueva mediante la configuración de la misma etiqueta revision en tus cargas de trabajo y la ejecución de un reinicio progresivo para volver a incorporar los proxies a fin de que usen la versión y la configuración nuevas de Anthos Service Mesh. Con este enfoque, puedes supervisar el efecto de la actualización en un porcentaje pequeño de tus cargas de trabajo. Después de probar la aplicación, puedes migrar todo el tráfico a la versión nueva. Este enfoque es mucho más seguro que realizar una actualización in situ donde los nuevos componentes del plano de control reemplazan la versión anterior.

Migra a Anthos Service Mesh

  1. Configura las opciones y especifica las marcas para ejecutar la secuencia de comandos. Siempre debes incluir las siguientes opciones: project_id, cluster_name, cluster_location, mode y ca. Para el ca, tienes las siguientes opciones:

    • --ca mesh_ca: Especifica esta opción cuando quieras migrar a la autoridad certificadora de Anthos Service Mesh (CA de Mesh).

    • --ca citadel: Especifica esta opción cuando desees seguir usando la CA de Istio.

    Para obtener más información, consulta Elige una autoridad certificadora.

    Nota: Puedes usar --mode install para una migración desde Istio. Cuando usas --mode install en lugar de --mode migrate, install_asm permite la migración sin importar qué versión del plano de control tenga el clúster. La marca migrate solo permite una migración de la versión secundaria anterior o una versión de parche anterior.

    En la siguiente sección, se proporcionan ejemplos típicos de la ejecución de la secuencia de comandos. Para obtener una descripción completa de los argumentos de la secuencia de comandos, consulta Opción y marcas.

  2. Para completar la configuración de Anthos Service Mesh, debes habilitar la inyección automática del archivo adicional y, luego, implementar o volver a implementar las cargas de trabajo.

Ejemplos

En esta sección, se muestran ejemplos a fin de ejecutar la secuencia de comandos para una migración de Istio con algunos argumentos adicionales que pueden resultarte útiles. Consulta la barra de navegación de la derecha para ver una lista de los ejemplos.

Solo validación

En el siguiente ejemplo, se muestra la ejecución de la secuencia de comandos con la opción --only_validate. Con esta opción, la secuencia de comandos no realiza ningún cambio en tu proyecto o clúster y no instala Anthos Service Mesh. Cuando especificas --only_validate, la secuencia de comandos falla si incluyes alguna de las marcas --enable_*.

La secuencia de comandos valida lo siguiente:

  • Tu entorno tiene las herramientas necesarias.
  • Tienes el permiso requerido en el proyecto especificado.
  • El clúster cumple con los requisitos mínimos.
  • El proyecto tiene habilitadas todas las API de Google requeridas.

De forma predeterminada, la secuencia de comandos descarga y extrae el archivo de instalación, y descarga el paquete de configuración asm de GitHub a un directorio temporal. Antes de salir, la secuencia de comandos genera un mensaje que proporciona el nombre del directorio temporal. Puedes especificar un directorio para las descargas con la opción --output_dir DIR_PATH. La opción --output_dir te permite usar la herramienta de línea de comandos de istioctl si la necesitas. Además, los archivos de configuración para habilitar funciones opcionales se incluyen en el directorio asm/istio/options.

Ejecuta el siguiente comando para validar tu configuración y descargar el archivo de instalación, y el paquete asm en el directorio OUTPUT_DIR:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --output_dir DIR_PATH \
  --only_validate

Si la operación es exitosa, la secuencia de comandos mostrará lo siguiente:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Si una de las pruebas no pasa la validación, la secuencia de comandos mostrará un mensaje de error. Por ejemplo, si tu proyecto no tiene habilitadas todas las API de Google necesarias, verás el siguiente error:

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Si recibiste un mensaje de error que indica que debes ejecutar la secuencia de comandos con una marca de habilitación, tienes las siguientes opciones:

  • Incluye la marca específica del mensaje de error o la marca --enable_all cuando ejecutes la secuencia de comandos para realizar la instalación real (es decir, sin --only_validate).

  • Si lo prefieres, puedes actualizar tu proyecto y clúster antes de ejecutar la secuencia de comandos como se describe en Configuración para la instalación de Anthos Service Mesh en GKE.

Ten en cuenta que install_asm no permite ninguna marca de habilitación con --only_validate.

Migra a la CA de Mesh con tiempo de inactividad

La migración a la autoridad certificadora de Anthos Service Mesh (CA de Mesh) desde la CA de Istio requiere la migración de la raíz de confianza. Durante la migración, algunas cargas de trabajo usan el certificado raíz anterior, mientras que otras usan el nuevo certificado raíz de la CA de Mesh. Las cargas de trabajo que usan certificados firmados por diferentes certificados raíz no pueden autenticarse entre sí. El clúster completo solo se recupera por completo cuando el plano de control y todas las cargas de trabajo en todos los espacios de nombres se vuelven a implementar con el nuevo certificado de CA raíz.

Si puedes programar el tiempo de inactividad, esta es la forma más fácil de migrar a Anthos Service Mesh con la CA de Mesh. En el siguiente ejemplo, se muestran opciones de línea de comandos típicas para migrar a la CA de Mesh.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir OUTPUT_DIRECTORY
  --enable_all

Migra a la CA de Mesh con poco o ningún tiempo de inactividad

Si no puedes programar el tiempo de inactividad para la migración a la CA de Mesh, aún hay una ruta de migración a la CA de Mesh, pero se requieren pasos adicionales. Para obtener más información, consulta Migra a la CA de Mesh.

Migra, pero continúa usando la CA de Istio

Si necesitas una CA personalizada, puedes seguir usando la CA de Istio después de migrar a Anthos Service Mesh. En el siguiente comando, se ejecuta la secuencia de comandos para una migración y se habilita la CA de Istio. La opción --ca citadel se llama “citadel”, ya que ese era el nombre del componente de CA antes de que se incorporarán todos los componentes de Istio en istiod. Esta migración solo implementa el plano de control y la puerta de enlace de entrada. No cambia la CA raíz ni afecta a las cargas de trabajo existentes.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all

Migra con un archivo de superposición

Un archivo de superposición es un archivo YAML que contiene un recurso personalizado (CR) IstioOperator que pasas a install_asm para configurar el plano de control. Puedes anular la configuración predeterminada del plano de control y habilitar una función opcional si pasas el archivo YAML a install_asm. Puedes agregar capas a más superposiciones, y cada archivo superpuesto anula la configuración de las capas anteriores.

Si especificas más de un CR en un archivo YAML, install_asm divide el archivo en varios archivos YAML temporales, uno para cada CR. La secuencia de comandos divide los CR en archivos separados porque istioctl install solo aplica el primer CR en un archivo YAML que contiene más de un CR.

En el siguiente ejemplo, se realiza una migración y se incluye un archivo de superposición para personalizar la configuración del plano de control. En el siguiente comando, cambia OVERLAY_FILE por el nombre del archivo YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Migra con una opción

En el siguiente ejemplo, se realiza una migración y se incluye el archivo egressgateways.yaml del paquete asm, lo que habilita una puerta de enlace de salida. Ten en cuenta que no incluyes la extensión .yaml. La secuencia de comandos recupera el archivo para que no tengas que descargar primero el paquete asm.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --option egressgateways

Puedes usar --option para habilitar una función opcional. Si necesitas realizar modificaciones en cualquiera de los archivos del directorio asm/istio/options en el paquete asm, descarga el paquete asm, realiza los cambios y, luego, incluye el archivo --custom_overlay.

Para descargar el paquete asm en el directorio de trabajo actual, de manera que puedas realizar modificaciones en los archivos, haz lo siguiente:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm

Si ejecutaste el ejemplo Solo validar donde especificaste la opción --output_dir, los archivos de configuración están en el directorio de salida especificado en asm/istio/options.

Implementa y vuelve a implementar las cargas de trabajo

La instalación no estará completa hasta que habilites la inserción automática de proxy de sidecar (inserción automática). Las migraciones de OSS Istio y las actualizaciones siguen el proceso de actualización basado en la revisión (denominado “actualizaciones canary” en la documentación de Istio). Con una actualización basada en revisiones, la versión nueva del plano de control se instala junto con el plano de control existente. Luego, transfiere algunas de tus cargas de trabajo a la versión nueva, lo que te permite supervisar el efecto de la actualización con un pequeño porcentaje de las cargas de trabajo antes de migrar todo el tráfico a la versión nueva.

La secuencia de comandos establece una etiqueta de revisión en el formato istio.io/rev=asm-1106-2 en istiod. Para habilitar la inserción automática, agrega una etiqueta de revisión coincidente a tus espacios de nombres. El webhook de inserción de sidecar usa la etiqueta de revisión para asociar los sidecars insertados con una revisión istiod particular. Después de agregar la etiqueta, reinicia los Pods en el espacio de nombres para que se inserten los sidecars.

  1. Obtén la etiqueta de revisión que se encuentra en istiod y la istio-ingressgateway.

    kubectl get pod -n istio-system -L istio.io/rev

    El resultado del comando es similar al siguiente: 

    NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

    1. En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la versión nueva. En este ejemplo, el valor es asm-1106-2.

    2. Observa también el valor en la etiqueta de revisión de la versión istiod anterior. Necesitarás esto para borrar la versión anterior de istiod cuando termines de migrar las cargas de trabajo a la versión nueva. En el resultado de ejemplo, el valor de la etiqueta de revisión para la versión anterior es asm-198-3.

  2. Cambia istio-ingressgateway a la revisión nueva. En el siguiente comando, cambia REVISION por el valor que coincide con la etiqueta de revisión de la versión nueva.

    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    Resultado esperado: service/istio-ingressgateway patched

  3. Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, cambia REVISION por el valor que coincide con la nueva revisión de istiod.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

    Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection antes. Debido a que la inserción automática falla si un espacio de nombres tiene tanto la istio-injection como la etiqueta de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la acción de quitar la etiqueta istio-injection.

  4. Reinicia los Pods para activar la reinserción:

    kubectl rollout restart deployment -n NAMESPACE

  5. Verifica que tus pods estén configurados para apuntar a la nueva versión de istiod.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  6. Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.

  7. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.

  8. Si estás seguro de que tu aplicación funciona como se esperaba, continúa con los pasos para completar la transición a la versión nueva de istiod. Si hay un problema con tu aplicación, sigue los pasos para revertirla.

    Completa la transición

    Si estás seguro de que tu aplicación funciona como se esperaba, quita el plano de control anterior para completar la transición a la nueva versión.

    1. Cambia al directorio en el que se encuentran los archivos del repositorio de GitHub anthos-service-mesh.

    2. Configura el webhook de validación para usar el plano de control nuevo.

      kubectl apply -f asm/istio/istiod-service.yaml

    3. Borra el Deployment istio-ingressgateway anterior. El comando que debes ejecutar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh:

      Migra

      Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión.

      kubectl delete deploy/istio-ingressgateway -n istio-system

      Actualizar

      Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, reemplaza OLD_REVISION por la etiqueta de revisión para la versión anterior de istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. Borra la versión anterior de istiod. El comando que debes usar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh.

      Migra

      Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

      Actualizar

      Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, asegúrate de que OLD_REVISION coincida con la etiqueta de revisión de la versión anterior de istiod.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true

    5. Quita la versión anterior de la configuración IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      El resultado esperado es similar al siguiente:

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    Revertir

    Si encontraste un problema cuando probaste tu aplicación con la versión nueva de istiod, sigue estos pasos para realizar una reversión a la versión anterior:

    1. Vuelve a la versión anterior de la istio-ingressgateway. En el siguiente comando, reemplaza OLD_REVISION por la revisión anterior.

      kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'

    2. Vuelve a etiquetar tu espacio de nombres para habilitar la inserción automática con la versión anterior de istiod. El comando que uses depende de si usaste una etiqueta de revisión o istio-injection=enabled con la versión anterior.

      • Si usaste una etiqueta de revisión para la inserción automática, haz lo siguiente:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      • Si usaste istio-injection=enabled:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

      Resultado esperado:

      namespace/NAMESPACE labeled

    3. Confirma que la etiqueta de revisión en el espacio de nombres coincida con la etiqueta de revisión en la versión anterior de istiod:

      kubectl get ns NAMESPACE --show-labels

    4. Reinicia los Pods para activar la reinserción a fin de que los proxies tengan la versión previa:

      kubectl rollout restart deployment -n NAMESPACE

    5. Quita el Deployment istio-ingressgateway nuevo. Asegúrate de que el valor de REVISION en el siguiente comando sea correcto.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true

    6. Quita la versión nueva de istiod. Asegúrate de que el valor de REVISION en el siguiente comando sea correcto.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

    7. Quita la versión nueva de la configuración IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system

      El resultado esperado es similar al siguiente:

      istiooperator.install.istio.io "installed-state-REVISION" deleted

    8. Si no incluiste la marca --disable_canonical_service, la secuencia de comandos habilitó el controlador del servicio canónico. Recomendamos que lo habilites, pero si necesitas inhabilitarlo, consulta Habilita o inhabilita el controlador de servicio canónico.

Visualiza los paneles de Anthos Service Mesh

Después de implementar las cargas de trabajo en el clúster con los proxies de sidecar incorporados, puedes explorar las páginas de Anthos Service Mesh en la consola de Google Cloud para ver todas las funciones de observabilidad que ofrece Anthos Service Mesh. Ten en cuenta que los datos de telemetría toman uno o dos minutos en aparecer en la consola de Google Cloud después de implementar las cargas de trabajo.

El acceso a Anthos Service Mesh en la consola de Google Cloud se controla mediante la Administración de identidades y accesos (IAM). Para acceder a las páginas de Anthos Service Mesh, el propietario del proyecto debe otorgar a los usuarios la función de editor o visualizador del proyecto, o los roles más restrictivas que se describen en Controla el acceso a Anthos Service Mesh en la consola de Google Cloud.

  1. En la consola de Google Cloud, ve a Anthos Service Mesh.

    Ir a Anthos Service Mesh

  2. Selecciona el proyecto de Google Cloud de la lista desplegable de la barra de menú.

  3. Si tienes más de una malla de servicios, selecciona la malla en la lista desplegable Malla de servicios.

Para obtener más información, consulta Explora Anthos Service Mesh en la consola de Google Cloud.

Además de las páginas de Anthos Service Mesh, las métricas relacionadas con tus servicios (como la cantidad de solicitudes que recibe un servicio específico) se envían a Cloud Monitoring, donde aparecen en el Explorador de métricas.

Para ver las métricas, sigue estos pasos:

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

    Ir a Monitoring

  2. Selecciona Recursos > Explorador de métricas.

Para obtener una lista completa de las métricas, consulta Métricas de Istio en la documentación de Cloud Monitoring.

¿Qué sigue?