Instalación y Configuración de Anthos Service Mesh en Google Cloud
Resumen
¿Cómo instalar Anthos Service Mesh en Google Cloud?
El proceso de instalación del Anthos Service Mesh (ASM) en Google Cloud es más sencillo de lo que parece. Google Cloud proporciona una alternativa más robusta llamada Anthos Service Mesh en lugar de usar Istio debido a que ASM ofrece soporte, facilidad en las actualizaciones y funcionalidades adicionales. Antes de comenzar, asegúrate de estar familiarizado con la consola de administración de Google Cloud.
¿Cuáles son los pasos iniciales para configurar ASM?
Levantar Cloud Shell: Abre la consola de Google Cloud y levanta la Cloud Shell.
Configurar el proyecto: Utiliza el comando gcloud config set project [nombre_proyecto] para asegurarte de que estás trabajando en el proyecto correcto.
Crear un cluster: Crea un cluster que cumpla con la única restricción de ASM: cada nodo debe tener al menos cuatro VCPUs.
¿Cómo conectar al cluster y preparar el entorno?
Conectar al cluster: Usa la consola para generar el comando que te permitirá conectarte al cluster desde tu terminal.
Revisar kubeconfig: Verifica que el archivo kubeconfig tenga las credenciales necesarias para comunicarte con los clusters.
Instalar ASM: Descarga los binarios de la versión deseada de ASM y cambia los permisos para hacer ejecutable la instalación.
chmod +x install_asm
¿Cómo realizar la instalación y etiquetado en el namespace?
Instalar:
Ejecuta el comando para instalar ASM en el cluster objetivo, el proceso validará y levantará la malla de servicio automáticamente.
¿Por qué es importante la gestión de namespaces y la revisión?
El uso de revisiones permite gestionar mejor las actualizaciones de la malla de servicio. Ahora puedes tener varias versiones del plano de control y actualizar los namespaces individualmente sin desinstalar la malla entera, brindando mayor seguridad y confiabilidad.
¿Cómo verificar el despliegue de servicios y la malla de servicios?
Listar y verificar pods: Utiliza el comando para ver los pods desplegados y confirmar la inyección del sidecar proxy.
kubectl get pods --namespace demo
Revisar servicios en Anthos Service Mesh: Navega a la sección de mallas de servicio en Anthos para verificar que todos los servicios estén listados y que los datos de telemetría comiencen a poblarse, lo cual permitirá un mejor monitoreo y gestión de métricas como errores y latencia.
¿Qué nuevas funcionalidades ofrece ASM?
Telemetría y monitoreo: ASM proporciona tableros integrados donde puedes ver métricas de rendimiento, lo que te dará una vista clara y en tiempo real del comportamiento de tus servicios.
Aislamiento y seguridad reforzada: Gracias a los proxies sidecar, puedes gestionar mejor la seguridad y las configuraciones de tráfico interno.
Conclusión
ASM simplifica significativamente la gestión de servicios en Google Cloud al ofrecer una experiencia más integrada y eficiente. Además, introduce mejoras en la seguridad y facilita el monitoreo con herramientas sofisticadas. Sigue explorando y experimentando con las capacidades avanzadas que Anthos Service Mesh tiene para ofrecer, ¡sin miedo a ensuciarte las manos en el proceso!
Vemos que en nuestros pods tenemos dos contenedores, uno es de la aplicación y el otro del proxy que vimos en la clase pasada.
Podemos ver en el frontend de GCP (Anthos > Service Mesh) la lista de los servicios que ya conoce mi service mesh. Luego con el uso podremos ver métricas de cada uno de ellos.
Hola un typo en paso 11, es -l en lugar de -1
kubectl -n istio-system get pods -l app=istiod --show-labels
pero estos servicios me imagino que tienen un precio, creo que hace falta detallar los precios que tiene google cloud, yo hice unas pruebas y me llego el recibo al mes a pesar que lo baje y no tenia ya nada instalado. 🤣
Deberian agregar un listado con las urls de los recursos utilizados en el ejercicio para replicarlos. Se vuelve complejo pasar lo del video a la cloud shell
Beneficios de ASM sobre OSS lstio
Mantenida y soportada
Tableros integrados ( SLOs y Tablero de seguridad)
Funcionalidad de Enterprise
Imagina que Istio open-source es como armar un auto desde cero: tú eres responsable de conseguir las piezas, darle mantenimiento y arreglarlo si se descompone en la carretera. Anthos Service Mesh (ASM), por otro lado, es como rentar un auto de lujo con chofer y seguro incluido. Es la versión administrada por Google Cloud. Es mejor porque te quita el peso operativo de encima. Google se encarga del soporte técnico, la seguridad del plano de control y facilita enormemente las actualizaciones. Además, ASM incluye características Enterprise listas para usar, como tableros de observabilidad integrados, soporte para máquinas virtuales y la posibilidad de conectar tu propio proveedor de identidad para un control de acceso centralizado. En un entorno productivo, delegar esta carga operativa te permite enfocarte en desarrollar tu aplicación en lugar de pelear con la infraestructura.
Debes aplicar estas etiquetas justo antes de desplegar tus aplicaciones en el clúster. Etiquetar un namespace es como darle una instrucción permanente a un guardia de seguridad en la entrada de un edificio. Al agregar el label istio-injection con el número de revisión correspondiente, le estás diciendo a Kubernetes: "Cada vez que alguien cree un pod en este espacio, asegúrate de adjuntarle automáticamente un proxy de red". Si omites este paso, tus microservicios se desplegarán de forma normal, pero estarán ciegos y aislados de la malla de servicio; no enviarán métricas de telemetría, no tendrán seguridad mTLS y no aparecerán en tus tableros de topología. Es una buena práctica automatizar este etiquetado dentro de tus pipelines de CI/CD o en tus manifiestos de infraestructura como código para asegurar que ninguna carga de trabajo se quede fuera del radar de observabilidad.
La mejor forma de actualizar es utilizando el modelo de revisiones por namespace, una estrategia que funciona como probar un puente nuevo antes de demoler el viejo. En lugar de desinstalar la versión anterior de la malla (lo cual causaría una caída masiva), instalas el nuevo plano de control en paralelo. Cada versión tiene un identificador único o revisión (por ejemplo, 1102-3). Para migrar tus aplicaciones, simplemente cambias la etiqueta (label) en el namespace específico para que apunte a la nueva revisión. Luego, reinicias los pods de ese namespace. Al levantarse, los pods adoptarán automáticamente el proxy de la nueva versión. Si algo sale mal, puedes revertir la etiqueta a la versión anterior al instante. Este enfoque granular te permite actualizar servicio por servicio, reduciendo el riesgo a cero y garantizando alta disponibilidad continua.
