Anthos Service Mesh 1.10 llegó al final del ciclo de vida y ya no es compatible. Consulta Actualiza desde versiones anteriores.

Consulta la documentación más reciente o selecciona otra versión disponible:

Versiones disponibles

Migra de Istio 1.7 o posterior a la CA de Mesh y Anthos Service Mesh

En este documento, se describe cómo los administradores de Google Kubernetes Engine (GKE) pueden instalar Anthos Service Mesh y migrar las cargas de trabajo que se ejecutan actualmente con una malla de servicios de Istio. La configuración implementada de Anthos Service Mesh incluye Cloud Monitoring para telemetría y la autoridad certificadora de Anthos Service Mesh (CA de Mesh) a fin de administrar certificados y administrados con alta disponibilidad. Las puertas de enlace, los servicios virtuales y otras opciones de configuración de malla que definen la topología de la malla se conservan en la migración.

Este proceso abarca la instalación de un solo clúster. Para una instalación de malla de varios clústeres, consulta Configura una malla de varios clústeres en GKE, que incluye pasos a fin de agregar clústeres a Anthos Service Mesh luego de la instalación.

Para completar los pasos de este documento, debes usar Istio 1.7 o una versión posterior con un clúster de GKE. Anthos Service Mesh no admite Helm para la instalación ni la configuración. Recomendamos que los administradores de mallas usen la API de IstioOperator para la configuración de la malla. Este proceso puede generar tiempo de inactividad para tu aplicación mientras cambias de autoridad certificadora, por lo que te recomendamos que realices este proceso durante un período de mantenimiento programado.

Anthos Service Mesh usa las mismas API de Istio y Envoy para configurar la malla, por lo que no es necesario realizar cambios en los recursos existentes.

Estas son algunas diferencias de implementación después de la migración:

El plano de control de Istio se reemplaza por un plano de control de Anthos Service Mesh.
Se quita la autoridad certificadora de Citadel y un servicio de CA de Mesh de Google Cloud administra los certificados.
La telemetría se envía a Cloud Logging y Cloud Monitoring. Los paneles y la administración de SLO están disponibles en la consola de Google Cloud.
Si tienes un recurso IstioOperator personalizado, la secuencia de comandos puede tomar eso como una entrada.
Tu instalación de Istio de código abierto (versión 1.7 o posterior) se migra a la versión 1.10 de Anthos Service Mesh con la CA de Mesh. Si tienes una versión diferente de Istio o necesitas una versión diferente de Anthos Service Mesh, o si deseas implementar Anthos Service Mesh con un plano de control administrado por Google, consulta Prepárate para la migración desde Istio.

Requisitos previos

Para completar esta guía, se requieren los siguientes requisitos:

Tienes un clúster de GKE con la versión de Istio 1.7 o posterior instalada. Si no tienes un clúster de GKE, o si primero deseas probar esta guía en un clúster nuevo (de prueba), sigue los pasos del Apéndice a fin de crear un clúster de GKE nuevo con la versión 1.7 o posterior de Istio implementada con una aplicación de prueba
Usa Cloud Shell para realizar los pasos de esta guía porque esta se prueba en Cloud Shell.

Objetivos

En esta guía, elegirás una ruta de migración. Puedes elegir entre una ruta con secuencia de comandos de un paso o una migración con secuencia de comandos paso a paso.

Para obtener más información, consulta Elige una ruta de migración.

Para obtener respuestas a las preguntas frecuentes sobre esta migración, consulta Preguntas frecuentes sobre la migración de Istio 1.7 o posterior a la CA de Mesh y Anthos Service Mesh.

Antes de comenzar

Para esta guía, necesitas acceso de administrador a un clúster de GKE con Istio instalado. Para observar cómo se comporta tu aplicación durante el proceso de migración, te recomendamos que primero realices este proceso con un clúster en un entorno de desarrollo o etapa de pruebas.

