Un setup pragmático de Argo CD — GitOps que sobrevive al contacto con la realidad

Argo CD es uno de esos proyectos enormemente populares y enormemente mal desplegados. Cada equipo con el que trabajo tiene alguna versión de Argo CD corriendo. Quizás un tercio lo tiene configurado de un modo que de verdad les ahorra trabajo en vez de ser una versión peor de kubectl apply con YAML extra.

La diferencia suele estar en tres sitios: estructura del repo, orquestación de sync waves, y cómo gestionas los secretos.

La disposición de repo App-of-Apps

gitops-repo/
├── bootstrap/                  # root app-of-apps
├── platform/                   # infra cluster-wide (ingress, cert-manager, …)
├── tenants/
│   ├── team-payments/{dev,staging,prod}/
│   └── team-search/{dev,staging,prod}/
└── projects/                   # fronteras RBAC AppProject

Una sola Application raíz arranca el clúster. platform/ lo posee el equipo de plataforma. Cada tenant tiene su propia carpeta por entorno, por lo que la promoción es un PR que copia manifiestos de un directorio al siguiente.

El artículo completo cubre:

• Sync waves — la convención de numeración que usamos en cada clúster
• Por qué usamos External Secrets Operator + un vault, no sealed-secrets (rotación)
• Auto-sync para dev/staging, sync manual para prod (y por qué)
• ApplicationSet para patrones de flota-de-entornos
• Notificaciones: las alertas Slack que de verdad importan
• Respaldar Argo CD y las lecciones de la vez que no lo hicimos

Entregamos esta disposición en cada clúster Kubernetes gestionado.