Migrar tu cluster a GitOps sin romper producción

La migración a GitOps es una de esas tareas que o se hacen bien, o se hacen una sola vez. El error clásico es el big bang: “movemos todo el cluster de una”. Eso termina con un viernes a las 11pm intentando explicar por qué el staging no levanta.

La buena noticia: se puede migrar de forma incremental, app por app, sin downtime y con un plan de rollback claro. Acá va la estrategia que funciona.

La regla de oro: no migres el cluster, migrá apps

GitOps gobierna aplicaciones, no “clusters”. La unidad de migración es la aplicación: su deployment, service, configmaps, secrets y policies asociados. Empezá por las apps menos críticas y andá subiendo en confianza.

Paso 1: Doble escritura (la fase de seguridad)

Antes de tocar nada, garantizá que cualquier cambio que se haga por el flujo viejo siga funcionando durante la transición:

1. Poné el repo bajo control de Git (si no está, git init y commit del estado actual).
2. Documentá el estado actual: kubectl get all -A y guardá los outputs como baseline.
3. Configurá el agente GitOps (ej. Argo CD) apuntando al repo, pero con auto-sync: false.

En esta fase conviven ambos mundos: la gente sigue aplicando a mano, y el agente solo observa y reporta drift. Nadie se entera de que existe.

Paso 2: Adoptá la primera app (la más fácil)

Elegí la app menos crítica y más simple (un servicio interno, un cronjob, algo que no facture):

1. Versioná sus manifiestos en el repo (app/ + envs/dev/).
2. Creá la Application de Argo CD con auto-sync en modo prune disabled al principio.
3. Cuando el diff entre repo y cluster sea cero, activá auto-sync + selfHeal.

Ejemplo mínimo de Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mi-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/tu-org/tu-repo
    path: apps/mi-app/overlays/prod
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: mi-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

⚠️ prune borra recursos que desaparecen del repo. Activarlo sin entenderlo es el accidente más común en migraciones. Primero prune: false, después de unas semanas sin sorpresas, prune: true.

Paso 3: Escalá app por app, en oleadas

• Oleada 1: apps internas, sin criticidad.
• Oleada 2: apps con usuarios, en horarios de bajo tráfico.
• Oleada 3: apps críticas, cuando ya confiás en el proceso.

Entre oleadas, dejá pasar tiempo (una semana o más). La confianza se construye viendo el loop funcionar, no leyendo docs.

Paso 4: El plan de rollback (antes de necesitarlo)

Esto se define al principio, no cuando algo explota:

1. Por app: git revert del último commit y push. El agente revierte el cluster solo.
2. Global: si el agente mismo es el problema, un kubectl -n argocd scale deploy argocd-server --replicas=0 congela todo el sync (las apps quedan como están; no se desinstalan).
3. De emergencia: el repo siempre tiene el último estado bueno. git checkout <tag-estable> && git push vuelve a ese estado.

Ninguno de estos pasos requiere tocar el cluster a mano. Ese es el punto.

Anti-patrones que vi en producción

• Migrar y desactivar el flujo viejo el mismo día. Error. La doble escritura tiene que durar lo que tarde la gente en acostumbrarse.
• Poner secrets en el repo en claro. Ni lo pienses. Usá Sealed Secrets o SOPS desde el día uno.
• Una sola Application gigante con todo el cluster. Rompé en apps pequeñas: el diff, el rollback y el blame de Git funcionan mucho mejor a esa escala.
• Olvidar el auto-healing. Sin selfHeal, el drift se acumula callado y la migración no sirvió de nada.

El resultado

Cuando termina la migración, el cluster se opera como un repo: PRs, reviews, CI y rollbacks desde Git. Nadie aplica YAML a mano, nadie pregunta quién tocó qué, y el historial de cambios es el historial de Git.

En el ebook armé toda la estrategia con más detalle — patrones de repositorio, App of Apps, secrets y la migración completa paso a paso con laboratorios para hacerla en tu propio cluster:

→ GitOps para DevOps · De CI/CD a la operación declarativa de Kubernetes, con Argo CD y Flux.

Y si todavía no estás convencido de por qué migrar: Qué es GitOps y por qué tu equipo debería adoptarlo.