Implementa tu migración con la expansión de malla de Istio

Last reviewed 2023-11-02 UTC

En este documento, se describe cómo inicializar y configurar una malla de servicios para respaldar una migración de las características de un centro de datos local a Google Cloud. Se supone que estás familiarizado con la arquitectura de referencia asociada. Está dirigido a administradores, ingenieros y desarrolladores que deseen usar una malla de servicios que enrute el tráfico de manera dinámica al entorno de origen o a Google Cloud.

En esta guía de implementación, se tiene como objetivo ayudarte a migrar desde un entorno que no es de Google Cloud (como un proveedor local o algún otro proveedor de servicios en la nube) a Google Cloud. Estas migraciones tienen una capa de complejidad de red porque debes configurar un canal de comunicación seguro entre el entorno que no es de Google Cloud y el de Google Cloud.

Arquitectura

En el siguiente diagrama, se muestra cómo puedes usar una malla de servicios para enrutar el tráfico a los microservicios que se ejecutan en el entorno de origen o a Google Cloud:

Arquitectura que usa una malla de servicios para enrutar el tráfico a los microservicios que se ejecutan en el entorno heredado o a Google Cloud.

En el diagrama, la puerta de enlace de Istio proporciona una malla de servicios que vincula los microservicios de una aplicación. Google Kubernetes Engine (GKE) actúa como un contenedor para definir los límites de cada microservicio. Para obtener más información, consulta Respalda tu migración con la expansión de malla de Istio.

En esta implementación, usarás el siguiente software:

  • Ubuntu Server y Container-Optimized OS: Son los sistemas operativos que se usan en esta implementación.
  • Docker Engine: Plataforma para ejecutar cargas de trabajo en contenedores.
  • Docker Compose: Es una herramienta para definir y ejecutar apps de Docker.
  • Istio: Es una malla de servicios de código abierto.
  • Kiali: Es una herramienta para visualizar mallas de servicios de Istio.
  • Envoy: Un proxy de sidecar que usa Istio para incluir servicios en la malla.

Carga de trabajo de ejemplo

En esta implementación, debes usar la app Bookinfo, que es una app de microservicios de programa multilenguaje de 4 niveles que muestra información sobre libros. Esta app se diseñó para ejecutarse en Kubernetes, pero debes implementarla en una instancia de Compute Engine mediante Docker y Docker Compose. Con Docker Compose, puedes describir apps de varios contenedores mediante descriptores YAML. Luego, puedes iniciar la app mediante la ejecución de un solo comando.

Aunque esta carga de trabajo de ejemplo ya está en contenedores, este enfoque también se aplica a los servicios que no están en contenedores. En esos casos, puedes agregar una fase de modernización en la que se creen contenedores para los servicios que deseas migrar.

La app Bookinfo tiene cuatro componentes de microservicios:

  • productpage: Llama a los microservicios details, ratings y reviews para propagar la página de información del libro.
  • details: Entrega información sobre libros.
  • reviews: Contiene reseñas de libros.
  • ratings: Muestra información sobre la clasificación de un libro para acompañar la reseña del mismo.

Para demostrar Istio y sus características, los autores de la app Bookinfo y los encargados de su mantenimiento implementaron varias versiones de algunos de estos componentes. En esta implementación, debes implementar solo una versión de cada componente.

Objetivos

  • Inicializar un entorno que simule el centro de datos local.
  • Implementar y probar cargas de trabajo de ejemplo en el centro de datos local.
  • Configurar el entorno de destino en Google Cloud.
  • Migrar la carga de trabajo del centro de datos local al entorno de destino.
  • Probar las cargas de trabajo que se ejecutan en el entorno de destino.
  • Retirar el centro de datos local

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Prepare el entorno

