En esta página, se explica cómo ejecutar la secuencia de comandos para migrar de Istio 1.7 or 1.8 a Anthos Service Mesh 1.8.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.
Para una malla de varios clústeres en la que los clústeres se encuentran en diferentes proyectos, consulta Instalación y migración de varios clústeres o varios proyectos para GKE.
Esta página permite migrar de Istio a Anthos Service Mesh. Si deseas obtener información a fin de ejecutar la secuencia de comandos para las nuevas instalaciones y actualizaciones, consulta los siguientes vínculos:
Antes de comenzar
Antes de comenzar la migración, asegúrate de tener lo siguiente:
- Revisar los requisitos
- Elegir una autoridad certificadora
- Registrar tu clúster
- Instalar las herramientas necesarias
- Descargar la secuencia de comandos
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 Anthos Service Mesh
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
ymode
.En la siguiente sección, se proporcionan ejemplos típicos de la ejecución de la secuencia de comandos. Consulta la barra de navegación de la derecha para ver una lista de los ejemplos. Para obtener una descripción completa de los argumentos de la secuencia de comandos, consulta Opción y marcas.
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 para ejecutar la secuencia de comandos para una migración 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 existente 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 migrate \ --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 sobre la necesidad de ejecutar la secuencia de comandos con una marca de habilitación, puedes incluir la marca específica del mensaje de error o la marca --enable_all
cuando se ejecuta la secuencia de comandos sin --only_validate
. Si lo prefieres, puedes actualizar tu proyecto y clúster antes de ejecutar la secuencia de comandos como se describe en las secciones Configura tu proyecto y Configura tu clúster de la guía de instalación de varios proyectos.
Migración desde Istio con Citadel
Si migras desde Istio con Citadel como la CA, puedes continuar usando Citadel después de migrar a Anthos Service Mesh. El siguiente comando ejecuta la secuencia de comandos para una migración y habilita Citadel como la CA. Esta migración solo implementa el plano de control. 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 migrate \ --ca citadel \ --option revisioned-istio-ingressgateway \ --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 migrate \ --ca citadel \ --enable_all \ --option revisioned-istio-ingressgateway \ --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 migrate \ --ca citadel \ --enable_all \ --option revisioned-istio-ingressgateway \ --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.8-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-186-8
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.
La secuencia de comandos crea un Deployment istio-ingressgateway
revisado. Esto te permite controlar el cambio a la nueva versión.
Obtén la etiqueta de revisión que se encuentra en
istiod
y laistio-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-186-8 istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2 1/1 Running 0 20s asm-186-8 istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-178-10 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-178-10 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-186-8 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-186-8
Ten en cuenta si tienes las versiones anteriores y las nuevas de la
istio-ingressgateway
.Si incluiste la opción
revisioned-istio-ingressgateway
cuando actualizaste, se realizó una actualización canary deistio-ingressgateway
. En este caso, el resultado muestra las versiones anteriores y nuevas de laistio-ingressgateway
.Si no incluiste
revisioned-istio-ingressgateway
cuando actualizaste, se realizó una actualización in situ de laistio-ingressgateway
. En este caso, tu resultado solo muestra la versión nueva.
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 esasm-186-8
.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 deistiod
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 esasm-178-10
.
Si tienes las versiones anteriores y nuevas de la
istio-ingressgateway
, cambia laistio-ingressgateway
a la revisión nueva. En el siguiente comando, cambiaREVISION
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
Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta
istio-injection
(si existe). En el siguiente comando, cambiaREVISION
por el valor que coincide con la nueva revisión deistiod
.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 etiquetaistio-injection
antes. Debido a que la inserción automática falla si un espacio de nombres tiene tanto laistio-injection
como la etiqueta de revisión, todos los comandoskubectl label
de la documentación de Anthos Service Mesh incluyen la acción de quitar la etiquetaistio-injection
.Reinicia los Pods para activar la reinserción:
kubectl rollout restart deployment -n NAMESPACE
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
Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.
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.Vuelve a ejecutar el siguiente comando para confirmar si tienes la versión nueva y la anterior de la
istio-ingressgateway
, o solo la nueva. Esto determina cómo controlas la transición a la versión nueva de laistio-ingressgateway
o la reversión a la versión anterior.kubectl get pod -n istio-system -L istio.io/rev
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.
Cambia al directorio en el que se encuentran los archivos del repositorio de GitHub
anthos-service-mesh
.Configura el webhook de validación para usar el plano de control nuevo.
kubectl apply -f asm/istio/istiod-service.yaml
Si tienes las versiones anteriores y nuevas de la
istio-ingressgateway
, borra la implementación anterior deistio-ingressgateway
. 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 deistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
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
istiod
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 deistiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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:Vuelve a la versión anterior de la
istio-ingressgateway
. El comando que uses dependerá de si tienes las versiones anteriores y nuevas de laistio-ingressgateway
o solo la nueva.Si tienes las versiones anteriores y nuevas de la
istio-ingressgateway
, ejecuta el comandokubectl patch service
y reemplazaOLD_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"}]'
Si solo tienes la versión nueva de la
istio-ingressgateway
, ejecuta el comandokubectl rollout undo
.kubectl -n istio-system rollout undo deploy istio-ingressgateway
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 oistio-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
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
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
Si tienes la versión anterior y la nueva de la
istio-ingressgateway
, quita la implementación nueva deistio-ingressgateway
. Asegúrate de que el valor deREVISION
en el siguiente comando sea correcto.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
Quita la versión nueva de
istiod
. Asegúrate de que el valor deREVISION
en el siguiente comando sea correcto.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
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
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.
En la consola de Google Cloud, ve a Anthos Service Mesh.
Selecciona el proyecto de Google Cloud de la lista desplegable de la barra de menú.
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:
En la consola de Google Cloud, ve a la página Monitoring.
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.