Trabajar en un entorno multicloud puede ser intimidante. No solo significa utilizar múltiples servicios de nube, sino también garantizar su interoperabilidad. En este laboratorio, aprenderemos a gestionar infraestructuras utilizando Google Cloud Platform (GCP) y Amazon Web Services (AWS). Veamos cómo empezar a aprovisionar, configurar y visualizar nuestras aplicaciones en un entorno multicloud.
¿Qué necesitamos para comenzar?
Para llevar a cabo el laboratorio, es necesario contar con:
Credenciales para acceder a GCP y AWS.
Un repositorio de GitLab con el workshop Anthos Multicloud.
La plataforma Quick Labs, que nos proporciona credenciales y alguna infraestructura preconfigurada.
¿Cómo configurar entornos de trabajo?
Comenzamos iniciando sesión en la consola de GCP (console.cloud.google.com) usando las credenciales proporcionadas. Es importante elegir el proyecto correcto usando gcloud config set project. Esto nos asegura trabajar en el entorno adecuado.
gcloud config set project <YOUR_PROJECT_ID>
A continuación, configuramos las variables de ambiente que serán necesarias para aprovisionar la infraestructura en AWS. Estas incluyen la secret_access_key, AWS_access_key_id, entre otras. Después, creamos un directorio para nuestro proyecto con mkdir y lo preparamos para trabajar ahí:
mkdir ~/AnthosMulticloud
cd ~/AnthosMulticloud
exportWORKDIR=~/AnthosMulticloud
¿Cómo aprovisionar infraestructura?
El proceso de aprovisionamiento utiliza scripts que tienen instrucciones definidas para implementar la infraestructura necesaria. Usamos Terraform para aprovisionar recursos en GCP y AWS en diferentes ambientes: desarrollo, staging y producción.
Monitorizamos el proceso desde Cloud Build en la consola de Google, donde veremos cómo se despliegan varios jobs para levantar la infraestructura.
¿Qué servicios se implementan?
El despliegue crea:
Clústeres de GKE para Google Cloud.
Clústeres de EKS en AWS.
Un servidor GitLab para configuraciones remotas.
Durante el script de aprovisionamiento, tareas como la creación de clústeres y la configuración de redes de trabajo se realizan para cada entorno. Este proceso puede tardar de 20 a 25 minutos.
¿Cómo visualizar el despliegue?
Para asegurarnos de que nuestra infraestructura esté funcionando correctamente, accedemos a los servicios implementados y revisamos su funcionamiento. Usamos kubectl para verificar los clústeres de Kubernetes, y Kiali para monitorear el tráfico y el estado de los servicios en tiempo real.
kubectl get pods -n istio-system
Kiali proporciona un gráfico visual que muestra cómo los servicios se conectan entre sí y el flujo del tráfico entre microservicios.
¿Cómo manejar la portabilidad de los servicios?
Uno de los aspectos esenciales del enfoque multicloud es mover servicios entre nubes rápidamente:
Si un servicio falla en AWS, podemos migrarlo a GCP.
El script de despliegue nos ayuda a crear un nuevo servicio en GCP.
Por ejemplo, si el cart service en AWS deja de funcionar, lo recreamos en GKE, lo cual restablece la aplicación sin que el usuario final note interrupciones.
¿Cómo implementar múltiples instancias?
Finalmente, desplegamos diferentes instancias del front end en ambas nubes, GCP y AWS, utilizando etiquetas y selectores. Esto permite un balance de carga entre nubes y garantiza alta disponibilidad. Al acceder a nuestra aplicación, podemos alternar entre instancias en GCP y AWS sin interrumpir la experiencia del usuario.
Con estas configuraciones y scripts, hemos logrado un entorno multicloud robusto y preparado para manejar tráfico y contingencias efectivamente. Continúa explorando y adquiriendo experiencia práctica para llegar a dominar los entornos multicloud. ¡Tienes todo lo que necesitas para seguir aprendiendo y mejorando tus habilidades!
Se ve muy interesante el hands on! Ojala estuviera en Qwiklabs! 💻
Como aprendiz en ésto hubiera estado ideal!! :(
Lo raro es que desde el lado de GCP si lo ejecuta desde quicklabs pero no lo encontre. tampoco.
Mis respetos al contenido de este laboratorio, desde el tiempo dedicado hasta la configuración del repositorio.
¿Cómo se manejarían en este laboratorio las bases de datos de los microservicios? Existiría una base en cada nube? Cada microservicio tendría una base independiente?
Lindo ver este laboratorio en ejecución!! Realmente aterriza todo lo aprendido!
Genial lo fácil que lo hacen ver, pero con scripts ya hechos 😅
Para lograr esto, Anthos actúa como un puente de control unificado. En lugar de saltar entre la consola de AWS y la de Google Cloud, utilizas tokens de acceso generados durante el aprovisionamiento de tu infraestructura. Al registrar estos tokens en GCP, le otorgas a Google Cloud los permisos necesarios para leer el estado y gestionar los recursos de los clústeres de EKS (Elastic Kubernetes Service).
Piensa en esto como un control remoto universal: configuras la frecuencia de tu televisor (AWS) en el control de tu sistema de sonido (GCP). Esto te permite tener una visión centralizada de los nodos, vCPUs y memoria de toda tu flota, sin importar dónde vivan físicamente los servidores. Es una ventaja operativa gigante porque estandariza la administración y reduce la fricción de tener múltiples paneles de control.
Sí, es totalmente viable y representa uno de los mayores superpoderes de una arquitectura distribuida. Utilizando un Ingress Gateway centralizado, puedes recibir todas las peticiones de los usuarios en una nube principal (por ejemplo, GCP) y, desde ahí, enrutar el tráfico de forma transparente hacia réplicas de tu aplicación que viven en otras nubes (como AWS).
Kubernetes logra esta magia gracias a las etiquetas y selectores. Para el orquestador, dos despliegues con las mismas etiquetas son idénticos, sin importar si uno corre en GKE y el otro en EKS. El gateway evalúa la disponibilidad y balancea la carga a través de canales seguros. Esto es ideal para estrategias de alta disponibilidad, mitigación de caídas regionales o incluso para aprovechar créditos y recursos ociosos en diferentes proveedores de nube simultáneamente.
Porque en un entorno distribuido, rastrear un error sin una herramienta centralizada es como buscar una aguja en un pajar a oscuras. Al tener microservicios repartidos entre Google Cloud y AWS, los logs y métricas aislados no te cuentan la historia completa. Herramientas de observabilidad visual como Kiali se conectan directamente a la telemetría que emiten los proxies (como Envoy) en tu malla de servicios.
Esto te permite generar un mapa topológico en tiempo real de cómo fluye el tráfico entre tus servicios, sin importar en qué nube residan. Si un servicio empieza a fallar, la gráfica te mostrará exactamente dónde se rompe la cadena de peticiones (por ejemplo, marcando la conexión en rojo). Centralizar esta visión reduce drásticamente el Tiempo Medio de Recuperación (MTTR) y te da la confianza para operar infraestructuras complejas.
En conclusion seguir pautas establecidas de comandos, segun yo