Realizarás la mayoría de los pasos de esta implementación en Cloud Shell.

  1. 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.

  2. En Cloud Shell, verifica la cantidad de espacio libre que tienes:

    df -h
    

    Para completar esta implementación, necesitas alrededor de 200 MB de espacio libre.

  3. Cambia el directorio de trabajo al directorio ${HOME}:

    cd "${HOME}"
    
  4. Clona el repositorio de Git, que contiene las secuencias de comandos y los archivos de manifiesto para implementar y configurar la carga de trabajo de ejemplo:

    git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
    
  5. Autentica con Credenciales predeterminadas de la aplicación (ADC):

    gcloud auth application-default login
    

    El resultado muestra la ruta al archivo Application Default Credentials:

    Credentials saved to file:
    [/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
    

    Toma nota de la ruta del archivo Application Default Credentials. Cualquier biblioteca que solicite ADC usará estas credenciales.

  6. Inicializa las variables de entorno:

    APPLICATION_DEFAULT_CREDENTIALS_PATH=APPLICATION_DEFAULT_CREDENTIALS_PATH
    BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID
    DEFAULT_FOLDER=DEFAULT_FOLDER
    DEFAULT_PROJECT=DEFAULT_PROJECT
    DEFAULT_REGION=DEFAULT_REGION
    DEFAULT_ZONE=DEFAULT_ZONE
    GKE_CLUSTER_NAME=istio-migration
    DEPLOYMENT_DIRECTORY_PATH="$(pwd)"/solutions-istio-mesh-expansion-migration
    ORGANIZATION_ID=ORGANIZATION_ID
    

    Reemplaza lo siguiente:

    • APPLICATION_DEFAULT_CREDENTIALS_PATH: Es la ruta de acceso al archivo ADC del paso anterior.
    • BILLING_ACCOUNT_ID: Es el ID de la cuenta de facturación que se usará.
    • DEFAULT_FOLDER: El ID de la carpeta de Google Cloud en la que se creará el proyecto de Google Cloud. Si deseas que Terraform cree el proyecto de Google Cloud directamente en la organización de Google Cloud, deja esta string vacía.
    • DEFAULT_PROJECT: Es el ID del proyecto de Google Cloud que aprovisionará los recursos para completar esta implementación. Terraform crea este proyecto por ti cuando aprovisiona el entorno.
    • DEFAULT_REGION: Es la región predeterminada en la que se aprovisionan los recursos.
    • DEFAULT_ZONE: Es la zona predeterminada en la que se aprovisionan los recursos.
    • ORGANIZATION_ID: es el ID de la organización de Google Cloud.

Aprovisiona tus entornos

En esta sección, aprovisionarás los siguientes entornos para esta implementación:

  • Un entorno que simule el centro de datos local.
  • Un entorno que simule el destino de la migración.

En esta implementación, ambos entornos se ejecutan en Google Cloud. Este enfoque ayuda a simplificar el proceso de configuración porque solo hay una fase de inicialización. Aprovisionas de forma automática los entornos de origen y destino mediante Terraform.

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Inicializa la configuración del backend de Terraform:

    scripts/init.sh \
    --application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \
    --billing-account-id "${BILLING_ACCOUNT_ID}" \
    --default-folder "${DEFAULT_FOLDER}" \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}" \
    --organization-id "${ORGANIZATION_ID}"
    

    La secuencia de comandos init.sh hace lo siguiente:

    • Genera los descriptores para configurar el backend de Terraform.
    • Inicializa el directorio de trabajo de Terraform.
  3. Cambia el directorio de trabajo al directorio terraform:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
    
  4. Aplica los cambios con Terraform:

    terraform apply
    
  5. Cuando se te solicite, revisa los cambios propuestos y confirma mediante la respuesta yes.

    El resultado es similar al siguiente:

    Apply complete! Resources: 27 added, 0 changed, 0 destroyed
    

Cuando aplicas los cambios propuestos con Terraform, automatizas las siguientes tareas:

  • Crea reglas de firewall para permitir el acceso externo a los microservicios, y a las bases de datos y las comunicaciones entre nodos.
  • Crea y habilita una cuenta de servicio para que la usen las instancias de Compute Engine. Te recomendamos que limites la cuenta de servicio a los permisos de acceso y roles necesarios para ejecutar la app. En esta implementación, la cuenta de servicio para las instancias de Compute Engine solo requiere el rol Visualizador de Compute (roles/compute.viewer). Este rol proporciona acceso de solo lectura a los recursos de Compute Engine.
  • Aprovisionar y configurar una instancia de Compute Engine para alojar las cargas de trabajo que se migrarán, como un entorno de origen Cuando configuras la instancia de Compute Engine, se proporciona una secuencia de comandos de inicio que instala Docker, Docker Compose y Dnsmasq.
  • Crea y habilita una cuenta de servicio para el clúster de GKE a fin de alojar cargas de trabajo como un entorno de destino. En esta implementación, crearás una cuenta de servicio que los nodos del clúster de GKE usarán. Te recomendamos que limites la cuenta de servicio solo a los permisos de acceso y los roles necesarios para ejecutar la app. En esta implementación, los roles que se necesitan para la cuenta de servicio de los nodos del clúster de GKE son los siguientes:
  • Aprovisiona y configura un clúster de GKE para alojar las cargas de trabajo como un entorno de destino. Para aprovisionar los clústeres de GKE, Terraform usa el módulo de Terraform kubernetes-engine.

