Estás viendo la documentación de Anthos Service Mesh 1.7. Consulta la documentación más reciente o selecciona otra versión disponible:

Prepárate para la migración desde Istio

La migración de Istio a Anthos Service Mesh requiere un poco de planificación. En esta página, se proporciona información que te ayudará a prepararte para la migración.

Revisa los perfiles

Los perfiles de configuración que proporciona Anthos Service Mesh son diferentes a Istio de código abierto. Cuando instalas Anthos Service Mesh, debes usar un perfil de configuración adecuado para tu entorno:

  • asm-gcp: Usa este perfil para las instalaciones de GKE en una malla que contiene un solo clúster o varios clústeres que se encuentran en el mismo proyecto de Cloud.

  • asm-gcp-multiproject beta: Usa este perfil para las instalaciones en GKE con clústeres en diferentes proyectos de Cloud.

  • asm-multicloud: Usa este perfil para las instalaciones en los siguientes entornos:

    • clústeres de Anthos alojados en VMware
    • Clústeres de Anthos en AWS
    • Amazon Elastic Kubernetes Service (Amazon EKS)
    • Microsoft Azure Kubernetes Service (Microsoft AKS)

Las características compatibles de Anthos Service Mesh varían entre los perfiles. Revisa las funciones compatibles del perfil que es adecuado para tu configuración.

Compara perfiles

Puedes comparar el perfil de configuración que usaste para instalar Istio con el perfil de Anthos Service Mesh que planeas usar:

  1. Sigue los pasos que se indican en Cómo descargar el archivo de instalación para descargar los archivos de instalación y firma, extraer el contenido y configurar la ruta de acceso a fin de que use la versión de istioctl del archivo de descarga.

  2. Genera un manifiesto para el perfil de Anthos Service Mesh que planeas usar:

    istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
  3. Ubica el perfil que usaste para instalar Istio. Debido a que los perfiles pueden cambiar entre las versiones de Istio, necesitas el perfil del paquete de instalación que coincida con tu versión de Istio.

  4. Genera un manifiesto para el perfil que usaste a fin de instalar Istio:

    istioctl manifest generate -f ISTIO_PROFILE > b.yaml
  5. Compara los manifiestos:

    istioctl manifest diff a.yaml b.yaml
    

Prepara archivos de configuración

Si personalizaste la instalación de Istio, necesitas usar las mismas personalizaciones cuando migras a Anthos Service Mesh. Si personalizaste la instalación mediante el agregado de la marca --set values, te recomendamos que agregues esa configuración a un archivo de configuración IstioOperator. Para especificar el archivo de configuración, usa la marca -f con el archivo de configuración cuando ejecutes el comando istioctl install.

Elige una autoridad certificada

Puedes continuar con el uso de Citadel (ahora incorporado en istiod) como la autoridad certificada (CA) para emitir certificados de TLS mutua (mTLS), o puedes optar por migrar a la autoridad certificada de Anthos Service Mesh (CA de Mesh).

Por lo general, recomendamos que uses CA de Mesh por los siguientes motivos:

  • La CA de Mesh es un servicio altamente confiable y escalable que está optimizado para cargas de trabajo escaladas de forma dinámica en Google Cloud.
  • Con la CA de Mesh, Google administra la seguridad y la disponibilidad del backend de CA.
  • La CA de Mesh te permite tener una sola raíz de confianza entre clústeres.

Sin embargo, hay casos en los que podrías considerar usar Citadel, como los que se mencionan a continuación:

  • Si tienes una CA personalizada.
  • No puedes programar el tiempo de inactividad de la migración para la CA de Mesh. Si bien recomendamos que uses la CA de Mesh, debes programar el tiempo de inactividad para la migración, ya que el tráfico de mTLS fallará hasta que reinicies todos los pods en todos los espacios de nombres.

Revisa el proceso de migración

Para migrar desde Istio, sigue el proceso de actualización del plano de control dual (denominado actualizaciones canary en la documentación de Istio). Con la actualización del plano de control doble, instalas una versión nueva del plano de control junto con el plano de control existente. Cuando instales la versión nueva, incluye una etiqueta revision que identifique la versión del plano de control nuevo. Cada revisión es una implementación completa del plano de control de Anthos Service Mesh con sus propios objetos Deployment y Service.

Luego, debes migrar a la versión nueva mediante la configuración de la misma etiqueta revision en tus cargas de trabajo para apuntar al nuevo plano de control y realizar un reinicio progresivo a fin de volver a insertar los proxies con la nueva versión 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 en la que un plano de control nuevo reemplaza a la versión anterior.

A menos que tengas un balanceador de cargas o una configuración de router para las implementaciones azul-verde, te recomendamos probar la migración y reiniciar los pods en un entorno de etapa de pruebas a fin de verificar que tus servicios puedan controlar cualquier posible interrupción del tráfico.