La mayoría de los equipos empieza a desplegar en Kubernetes de la misma manera: el sistema de CI construye una imagen y luego ejecuta kubectl apply o helm upgrade contra el clúster. Funciona, hasta que crece el número de aplicaciones y clústeres. Esta guía explica qué cambia cuando un agente dentro del clúster, como Argo CD, extrae (pull) el estado deseado de Git en su lugar, y qué compensaciones conlleva.

El modelo push y dónde se tensa

En un pipeline push, el trabajo de CI es lo único que toca el clúster:

1. Un commit desencadena las pruebas y la construcción de la imagen.
2. El trabajo actualiza un manifiesto con la nueva etiqueta de imagen.
3. El trabajo ejecuta kubectl apply (o helm upgrade) contra el clúster.

Tres problemas aparecen al escalar:

• Las credenciales viven fuera del clúster. Cada pipeline necesita un kubeconfig o credenciales de la nube, y eso se multiplica con cada aplicación y cada clúster.
• Las herramientas viven en el runner. kubectl, helm y sus versiones deben estar instalados y sincronizados dondequiera que se ejecuten los despliegues.
• El feedback termina en “aplicado”. El trabajo sabe que el servidor de la API aceptó el manifiesto. No sabe si los Pods realmente se volvieron saludables.

Invierte la dirección: pull

Con un modelo pull, un agente se ejecuta dentro del clúster, observa un repositorio de Git, compara lo que está declarado allí con lo que se está ejecutando y aplica la diferencia.

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                        Argo CD (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

Las credenciales del clúster nunca salen de él, porque lo único que aplica cambios es el agente que se ejecuta dentro. Los ingenieros y los sistemas de CI solo necesitan acceso de escritura a Git. Argo CD puede leer YAML plano, charts de Helm y overlays de Kustomize, y los convierte en manifiestos de Kubernetes antes de aplicarlos.

Mantén el código de la aplicación y la configuración en repositorios separados

La recomendación habitual son dos repositorios: uno para el código fuente de la aplicación y otro para la configuración de Kubernetes (Deployments, Services, ConfigMaps, Ingresses, etc.).

La razón es que la configuración cambia según su propio ritmo. Editar un Service o un ConfigMap no debería desencadenar un pipeline completo de construcción y pruebas para código que no cambió, y no quieres lógica en el pipeline que inspeccione un commit para decidir qué omitir. El último paso del pipeline de CI pasa a ser “haz commit de la nueva etiqueta de imagen en el repositorio de configuración”, y Argo CD se encarga del resto. También separa limpiamente la propiedad: los desarrolladores son dueños del CI, los equipos de plataforma u operaciones son dueños de la entrega.

Haz de Git la única vía de entrada: detección de desviaciones y self-heal

Argo CD observa el clúster en vivo además del repositorio. Cuando los dos no coinciden, la aplicación se reporta como OutOfSync. Según cómo lo configures, Argo CD solo te avisa o revierte el clúster para que coincida con Git (consulta la guía de políticas de sincronización de esta serie).

Esto tiene consecuencias prácticas:

• Cada cambio tiene un commit, un autor y normalmente un pull request revisado, lo que te da un rastro de auditoría.
• Los permisos se mueven a Git. Los ingenieros junior pueden abrir pull requests; solo unos pocos hacen merge. No necesitas roles de clúster por persona para conseguirlo.
• Un kubectl edit rápido en producción deja de ser invisible.

Rollback y recuperación se vuelven operaciones de Git

Como el estado deseado está versionado, volver a un estado conocido y correcto es un git revert, y Argo CD hace converger el clúster hacia él. La misma idea cubre la recuperación. Si se pierde un clúster, creas uno nuevo, instalas Argo CD, registras el mismo repositorio y las cargas de trabajo se recrean a partir de él. Todo lo que no esté en Git, como los datos persistentes o los secretos que gestionas en otro lugar, sigue necesitando su propia estrategia de respaldo.

Una sola instancia de Argo CD también puede gestionar muchos clústeres, de modo que un solo repositorio puede gobernar una flota.

Lo que Argo CD no reemplaza

Argo CD es una herramienta de entrega, no de construcción. Sigues necesitando CI para probar el código, construir imágenes y subirlas a un registro. También es específico de Kubernetes, por lo que otros destinos de despliegue necesitan otras herramientas. Y no es el único controlador GitOps: Flux implementa los mismos principios con un diseño distinto. El resto de esta serie asume Argo CD y empieza con su instalación. Para la referencia completa, consulta la documentación oficial de Argo CD.