Implementa la carga de trabajo en el entorno de origen

En esta implementación, debes implementar la app de Istio Bookinfo como la carga de trabajo que se migrará. En el siguiente diagrama, se muestra la arquitectura del entorno de origen:

Arquitectura de destino para el entorno de origen.

En el diagrama, los clientes acceden a la carga de trabajo de ejemplo que se ejecuta en Compute Engine. Para reducir la complejidad en este ejemplo, los clientes se conectan directamente a una sola instancia de Compute Engine. En un entorno de producción, esta conexión directa es poco probable, ya que necesitas una capa de balanceo de cargas para ejecutar varias instancias de una carga de trabajo.

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Implementa las cargas de trabajo en las instancias de Compute Engine:

    scripts/workloads.sh \
    --deploy-with "COMPOSE" \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}"
    

    La secuencia de comandos workloads.sh hace lo siguiente:

    • Configura el proyecto, la región y la zona predeterminados.
    • Copia los descriptores de Docker Compose en las instancias de Compute Engine.
    • Implementa la carga de trabajo de ejemplo mediante Docker Compose.

    Si no creaste un archivo de claves SSH a fin de autenticarte con instancias de Compute Engine, gcloud CLI te pedirá que generes uno.

    En el resultado, verás una confirmación de la implementación y cómo puedes acceder a ella. El resultado es similar al siguiente:

    You can access the workload by loading http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
    

    En el resultado, COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP es la dirección IP en la que se entrega la carga de trabajo. Toma nota de la dirección IP, ya que la usarás en un paso posterior.

Prueba la implementación en el entorno de origen

  • Abre un navegador y dirígete a la siguiente URL, en la que COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP es la dirección IP del paso anterior:

    http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
    

Se muestra una página con detalles sobre libros y calificaciones relevantes.

Configura Istio

En esta sección, configurarás el entorno de destino en Google Cloud mediante la instalación de Istio y, luego, usarás Istio para exponer la carga de trabajo de ejemplo. En el siguiente diagrama, se muestra la arquitectura del entorno de destino:

Entorno de destino con Istio instalado.

En el diagrama, Istio expone la carga de trabajo que se ejecuta en Compute Engine.

Instala Istio

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Instala Istio:

    scripts/install-istio.sh \
    --cluster-name "${GKE_CLUSTER_NAME}" \
    --google-cloud-project "${DEFAULT_PROJECT}" \
    --cluster-region "${DEFAULT_REGION}"
    

    La secuencia de comandos install-istio.sh hace lo siguiente:

    • Descarga la distribución de Istio.
    • Instala Istio en el clúster de GKE del entorno de destino.
    • Implementa una puerta de enlace para exponer los servicios en la malla de servicios.
    • Configura Istio para permitir la expansión de la malla de servicios a las instancias de Compute Engine que simulan el entorno de origen.
    • Instala herramientas de supervisión y visualización de la malla de servicios, como Kiali.

    Cuando el comando termina de ejecutarse, la consola muestra una confirmación de la instalación. El resultado es similar al siguiente:

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

Configura la expansión de malla de Istio

En esta sección, conectarás la instancia de Compute Engine que simula el entorno de origen a la malla de servicios. La malla de servicios controla la conexión de los microservicios en el entorno heredado que se migrarán al entorno de destino. En esta fase, la malla de servicios está vacía, a la espera de que se registren los servicios. La malla de servicios aún no recibe tráfico de producción.

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Instala y configura Istio en la instancia de Compute Engine:

    scripts/compute-engine-mesh-expansion-setup.sh \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}"
    

    La secuencia de comandos compute-engine-mesh-expansion-setup.sh hace lo siguiente:

    • Instala Istio en las instancias de Compute Engine del entorno de origen.
    • Inicia el servicio de Istio en las instancias de Compute Engine.

Expón la carga de trabajo

En esta sección, registrarás las cargas de trabajo que se ejecutan en la instancia de Compute Engine y simulan el entorno de origen en la malla de servicios de Istio.

