¿Qué es GitOps y en qué se diferencia de un despliegue basado en push?

GitOps guarda el estado deseado del sistema en git y ejecuta un agente dentro del entorno destino que tira continuamente de ese estado y reconcilia la realidad contra él. Un despliegue basado en push hace que CI tenga credenciales del clúster y aplique cambios desde fuera. El modelo de pull significa que CI nunca necesita credenciales de producción, que la deriva se corrige automáticamente y que el historial de git es un registro de auditoría fiel de lo que está desplegado.

Lo que lo define no es que los manifiestos vivan en git, es que un agente dentro del clúster observa el repositorio y reconcilia continuamente el estado en ejecución para que coincida. Basado en push significa que mi job de CI tiene un kubeconfig con acceso de escritura y aplica desde fuera, así que esas credenciales existen en el sistema de CI y, una vez que aplica, deja de importarle. Con el modelo de pull, CI solo escribe en un repositorio. Nada de fuera necesita credenciales del clúster, lo que estrecha muchísimo la superficie de ataque. Y como la reconciliación es un bucle y no un evento, si alguien edita un despliegue a mano a las dos de la mañana, se revierte y yo puedo ver la deriva. Aun así las partes incómodas son reales. Promocionar entre entornos se convierte en una pull request que cambia una etiqueta de imagen en un overlay, lo que parece más lento hasta que aprecias que además es el registro de auditoría. Los secretos necesitan cifrado contra un servicio de gestión de claves, ya que el repositorio en sí no es un sitio seguro. Y necesitas un procedimiento de emergencia documentado para cuando la reconciliación sea lo único que se interpone entre tú y arreglar una caída.