Para mí, uno de los aspectos más interesantes de Anthos, la solución empresarial de Google, es Anthos Config Management (ACM). Puedes configurar un repositorio de Git, conectar tus distintos clusters y estos estandarizarán sus configuraciones, evitando el drift al estilo GitOps. Esto es especialmente importante para grandes empresas que administran cientos o miles de clusters en distintas ubicaciones de hosting.
Automatiza la configuración multi-cluster de Kubernetes con Argo CD
Inspirado en ACM, me pregunté si podría replicar ese tipo de funcionalidad con otra solución de GitOps: Argo CD. Me alegra contarte que funcionó tal como esperaba: cuando hice cambios en los archivos de configuración del repositorio de Git, se aplicaron a ambos clusters sin ningún problema.
Vista general de la arquitectura
La preparación
Para simplificar, creé dos clusters en GKE, el servicio gestionado de Kubernetes de Google Cloud, en dos regiones distintas para simular escenarios de Este y Oeste. Por supuesto, puedes instalar Argo CD en clusters de cualquier ubicación siempre y cuando tengan acceso a tu repositorio de Git.
Creé el siguiente shell script para hacer el bootstrap de todo; aun así, para entornos productivos te recomendaría administrar la infraestructura con Terraform en la medida de lo posible.
Clusters con bootstrap
En 8 a 10 minutos ambos clusters ya estaban activos y los workloads de Argo CD desplegados.
Clusters de Kubernetes en las regiones Este y Oeste
Argo CD desplegado en cada cluster
App of Apps
Lo particular de este setup es que también instalé Argo CD en cada cluster con una Application inicial siguiendo el patrón App of Apps, apuntando a mi repositorio de Github. Esto te da flexibilidad para sumar tantas configuraciones como quieras al repositorio en el futuro y personalizar los clusters o las apps que despliegues en ellos.
Ten en cuenta que la sincronización automática es totalmente opcional. Si manejaras una cantidad enorme de clusters, te la recomendaría para que se autorreparen y gestionen el drift por sí solos. Sin embargo, una desventaja de la auto-sync es que la función de rollback deja de funcionar.
La carpeta (path) applications/ contiene una app (por ahora) llamada k8s-config.yaml, que a su vez es otra app de Argo que apunta a otra carpeta con nuestras configuraciones de Kubernetes.
La carpeta (path) k8s-config/ contiene todos los archivos YAML que queremos aplicar a mis clusters de Kubernetes. Opcionalmente, también puedes declarar una app que aplique las configuraciones de forma recursiva si tienes muchos archivos por organizar.
Repositorio de código fuente
Para el experimento publiqué un repositorio de código fuente en Github en mikesparr/multi-cluster-argo-demo con la siguiente estructura de directorios.
Estructura del repositorio de código fuente
En este ejemplo todo está en un único repositorio, pero podrías separar responsabilidades usando distintos repositorios y otorgando permisos de edición a equipos diferentes.
UI de Argo
Desde la línea de comandos puedes hacer port-forward al servicio argo-server
kubectl -n argocd port-forward svc/argo-server 8080:443
Abre http://localhost:8080 en tu navegador y, cuando aparezca el aviso, acepta la excepción de seguridad (sin https). TIP: por defecto, inicias sesión con admin y el nombre completo del pod del servidor argocd:
Copia el argocd-server-XXXXXXX como tu contraseña por defecto
Al principio aparece la aplicación (app of apps) hasta que se sincroniza
Una vez que tu App of Apps (applications) se sincronice, reconocerá tu primera app: k8s-config.
Después de que ambas aplicaciones se sincronizan
Si haces clic en el panel de la app k8s-config, verás el detalle de todo lo que instaló en el servidor.
Todos los archivos YAML del directorio /k8s-config del repositorio se aplican al servidor
Verifica la configuración de los clusters
Cambia el contexto de kubectl a cada cluster y revisa los namespaces, serviceaccounts, roles y rolebindings del test-namespace. Verás que están instalados en ambos clusters. ¡Felicitaciones!
El cluster instaló automáticamente los workloads desde el repositorio de Git
Demo en video
Demo en vivo: agregar un pod de Nginx y desplegarlo automáticamente en múltiples clusters desde un repositorio de Github
Potencial infinito
Imagina que quieres sumar un API Gateway a tu stack y te decides por Ambassador o Kong, ambos configurados con CRDs y YAML. Bastaría con agregar otra carpeta o repositorio, luego otro YAML de app dentro de la carpeta applications/, y ArgoCD lo instalaría y configuraría automáticamente por ti.
Por cada aplicación que publique el equipo de Engineering, podrían editar la versión de la imagen Docker en un manifiesto de Deployment, abrir un pull request con el cambio y, de paso, ya tienes incorporados los criterios manuales y la separación de funciones. Una vez que se haga merge del PR, Argo CD lo desplegará en el cluster y entorno correspondientes.
Otro caso de uso sería soportar despliegues multi-cloud y balancear el tráfico con DNS para lograr una verdadera configuración activo-activo. Otro más podría ser migrar de una nube a otra.
Tengo muchas ganas de seguir explorando posibilidades y espero que hayas disfrutado esta otra forma de mantener los clusters sincronizados en distintos entornos.
Limpieza
Si usaste el script o el repositorio, no olvides hacer la limpieza y eliminar tus recursos para evitar cargos innecesarios. Lo más sencillo es eliminar los clusters con el siguiente comando (o eliminar el proyecto).
gcloud container clusters delete west --zone us-west2-b
gcloud container clusters delete east --zone us-east1-c