La secuencia de comandos workloads.sh que ejecutas en esta sección configura reglas de enrutamiento para dividir el tráfico de producción entre los servicios que se ejecutan en el entorno heredado y los servicios que se ejecutan en el entorno de destino mediante la malla de servicios. Debido a que el enrutamiento de tráfico dentro de la malla de servicios es transparente para los clientes, no sabrán que la configuración de enrutamiento cambió.

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Expón las cargas de trabajo:

    scripts/workloads.sh \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}" \
    --expose-with "ISTIO_COMPUTE_ENGINE"
    
  3. La secuencia de comandos workloads.sh hace lo siguiente:

    • Configura el proyecto, la región y la zona predeterminados.
    • Habilita la inyección automática de sidecar para evitar las ediciones manuales en los descriptores de implementación.
    • Registra las cargas de trabajo que se ejecutan en la instancia de Compute Engine en la malla mediante la configuración de los extremos WorkloadEntry y los servicios correspondientes.
    • Implementa el ServiceEntries para permitir el tráfico al servidor de metadatos de Compute Engine y a API de Cloud.
    • Implementa servicios virtuales para enrutar el tráfico desde la puerta de enlace de Istio a la instancia productpage que se ejecuta en la instancia de Compute Engine.

    En el resultado, verás una confirmación de la implementación y cómo puedes acceder a ella. El resultado es similar al siguiente:

    You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

    En el resultado, ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP en la que se entrega la carga de trabajo. Toma nota de la dirección IP, ya que la usarás en un paso posterior.

Prueba la expansión de malla de Istio

En esta sección, probarás la carga de trabajo de ejemplo que se ejecuta en la instancia de Compute Engine que usaste para exponer Istio.

  • Abre un navegador y dirígete a la siguiente URL, en la que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP del paso anterior:

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

El punto de entrada del entorno de origen (que se conecta a la instancia de Compute Engine) aún está disponible en esta etapa. Cuando migres un entorno de producción, recomendamos que redirecciones el tráfico de forma gradual al entorno de destino mediante la actualización de la configuración de la capa de balanceo de cargas.

Visualiza la malla de servicios

En esta sección, debes usar Kiali para ver una representación visual de la malla de servicios.

  1. Abre un navegador y dirígete a la siguiente URL, en la que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP del paso anterior:

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
    

    Se muestra el panel de servicio de Kiali.

  2. En Cloud Shell, ejecuta una solicitud varias veces para la página principal de la carga de trabajo de ejemplo:

    ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
    
    for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
    

    La solicitud genera tráfico a la app Bookinfo. El resultado muestra una lista de las marcas de tiempo de cada solicitud HTTP al servicio productpage y el código de retorno HTTP de cada solicitud (200 en este caso).

    El resultado es similar al siguiente:

    2021-06-09T10:16:15,355323181+00:00 - 200
    2021-06-09T10:16:15,355323182+00:00 - 200
    2021-06-09T10:16:15,355323183+00:00 - 200
    [...]
    

    La solicitud tarda en completarse, por lo que puedes dejarla en ejecución y continuar con el siguiente paso.

  3. En el panel de servicio de Kiali, verás un diagrama de la malla actual, con el tráfico enrutado a los servicios que se ejecutan en Compute Engine. Todo el tráfico se enruta desde istio-ingressgateway al microservicio productpage que se ejecuta en la instancia de Compute Engine con la etiqueta de versión compute-engine y al servicio kiali para visualizar la malla de servicios.

    No ves los otros servicios en el gráfico (details, reviews y ratings) porque el microservicio productpage que se ejecuta en Compute Engine se conecta directamente a otros microservicios que se ejecutan en Compute Engine. El microservicio productpage no pasa por la malla de servicios.

    Si deseas que todo el tráfico pase por la malla de servicios, debes volver a configurar las cargas de trabajo que se ejecutan en Compute Engine para que apunten a los servicios en la malla de servicios, en lugar de conectarse directamente a ellas.

    Si no ves el siguiente diagrama en el panel de Kiali, actualiza la página.

    El panel de Kiali muestra cómo se enruta el tráfico.

    En el diagrama de el panel de Kiali, se muestra que el tráfico se enruta a los servicios que se ejecutan en Compute Engine.

  4. En Cloud Shell, presiona Control+C para detener el comando de generación de tráfico.

Migra la carga de trabajo

