¿Qué es GitOps y cómo funciona realmente la gestión declarativa de infraestructura a través de git?

#La idea central: git es el estado deseado, no solo un historial de este

GitOps es un modelo operativo en el que el estado deseado de tu infraestructura y tus aplicaciones se declara enteramente en git — manifiestos de Kubernetes?, charts de Helm?, overlays de Kustomize, HCL de Terraform — y una pieza de automatización que corre dentro del entorno objetivo compara continuamente ese estado declarado contra lo que realmente está corriendo, y reconcilia cualquier diferencia. El commit no es un registro de lo que pasó; es la instrucción de lo que debería existir.

Este es un cambio arquitectónico significativo respecto al CI/CD tradicional, y los entrevistadores preguntan sobre esto porque el cambio afecta dónde viven la autoridad y las credenciales, no solo qué archivos YAML editas.

#CI/CD basado en push vs. GitOps basado en pull

En un pipeline de push tradicional, tu sistema de CI (GitHub Actions, Jenkins, GitLab CI) construye un artefacto y luego ejecuta kubectl apply o helm upgrade directamente contra el clúster, usando credenciales almacenadas como secretos de CI. El sistema de CI alcanza hacia dentro del clúster.

En GitOps, esa dirección se invierte. Un operador que corre dentro del clúster — ArgoCD o Flux? son las dos opciones dominantes — vigila un repositorio de git y hala (pull) los cambios hacia el clúster mismo. Nada externo necesita jamás un kubeconfig de administrador del clúster; lo único que necesita acceso de escritura al clúster es el reconciliador que ya corre dentro de él. Esta única inversión es el argumento de seguridad de GitOps: reduce a uno el número de sistemas que pueden mutar producción, y la única entrada de ese sistema es un commit de git auditable.

#El ciclo de reconciliación

El operador ejecuta un ciclo continuo: lee el estado deseado desde git, lee el estado real desde el API server del clúster, compara ambos y actúa. Si un desarrollador sube la versión de una imagen en el repo de manifiestos, el operador aplica el cambio. Si alguien ejecuta kubectl edit directamente sobre un Deployment en ejecución y cambia manualmente el número de réplicas, el reconciliador nota la desviación en su siguiente pasada y la revierte a lo que diga git — infraestructura autorreparable, sea que el "daño" fuera un error o un atajo intencional.

La mayoría de los equipos dividen esto en dos repositorios: un repo de la aplicación (código fuente, Dockerfile, configuración de CI) y un repo de manifiestos separado (el YAML de Kubernetes/Helm/Kustomize que describe qué debe correr). El único acceso de escritura de CI al repo de manifiestos es abrir un pull request — a menudo subiendo automáticamente un tag de imagen — que una persona o una política automatizada fusiona, y solo entonces el operador ve y aplica el cambio. Esto mantiene "construir" y "desplegar" como eventos auditables y con permisos separados.

#Por qué los equipos lo adoptan

• Auditabilidad por construcción. Cada cambio de infraestructura es un commit de git con autor, marca de tiempo y — si se exigen PRs — un revisor. El git log del repo de manifiestos es tu historial de despliegues.
• Rollback trivial y confiable. Revertir un mal despliegue es un git revert, no recordar los valores exactos de un Helm anterior o reconstruir manualmente un estado previo.
• Radio de impacto reducido para las credenciales. Ningún runner de CI, laptop o script externo necesita un kubeconfig de producción. Comprometer el CI ya no significa comprometer el clúster directamente.
• Autorreparación ante desviaciones. Los cambios manuales y no documentados se revierten silenciosamente en lugar de acumularse como estado "copo de nieve" no rastreado que nadie puede reproducir.
• Consistencia entre entornos. El mismo modelo de reconciliación y la misma estructura de repos (por ejemplo, base de Kustomize + overlays por entorno) escala de un clúster a una flota entera, a menudo mediante un patrón "app-of-apps" donde una Application raíz de ArgoCD gestiona muchas Applications hijas.

#Lo que te cuesta

GitOps no está libre de trade-offs. Los secretos no se pueden subir a git en texto plano, así que los equipos necesitan Sealed Secrets, archivos cifrados con SOPS, o un External Secrets Operator que los obtenga de un vault en el momento de reconciliar — una pieza extra de infraestructura que hay que configurar bien o la gestión de secretos se convierte en el eslabón débil. La reconciliación no es instantánea; hay un intervalo de sincronización (o una sincronización disparada por webhook) entre "commit fusionado" y "cambio aplicado", lo cual importa para quien espera la velocidad de un push-and-forget. Y el propio comportamiento de autorreparación puede sorprender a un ingeniero que hace kubectl edit sobre algo durante un incidente esperando que se mantenga, solo para ver cómo el operador lo revierte silenciosamente minutos después — una trampa operativa real que vale la pena conocer antes de toparse con ella en vivo.