Anthos Service Mesh tiene los siguientes requisitos. Puedes realizarlas de forma manual o permitir que las herramientas proporcionadas habiliten las dependencias en tu nombre durante el proceso previo a la instalación.

Habilita las siguientes API de Google Cloud:
- container.googleapis.com
- meshca.googleapis.com
- meshconfig.googleapis.com
- gkehub.googleapis.com
- stackdriver.googleapis.com
Habilita Workload Identity y Stackdriver para el clúster de GKE.
Etiqueta el clúster para habilitar la interfaz de usuario de servicio.
Obtén los derechos de administrador del clúster en el clúster de Kubernetes
Registra tu clúster en una flota.
Habilita la función servicemesh en la flota.

Configure su entorno

Para configurar tu entorno, sigue estos pasos:

En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell

En la parte inferior 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 ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Nota: La secuencia de comandos no funciona en macOS. La secuencia de comandos se probó solo en Cloud Shell. La secuencia de comandos requiere las siguientes aplicaciones (que se incluyen de forma predeterminada en Cloud Shell):
- gcloud (versión 346.0.0 y posteriores)
- kubectl (versión 1.21 y posteriores del cliente)
- jq
- sed
- curl
- awk

Crea las variables de entorno que se usan en esta guía:

export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE

Crea una carpeta WORKDIR:

mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`

Crea un archivo KUBECONFIG para esta guía:

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

Conéctate a tu clúster de GKE:

Clústeres zonales

gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --zone ${CLUSTER_LOCATION}

Clústeres regionales

gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --region ${CLUSTER_LOCATION}

Descarga la secuencia de comandos de migración:

curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
chmod +x ./migrate-to-asm

Elige una ruta de migración

Puedes elegir una de las dos rutas de acceso que se migrarán a Anthos Service Mesh. Elige solo una de estas dos estrategias y, luego, continúa con esa sección:

Migración en un solo paso a Anthos Service Mesh. Como se sugiere en el nombre, puedes realizar todos los pasos necesarios para migrar a Anthos Service Mesh mediante un solo comando. Esto puede ser beneficioso si tienes muchos clústeres y necesitas una forma rápida y fácil de actualizarlos a Anthos Service Mesh. Sin embargo, este método puede provocar un tiempo de inactividad de la aplicación.
Migración paso a paso a Anthos Service Mesh. Este método te proporciona más control sobre cada paso y te ayuda a comprender con exactitud lo que se necesita para migrar a Anthos Service Mesh.

Migración en un solo paso a Anthos Service Mesh

En esta sección, migrarás la instalación actual de Istio versión 1.7 (o posterior) a la versión 1.10 de Anthos Service Mesh. En esta sección, puedes realizar la migración mediante la ejecución de un solo paso. Si deseas realizar la migración mediante la ejecución de una serie de pasos, consulta la sección Migración paso a paso a Anthos Service Mesh.

Para migrar a Anthos Service Mesh, ejecuta el siguiente comando. Con cualquier comando, puedes usar la marca --dry-run para imprimir comandos en lugar de ejecutarlos, o puedes usar la marca --verbose a fin de imprimir comandos a medida que la secuencia de comandos los ejecuta. Si ya configuraste dependencias, como se indica en la sección Antes de comenzar, puedes omitir la marca --enable-dependencies.

Sin recurso personalizado

No uses un recurso IstioOperator personalizado:

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

Usa un recurso personalizado

Usa un recurso IstioOperator personalizado:

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

Este comando realiza los siguientes pasos:

Garantiza que la versión de Istio sea la versión 1.7 o posterior
Habilita Workload Identity en el clúster. Se requiere Workload Identity para la CA de Mesh. No es necesario que habilites el servidor de metadatos de GKE en los grupos de nodos existentes.
Habilita las API necesarias para Anthos Service Mesh.
Registra el clúster en una flota.
Actualiza el clúster con las etiquetas necesarias.
Evalúa si un plano de control administrado por Google es mejor para el clúster especificado.
Implementa Anthos Service Mesh con la configuración óptima del plano de control.
Vuelve a etiquetar todos los espacios de nombres habilitados para Istio con la etiqueta requerida de Anthos Service Mesh.
Reinicia las cargas de trabajo en todos los espacios de nombres habilitados de Anthos Service Mesh para que las cargas de trabajo obtengan los nuevos proxies de Anthos Service Mesh.
Quita el plano de control de Istio.

Migración paso a paso a Anthos Service Mesh

En esta sección, migrarás la instalación de Istio versión 1.7 (o posterior) a la versión 1.10 de Anthos Service Mesh. En esta sección, puedes realizar la migración mediante la ejecución de una serie de pasos. Si deseas realizar la migración en un solo paso, consulta la sección Migración de un paso a Anthos Service Mesh.

Los siguientes pasos son necesarios para migrar a Anthos Service Mesh:

Realiza un paso previo a la migración a fin de validar y preparar el clúster y el entorno para la migración a Anthos Service Mesh.
Instala la malla de servicios de Anthos como un plano de control de Canary junto con un plano de control de Istio existente y prepara cargas de trabajo
Prueba las cargas de trabajo en Anthos Service Mesh y vuelve a etiquetar los espacios de nombres para la inserción de sidecar de Anthos Service Mesh.
Accede e inspecciona los paneles de Anthos Service Mesh
Limpia los artefactos de Istio o revierte a una versión existente de Istio.

Realiza el paso previo a la migración

En el paso previo a la migración, se realizan las siguientes acciones:

Valida que la información del proyecto y del clúster sea correcta y que la versión de Istio instalada sea compatible con la migración.
Crea una copia de seguridad de la configuración de la puerta de enlace predeterminada y de las etiquetas de la malla de servicios de Istio actual.
Si se usa la marca --enable-dependencies, habilita las dependencias en tu nombre. de lo contrario, verificará que las dependencias estén habilitadas.

La secuencia de comandos previa a la migración crea una carpeta nueva (o reemplaza una carpeta existente) llamada configuration_backup en el directorio actual.

Para realizar el paso previo a la migración, ejecuta el siguiente comando:

Dependencias

Habilita las dependencias:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

No hay dependencias

No habilites las dependencias:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

El resultado es similar al siguiente:

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Instala Anthos Service Mesh y prepara cargas de trabajo

En este paso, se realiza lo siguiente:

Verifica la presencia de la carpeta configuration_backup y, si no está presente, se anula para garantizar que la herramienta previa a la migración se haya ejecutado de forma correcta.
Instala y configura un plano de control de Anthos Service Mesh según el análisis de la configuración de los clústeres y las mallas.
Usa el recurso IstioOperator personalizado si se proporciona uno. Si tienes puertas de enlace personalizadas o varias puertas de enlace que hayas configurado mediante un recurso IstioOperator, usa el mismo recurso en este paso.

Agrega la marca --no-mcp al comando para omitir el análisis y forzar a la herramienta a instalar un plano de control no administrado que se ejecute con los recursos del clúster.

Cuando instalas Anthos Service Mesh, puedes elegir una de estas tres rutas:

Opción 1: sin un recurso IstioOperator personalizado. Puedes instalar Anthos Service Mesh sin un recurso personalizado. Con esta opción, se instala la configuración predeterminada de Istio y se actualiza el istio-ingressgateway predeterminado en su lugar.
Opción 2: con una opción --no-gateways. Cuando instalas Anthos Service Mesh sin un recurso IstioOperator personalizado, también puedes usar la opción --no-gateways para no actualizar la istio-ingressgateway predeterminada implementada. Si usas esta opción, debes actualizar las puertas de enlace de forma manual luego de la instalación.
Opción 3: con un recurso IstioOperator personalizado Puedes instalar Anthos Service Mesh con un recurso IstioOperator personalizado. Si implementaste Istio con un recurso IstioOperator personalizado, te recomendamos que uses el mismo recurso IstioOperator cuando instales Anthos Service Mesh.

Para instalar Anthos Service Mesh, ejecuta uno de los siguientes comandos:

Opción 1

Actualiza el istio-ingressgateway predeterminado en su lugar:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

Opción 2

No actualices el istio-ingressgateway predeterminado implementado:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

Opción 3

Actualiza las puertas de enlace en su lugar con un recurso IstioOperator personalizado:

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

El resultado es similar al siguiente:

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

Vuelve a incorporar las cargas de trabajo y verifica el comportamiento de la aplicación

El plano de control de Anthos Service Mesh ahora está listo para manejar cargas de trabajo, pero el plano de control de Istio existente todavía administra las cargas de trabajo existentes. A fin de migrar esas cargas de trabajo, debes volver a etiquetar los espacios de nombres de Kubernetes que están etiquetados actualmente para la inyección de Istio con la etiqueta de revisión de Anthos Service Mesh. Luego, debes reiniciar las cargas de trabajo en esos espacios de nombres. Puedes hacerlo de forma manual (consulta la Nota en el paso 1) o en un paso mediante la herramienta.

Este es el paso para cambiar la etiqueta:

Encuentra todos los espacios de nombres que actualmente usan una etiqueta de inyección de Istio.
Vuelve a etiquetar esos espacios de nombres con istio.io/rev=asm-1102-2.
Reinicia las cargas de trabajo en el espacio de nombres.

Para volver a inyectar las cargas de trabajo, sigue estos pasos:

Vuelve a etiquetar todos los espacios de nombres habilitados para Istio y reinicia las cargas de trabajo mediante la ejecución del siguiente comando:

 ./migrate-to-asm relabel \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

El resultado es similar al siguiente:

migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for $CLUSTER_NAME.
migrate-to-asm:
migrate-to-asm: Verifying connectivity (20s)...
migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
******
migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with migration? (Y/n)Y
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!

Nota: Si no usaste el comando del paso anterior, puedes volver a etiquetar y reiniciar manualmente las cargas de trabajo en cada espacio de nombres uno por uno mediante la ejecución del siguiente comando:

export NAMESPACE=NAMESPACE_NAME
kubectl label namespace $NAMESPACE istio-injection- istio.io/rev=asm-1102-2 --overwrite

kubectl rollout restart deployment -n $NAMESPACE

Espera hasta que se reinicien todas las implementaciones y, luego, verifica la versión del plano de datos mediante la ejecución del siguiente comando:
```
istioctl version
```
El resultado es similar al siguiente:
```
client version: 1.8.0
pilot version: 1.9.5
istiod version: 1.10.2-asm.2
data plane version: 1.10.2-asm.2 (14 proxies)
```
Verifica que las aplicaciones funcionen de forma correcta después del reinicio.

Accede a los paneles de Anthos Service Mesh

En esta sección, ve a los paneles de Anthos Service Mesh y asegúrate de recibir los indicadores de oro para todos los objetos Service. También deberías poder ver la topología de tu aplicación.

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

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

Finaliza la migración

Antes de finalizar la migración, asegúrate de que todas las aplicaciones funcionen de forma correcta. Después de finalizar la migración, no puedes revertir a la versión existente de Istio. Para finalizar la migración, realiza los siguientes pasos:

Valida que todos los proxies en ejecución del clúster usen Anthos Service Mesh.
Quita los componentes de Istio sin usar del clúster. Este paso es irreversible.

Para finalizar la migración a Anthos Service Mesh, ejecuta el siguiente comando:

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

El resultado es similar al siguiente:

migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

Revierte a una versión existente de Istio

Ejecuta el paso de reversión para volver a etiquetar los espacios de nombres con la etiqueta de inyección anterior de Istio, reiniciar las cargas de trabajo y revertir los cambios de la puerta de enlace. Luego, la herramienta quita cualquier componente de Anthos Service Mesh implementado en el clúster.

Debes revertir manualmente cualquier dependencia habilitada en este paso.

Para revertir a Istio, ejecuta el siguiente comando:

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

El resultado es similar al siguiente:

migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

Apéndice

Crea un clúster de GKE con Istio instalado:

En esta sección, implementarás un clúster de GKE con Istio habilitado. Puedes usar un clúster de GKE privado o no privado. Los clústeres de GKE privados deben tener un extremo de GKE público. También verificarás la instalación de Istio.

Si ya tienes un clúster de GKE existente, puedes omitir el paso de creación y asegurarte de tener acceso al clúster que usa el archivo KUBECONFIG. El contexto que usa esta guía se define en la variable ${CLUSTER_1_CTX}. Puedes configurar el contexto de tu clúster para esta variable.

Crea las variables de entorno que se usan en esta guía:

# Enter your project ID
export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5

Crea un clúster de GKE con Istio habilitado (este es un clúster privado). También puedes realizar estos pasos con un clúster de GKE no privado.

Clústeres zonales

gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --zone ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

Clústeres regionales

gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --region ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

Confirma que el clúster sea RUNNING:

 gcloud container clusters list

El resultado es similar al siguiente:

NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING

Conéctese al clúster:

Clústeres zonales

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION}

Clústeres regionales

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --region ${CLUSTER_LOCATION}

Recuerda anular la configuración de la variable KUBECONFIG al final.

Instala Istio

En esta sección, implementarás la versión 1.7 de Istio en el clúster de GKE.

Descarga Istio:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -

Instala Istio mediante la herramienta de línea de comandos de istioctl. Elige una de las siguientes opciones:

Opción 1: sin un recurso IstioOperator personalizado
Opción 2: con un recurso IstioOperator personalizado

Opción 1

Sin un recurso IstioOperator personalizado:

./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y

El resultado es similar al siguiente:

✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

Opción 2

Con un recurso IstioOperator personalizado:

cat <<EOF > istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 name: istio-operator
spec:
 components:
   base:
     enabled: true
   ingressGateways:
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         metrics:
         - resource:
             name: cpu
             targetAverageUtilization: 80
           type: Resource
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     name: istio-ingressgateway
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     label:
       istio: istio-api-ingressgateway
     name: istio-api-ingressgateway
 meshConfig:
   defaultConfig:
     tracing:
       sampling: 1
       zipkin:
         address: jaeger-collector.observability.svc.cluster.local:9411
   enableTracing: true
EOF

./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y

El resultado es similar al siguiente:

✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

Asegúrate de que los servicios y Pods de Istio estén implementados y en ejecución:

kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods

El resultado es similar al siguiente:

Opción 1

Sin un recurso IstioOperator personalizado:

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s

NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s

Opción 2

Con un recurso IstioOperator personalizado:

NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s

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 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 Instala Anthos Service Mesh y prepara las cargas de trabajo.

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_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique

Espera hasta que todos los objetos Deployment estén listos:

kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

Asegúrate de que haya dos contenedores por pod: el contenedor de la aplicación y el proxy de sidecar de Istio que Istio inserta de forma automática en el Pod:

kubectl --context=${CLUSTER_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

También puedes verificar la versión del proxy de sidecar de Envoy desde cualquiera de los Pods para confirmar que tienes implementados los proxies de Envoy de la versión 1.4 de Istio:

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

El resultado es similar al siguiente:

"docker.io/istio/proxyv2:1.7.4"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

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_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

¿Qué sigue?

Para obtener respuestas a las preguntas frecuentes sobre esta migración, consulta Preguntas frecuentes sobre la migración de Istio 1.7 o posterior a la CA de Mesh y Anthos Service Mesh.