En esta sección, debes migrar los componentes de la carga de trabajo de ejemplo de la instancia de Compute Engine al clúster de GKE. Para cada microservicio de la carga de trabajo de ejemplo, debes hacer lo siguiente:

  • Implementa una instancia del microservicio en el clúster de GKE
  • Comienza a enrutar el tráfico a las instancias de microservicios que se ejecutan en Compute Engine y a GKE.

En el siguiente diagrama, se muestra la arquitectura del sistema para esta sección:

Arquitectura de destino con tráfico enrutado a instancias de microservicios en Compute Engine y GKE.

En el diagrama, Cloud Load Balancing enruta el tráfico a la puerta de enlace de Istio y, luego, Istio enruta el tráfico a los servicios que se ejecutan en Compute Engine o a los servicios que se ejecutan en GKE.

Para migrar los componentes de la carga de trabajo de ejemplo, haz lo siguiente:

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Implementa tus cargas de trabajo en el entorno de destino.

    scripts/workloads.sh \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}" \
    --deploy-with "GKE"
    

    La secuencia de comandos workloads.sh hace lo siguiente:

    Verás una confirmación de la implementación y cómo puedes acceder a ella. El resultado es similar al siguiente:

    You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

La malla de servicios enruta el tráfico a las cargas de trabajo de ejemplo que se ejecutan en las instancias de Compute Engine y a las que se ejecutan en el clúster de GKE.

Prueba la carga de trabajo que se ejecuta en Compute Engine y GKE

En esta sección, probarás la carga de trabajo de ejemplo que implementaste en Compute Engine y GKE.

  • Abre un navegador y dirígete a la siguiente URL, en la que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP del paso anterior:

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

    Se muestra una página Bookinfo con información sobre libros y calificaciones relevantes.

Debido a que implementaste la misma versión de la carga de trabajo de ejemplo en Compute Engine y en el clúster de GKE, el resultado es el mismo que el de la prueba anterior.

Visualiza la malla de servicios

En esta sección, debes usar Kiali para ver una representación visual de la malla de servicios.

  1. Abre un navegador y dirígete a la siguiente URL, en la que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP del paso anterior:

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
    
  2. En Cloud Shell, ejecuta una solicitud varias veces para la página principal de la carga de trabajo de ejemplo:

    ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
    for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
    

    Este comando genera tráfico a la aplicación Bookinfo. El resultado esperado es una lista de las fechas de las solicitudes HTTP al servicio productpage y el código de retorno HTTP de cada solicitud (200 OK en este caso). La salida es similar a lo siguiente:

    2021-06-09T10:16:15,355323181+00:00 - 200
    2021-06-09T10:16:15,355323182+00:00 - 200
    2021-06-09T10:16:15,355323183+00:00 - 200
    [...]
    
  3. En el panel de servicio de Kiali, verás un diagrama de la malla actual, con tráfico enrutado a los servicios que se ejecutan en Compute Engine y GKE.

    Cada instancia de microservicio tiene una etiqueta que explica su revisión.

    • Las instancias que se ejecutan en Compute Engine tienen una etiqueta compute-engine.
    • Las instancias que se ejecutan en GKE tienen una cadena adicional, por ejemplo, v1 o v3.

    Las instancias que se ejecutan en Compute Engine se conectan directamente a las otras instancias de Compute Engine sin pasar por la malla de servicios. Por lo tanto, no ves el tráfico que pasa de las instancias que se ejecutan en Compute Engine a otras instancias.

    Si no ves el siguiente diagrama en el panel de Kiali, actualiza la página.

    El panel de Kiali muestra cómo se enruta el tráfico.

    En el diagrama de el panel de Kiali, se muestra el tráfico que se enruta a los servicios que se ejecutan en Compute Engine y a los servicios que se ejecutan en GKE.

  4. En Cloud Shell, presiona Control+C para detener el comando de generación de tráfico.

Enruta el tráfico solo al clúster de GKE

En esta sección, enrutarás el tráfico solo a las instancias de servicio de la carga de trabajo que se ejecutan en el clúster de GKE. Para cada servicio de la carga de trabajo de ejemplo, borra la referencia WorkloadEntry que apunta al servicio que se ejecuta en Compute Engine. La eliminación hace que el servicio solo seleccione las instancias de microservicios que se ejecutan en el clúster de GKE y el tráfico solo se enruta al clúster de GKE. En el siguiente diagrama, se muestra la arquitectura del sistema para esta sección:

Arquitectura de destino con tráfico enrutado al clúster de GKE.

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Expón las cargas de trabajo solo en el entorno de destino:

    scripts/workloads.sh \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}" \
    --expose-with "GKE_ONLY"
    

    La secuencia de comandos workloads.sh borra las referencias WorkloadEntry que apuntan a las instancias de microservicios que se ejecutan en Compute Engine desde el clúster de GKE.

    Verás una confirmación de la implementación y cómo puedes acceder a ella. El resultado es similar al siguiente:

    You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

La entrada de servicio usa workloadSelector para seleccionar de forma automática la carga de trabajo de ejemplo que se ejecuta en el clúster de GKE.

Prueba la carga de trabajo que se ejecuta en GKE

  • Abre un navegador y dirígete a la siguiente URL, en la que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP del paso anterior:

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
    

    Se muestra una página Bookinfo con información sobre libros y calificaciones relevantes.

Visualiza la malla de servicios

En esta sección, debes usar Kiali para ver una representación visual de la malla de servicios.

  1. Abre un navegador y dirígete a la siguiente URL, en la que ISTIO_INGRESS_GATEWAY_EXTERNAL_IP es la dirección IP del paso anterior:

    http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
    
  2. En Cloud Shell, ejecuta una solicitud varias veces para la página principal de la carga de trabajo de ejemplo:

    ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
    for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
    

    Este comando genera tráfico a la aplicación Bookinfo. El resultado esperado es una lista de las fechas de las solicitudes HTTP al servicio productpage y el código de retorno HTTP de cada solicitud (200 OK en este caso). La salida es similar a lo siguiente:

    2021-06-09T10:16:15,355323181+00:00 - 200
    2021-06-09T10:16:15,355323182+00:00 - 200
    2021-06-09T10:16:15,355323183+00:00 - 200
    [...]
    
  3. El panel de servicio de Kiali muestra un diagrama de la malla actual con tráfico enrutado a los servicios que se ejecutan en GKE. Implementaste dos instancias de cada microservicio: una se ejecuta en la instancia de Compute Engine y la otra en el clúster de GKE. Sin embargo, debido a que quitaste las referencias WorkloadEntry que apuntan a las instancias de microservicios que se ejecutan en Compute Engine, los servicios solo seleccionan las instancias de microservicios que se ejecutan en el clúster de GKE.

    Si no ves el siguiente diagrama en el panel de Kiali, actualiza la página:

    El panel de Kiali muestra cómo se enruta el tráfico.

    En el diagrama de el panel de Kiali, se muestra el tráfico que se enruta a los servicios que se ejecutan en GKE.

  4. En Cloud Shell, presiona Control+C para detener el comando de generación de tráfico.

Retira el entorno de origen

Debido a que todo el tráfico ahora se enruta al clúster de GKE, puedes detener las instancias de la carga de trabajo que se ejecutan en Compute Engine.

Durante una migración de producción, mantén listo el centro de datos de origen para la estrategia de reversión. Recomendamos que comiences a retirar el centro de datos de origen solo cuando estés seguro de que la solución nueva funcione de forma correcta y de que todos los mecanismos de copia de seguridad y tolerancia a errores estén establecidos.

En el siguiente diagrama, se muestra la arquitectura del sistema para esta sección:

Entorno de origen sin instancias de carga de trabajo que se ejecutan en Compute Engine.

En el diagrama, Istio enruta el tráfico a los servicios que se ejecutan solo en GKE y se retiran las cargas de trabajo que se ejecutan en Compute Engine.

Para retirar el entorno de origen, haz lo siguiente:

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"
    
  2. Expón las cargas de trabajo solo en el entorno de destino:

    scripts/workloads.sh \
    --default-project "${DEFAULT_PROJECT}" \
    --default-region "${DEFAULT_REGION}" \
    --default-zone "${DEFAULT_ZONE}" \
    --deploy-with "GKE_ONLY"
    

    La secuencia de comandos workloads.sh detiene los contenedores que se ejecutan en las instancias de Compute Engine.

Limpia

Para evitar que se apliquen cargos a su cuenta de Google Cloud por los recursos usados en esta implementación, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra el proyecto

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

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Borra los recursos individuales

  1. En Cloud Shell, cambia el directorio de trabajo al directorio del repositorio:

    cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
    
  2. Borra los recursos que aprovisionaste:

    terraform destroy -auto-approve
    

¿Qué sigue?

  • Obtén más información sobre GKE.
  • Lee acerca de Istio.
  • Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.