La lección anterior terminó con un problema que ni Helm ni Kustomize resuelven. Ambas herramientas solo actúan cuando alguien ejecuta una orden. Si un compañero hace kubectl edit en rutas-norte-pro a las tres de la madrugada para salir de un apuro, ninguna se entera. Si el portátil de quien despliega se estropea, nadie sabe desplegar. Y si la canalización ci-rutasnorte necesita credenciales de administrador del clúster para ejecutar kubectl apply, hemos abierto un agujero de seguridad que contradice el RBAC mínimo que tanto cuidamos en 08-01.

GitOps es la respuesta, y es la conclusión natural de todo lo que llevamos de curso. La idea es sencilla de enunciar y transformadora en la práctica: un agente que vive dentro del clúster, mira un repositorio de Git de forma continua, y se encarga de que el clúster se parezca a lo que dice ese repositorio. Siempre. Sin que nadie ejecute nada.

En esta lección montaremos ese sistema para Rutas Norte con Argo CD, veremos su equivalente en Flux, resolveremos por fin el conflicto entre el HPA y el campo replicas anunciado en 09-01, y cerraremos el problema de los secretos en el repositorio que quedó pendiente desde 03-02.

1. Qué es GitOps y sus cuatro principios
2. Modelo de envío frente a modelo de extracción
3. Deriva de configuración y autocorrección
4. Argo CD: arquitectura e instalación
5. El recurso Application campo a campo
6. App of apps y ApplicationSet
7. Ondas de sincronización y hooks
8. Estados de salud y sincronización
9. Flux: los controladores y sus recursos
10. Argo CD frente a Flux
11. El problema de los secretos
12. Campos que cambian solos: ignoreDifferences
13. Estructura de repositorios y promoción entre entornos
14. Errores comunes y consejos
15. Ejercicios
16. Conclusión

GitOps es un modelo operativo en el que el estado deseado del sistema vive en Git y un agente automatizado lo hace realidad de forma continua. El grupo de trabajo OpenGitOps lo formalizó en cuatro principios:

1. Declarativo: todo el sistema se describe por lo que debe existir, no por los pasos a ejecutar. Ya lo tenemos desde 01-06: Kubernetes es declarativo por diseño.
2. Versionado e inmutable: el estado deseado se almacena de forma que el historial no se pueda alterar. Git es la implementación obvia. La pregunta "¿qué cambió en producción el martes?" pasa de ser una investigación forense a git log.
3. Aplicado automáticamente: los cambios aprobados se aplican sin intervención manual. Nadie ejecuta kubectl apply ni helm upgrade: se fusiona una petición de cambio y el sistema converge.
4. Reconciliado de forma continua: y este es el que lo cambia todo. El agente no se limita a aplicar cuando hay un commit nuevo: comprueba continuamente que el estado real coincide con el deseado y corrige las diferencias.

Ese bucle no para nunca. Cada tres minutos (configurable), el agente se pregunta: "¿el clúster es como dice Git?". Si no lo es, actúa.

Esta es la diferencia arquitectónica clave, y tiene implicaciones de seguridad serias.

En el modelo de envío, la canalización ejecuta kubectl apply contra el clúster y para eso necesita un kubeconfig con permisos. El problema, en detalle:

1. Ese kubeconfig es un secreto almacenado fuera del clúster, a menudo gestionado por otro equipo o por un proveedor externo.
2. Para poder desplegar cualquier cosa en cualquier namespace, suele acabar teniendo cluster-admin. Es lo más fácil, y por eso es lo que hay en la mayoría de las empresas.
3. Cualquiera que pueda modificar la definición de la canalización —un fichero YAML del repositorio de código— puede ejecutar órdenes arbitrarias con esas credenciales. Una petición de cambio maliciosa a un fichero de CI equivale a acceso de administrador a producción.
4. El apiserver tiene que ser alcanzable desde el exterior.
5. Las credenciales hay que rotarlas, auditarlas y revocarlas, y con tres clústeres, tres juegos.

El RBAC mínimo que definimos para ci-rutasnorte en 08-01 mitiga el problema, pero no lo elimina: la canalización sigue teniendo una credencial permanente hacia dentro del clúster.

El cambio es profundo: la credencial más peligrosa desaparece. Si alguien roba el token de escritura en Git, puede hacer un commit... que quedará registrado, será revisable y podrá revertirse.

La deriva de configuración es la diferencia entre lo que dicen tus ficheros y lo que hay realmente en el sistema. Se acumula sin que nadie se dé cuenta. Casos reales de Rutas Norte:

• Durante un incidente del puente de mayo, alguien hizo kubectl scale deploy/api-reservas --replicas=12. Funcionó. Nadie lo llevó al manifiesto. Tres semanas después, un despliegue rutinario devolvió el Deployment a 4 réplicas y el servicio se saturó.
• Se cambió un límite de memoria con kubectl edit para probar una hipótesis. Se quedó así seis meses.
• Se añadió una anotación al Ingress para ajustar un tiempo de espera. Cuando se recreó el clúster de pre, desapareció y nadie supo por qué el comportamiento cambió.

Con GitOps, kubectl scale deploy/api-reservas --replicas=12 en producción tiene otro desenlace. Tres minutos después:

Ha vuelto a 4. Y eso es exactamente lo que queremos. No es que la máquina sea tozuda: es que si 12 réplicas era la decisión correcta, tiene que estar en Git, donde queda revisada, documentada y presente la próxima vez que se recree el entorno.

El cambio cultural que esto provoca es más importante que la tecnología: la única forma de cambiar producción es a través de una petición de cambio. Al principio genera fricción; a los dos meses, nadie quiere volver atrás.

La autocorrección es una decisión, no una obligación. Argo CD permite activar selfHeal por aplicación. En rutas-norte-dev puede convenir dejarlo desactivado para que la gente experimente; en rutas-norte-pro debe estar activado.

Detalle clave: el controlador de aplicaciones es el único que necesita permisos sobre los objetos del clúster. El servidor de API solo gestiona recursos de Argo CD. Esa separación importa para el RBAC.

La instalación coherente con lo aprendido es por Helm (10-03), con valores versionados:

En producción, el usuario admin se desactiva y se usa un proveedor de identidad (OIDC, SSO corporativo). El RBAC de Argo CD se configura aparte del de Kubernetes, en el ConfigMap argocd-rbac-cm:

Y se registra el repositorio con una credencial de solo lectura: Argo CD nunca escribe en el repositorio de manifiestos. Es el privilegio mínimo de 08-01 aplicado aquí.

Application es un CRD (06-06). Cada instancia dice: "de este repositorio, esta ruta, a este clúster y namespace, con esta política".

Un AppProject restringe qué puede hacer un grupo de aplicaciones. Es una capa de seguridad esencial cuando varios equipos comparten Argo CD.

Ese clusterResourceWhitelist: [] es importante: significa que ni un error en un manifiesto puede crear un ClusterRole o una StorageClass. Sin él, quien pueda escribir en el repositorio puede escalar privilegios en el clúster.

Argo CD ejecuta internamente helm template, así que no crea releases de Helm: no verás nada en helm list. El estado lo lleva Argo CD, no Helm. Es coherente con GitOps (el estado está en Git), pero sorprende la primera vez.

Un patrón muy útil es el de múltiples orígenes: el chart viene de un repositorio público y los valores del repositorio de la empresa, referenciado con ref: valores y valueFiles: [$valores/plataforma/.../valores-pro.yaml].

Con veinte aplicaciones, crear cada Application a mano y aplicarla con kubectl nos devuelve al problema original. La solución: una Application que gestiona un directorio lleno de Applications.

Esa es la última vez que alguien ejecuta kubectl apply en Rutas Norte. A partir de ahí, añadir una aplicación nueva es añadir un fichero al directorio aplicaciones/ y fusionar la petición de cambio.

Una definición, tres aplicaciones. Hay más generadores, y algunos abren posibilidades notables:

Ese último es espectacular en la práctica: abres una PR con la etiqueta vista-previa y aparece un entorno completo desplegado; la cierras y desaparece solo.

Argo CD aplica los objetos en un orden por tipo (Namespace, CRDs, ConfigMaps, Secrets y al final las cargas). Cuando necesitas un orden propio, usas ondas: argocd.argoproj.io/sync-wave: "-5". Van de menor a mayor, y Argo CD espera a que todos los objetos de una onda estén sanos antes de pasar a la siguiente.

Los hooks son el equivalente de los de Helm (10-03): PreSync, Sync, PostSync, SyncFail y Skip.

Las políticas de borrado son HookSucceeded, HookFailed (no la uses: pierdes los logs) y BeforeHookCreation (recomendada). Y un PostSync con un curl --fail a /salud/listo es una prueba de humo excelente: si falla, la aplicación queda Degraded y Argo CD te avisa aunque los pods estén arrancados.

Argo CD maneja dos estados independientes. Confundirlos es el error conceptual más común.

• Estado de sincronización — ¿el clúster coincide con Git?: Synced, OutOfSync, Unknown.
• Estado de salud — ¿la aplicación funciona?: Healthy, Progressing, Degraded, Suspended, Missing, Unknown.

Son ortogonales. Las cuatro combinaciones importantes:

Argo CD sabe evaluar la salud de los tipos estándar (Deployment, Service, Ingress, StatefulSet, Job, PVC). Para CRDs se escriben evaluadores propios en Lua, en el ConfigMap argocd-cm:

Ojo con argocd app rollback: revierte el clúster, pero no revierte Git. Con selfHeal activo, en tres minutos el agente devolverá el clúster a lo que dice Git y tu rollback desaparecerá. El rollback de Argo CD es una medida de emergencia; el rollback de verdad en GitOps es git revert seguido de una petición de cambio, y Argo CD sincroniza solo.

Flux tiene una filosofía distinta: en vez de una aplicación con interfaz web, es un conjunto de controladores especializados, cada uno con su CRD.

Ese bootstrap es una decisión de diseño interesante: Flux se instala a sí mismo mediante GitOps. Escribe sus propios manifiestos en el repositorio y luego se gestiona desde ahí. Actualizar Flux es hacer un commit.

Para los charts de terceros están HelmRepository y HelmRelease, y a diferencia de Argo CD, Flux sí crea releases de Helm de verdad (aparecen en helm list), con install.remediation y upgrade.remediation como equivalente de --atomic.

Capacidad que Flux tiene de serie y Argo CD solo mediante un proyecto aparte:

Y en el manifiesto se marca qué campo actualizar: newTag: 2.4.1 # {"$imagepolicy": "flux-system:api-reservas:tag"}. Flux detecta una etiqueta nueva en el registro, hace un commit en Git actualizándola, y el ciclo GitOps normal la despliega. El estado sigue en Git: la automatización escribe en Git, no en el clúster.

Elige Argo CD si quieres que desarrollo y soporte puedan ver el estado del despliegue sin aprender kubectl (la interfaz web es una herramienta de comunicación, no un capricho), gestionas varios clústeres desde un punto central, o necesitas la flexibilidad de ApplicationSet.

Elige Flux si prefieres una herramienta ligera operada por CLI y por Git, quieres la automatización de imágenes de serie, necesitas releases de Helm de verdad, o tienes muchos clústeres pequeños y autónomos.

Para Rutas Norte elegimos Argo CD, por dos razones concretas: el equipo de soporte necesita ver el estado de los despliegues sin ser experto en Kubernetes, y ApplicationSet genera los tres entornos desde una definición. Ninguna elección es irreversible: ambas leen los mismos manifiestos de Kustomize y los mismos charts de Helm, así que cambiar afecta a los ficheros de k8s-gitops/, no a k8s/.

Aquí llega la objeción que aparece siempre: si todo va en Git, ¿dónde pongo la contraseña de postgres-reservas?

En 03-02 dijimos que los Secrets están codificados en base64, no cifrados, y que versionarlos requiere una herramienta específica. Ha llegado el momento. Y recuerda: un secreto que ha estado en Git está comprometido para siempre, aunque hagas commit para borrarlo. El historial lo conserva, y cualquiera que haya clonado el repositorio lo tiene.

SOPS cifra los valores de un YAML dejando las claves legibles, usando una clave de un KMS, age o PGP.

Ventaja enorme: los diffs siguen siendo legibles, ves qué clave cambió aunque no su valor. Flux trae soporte nativo (decryption: { provider: sops, secretRef: ... }); en Argo CD hace falta un plugin o ksops, lo que es un punto en contra.

Un controlador en el clúster genera un par de claves. Tú cifras con la pública; solo ese clúster puede descifrar.

El SealedSecret resultante, con su encryptedData, es seguro en un repositorio público. Contrapartidas: el diff no dice nada (todo el bloque cambia aunque cambies una letra), el secreto está atado a un namespace y nombre concretos, y hay que respaldar la clave maestra del controlador o perderás la capacidad de descifrar si recreas el clúster.

La más limpia conceptualmente: el secreto no está en Git de ninguna forma, ni cifrado. En Git hay solo una referencia.

Recomendación para Rutas Norte: External Secrets Operator con Vault. La plataforma maneja datos personales de clientes y credenciales de la pasarela de pagos; la rotación automática y la auditoría de accesos no son lujos. Sealed Secrets es una alternativa razonable para empezar sin infraestructura extra.

Regla que no cambia con ninguna de las tres: si un secreto ha llegado a Git en claro, hay que rotarlo. Siempre.

Y llegamos al problema que dejamos anunciado en 09-01.

api-reservas tiene un HPA que ajusta spec.replicas entre 4 y 20 según la carga. El manifiesto en Git dice replicas: 4. Cuando llega el puente de mayo, el HPA sube a 15. Sin nada más:

Argo CD ha bajado a 4 réplicas en plena hora punta. Treinta segundos después, el HPA vuelve a subirlas. Y a los tres minutos, Argo CD las baja otra vez. Es un bucle de guerra entre dos controladores, y el que sufre es el cliente que intenta comprar un billete.

La solución tiene dos partes. Primera: no declarar replicas en el manifiesto, como ya hicimos en 10-04. Segunda: ignoreDifferences, porque aunque el campo no esté en Git, Argo CD compara el objeto vivo con el generado y lo detecta igualmente.

Flux lo resuelve de otra forma: quitando el campo del objeto deseado antes de aplicar, con un patch de op: remove sobre /spec/replicas, de modo que server-side apply no reclama su propiedad y el HPA queda libre.

Consejo de operación: cuando una aplicación aparece OutOfSync de forma persistente y no entiendes por qué, argocd app diff te lo dice en dos segundos. Casi siempre es un campo de esta lista.

Cinco razones para separar código y manifiestos:

El último paso de la canalización, que solo toca dev:

Se promociona el digest, no la etiqueta. Es la garantía de que lo que se probó en pre es bit a bit lo que va a pro. La petición de cambio que promociona a producción es literalmente copiar tres líneas de pre/ a pro/: un diff revisable en diez segundos.

Esa última fila es importante: revertir tiene que ser rápido. Si el procedimiento de vuelta atrás es tan pesado como el de despliegue, la gente evitará revertir y arreglará a mano, que es lo que queríamos eliminar.

Las comprobaciones obligatorias en toda PR son las de 10-04: kustomize build de las tres superposiciones, kubeconform contra el esquema, kyverno apply de las políticas (08-03) y argocd app diff comentado automáticamente en la PR.

Esta es la anécdota que convence a los escépticos, y ocurre en todas las empresas que adoptan GitOps. Una persona de soporte, depurando un problema, ejecuta kubectl delete deployment api-reservas -n rutas-norte-pro. Se le hiela la sangre.

Treinta y siete segundos. Los pods vuelven, la configuración es exactamente la correcta, y hay un registro de lo que pasó.

Ese día el equipo entiende que el repositorio no es una copia de la documentación del clúster: es el clúster. El clúster es solo la proyección actual, y es reemplazable. La prueba definitiva, que conviene ensayar una vez al año: destruir rutas-norte-pre, crear un clúster nuevo, instalar Argo CD y aplicar una Application, la raíz. En veinte minutos está reconstruido entero: namespaces, aplicaciones, políticas, monitorización, certificados. Los datos se restauran aparte con Velero (05-06), pero la plataforma se reconstruye sola.

1. Olvidar el finalizador resources-finalizer.argocd.argoproj.io. Sin él, borrar una Application deja todos sus objetos huérfanos en el clúster, sin nadie que los gestione.

2. Activar prune: true sin entender el alcance. Si te equivocas en path y apunta a un directorio vacío, Argo CD borrará todo lo que gestionaba. Protégete con allowEmpty: false y prueba siempre en dev primero.

3. selfHeal peleando con el HPA. El bucle del apartado 12. Quita replicas del manifiesto y añade ignoreDifferences. Ambas cosas.

4. targetRevision: HEAD o main en producción. Cualquier commit a main se despliega inmediatamente en rutas-norte-pro. Usa una etiqueta o un commit fijo, y promociona conscientemente.

5. Poner secretos en el repositorio "de momento, ya lo arreglaremos". No se arregla, y el secreto queda en el historial para siempre. Monta SOPS, Sealed Secrets o External Secrets antes del primer despliegue.

6. Dar a la credencial de Argo CD permisos de escritura en Git. Solo necesita leer.

7. No configurar AppProject y dejar todo en default. El proyecto default permite desplegar cualquier cosa en cualquier namespace desde cualquier repositorio: quien pueda escribir en el repositorio de manifiestos puede escalar a administrador del clúster.

8. Confundir Synced con Healthy. Synced + Degraded significa que el despliegue funcionó y la aplicación está rota: mira los pods, no el repositorio.

9. Usar argocd app rollback creyendo que resuelve el problema. Revierte el clúster, no Git. Con selfHeal, en tres minutos vuelve el estado malo. El rollback real es git revert.

10. Todo en una sola Application gigante. Cuando algo falla, toda la aplicación queda Degraded y no sabes qué. Divide por componente o por capa, con ondas para el orden.

11. Editar en producción "solo esta vez, es una urgencia". Se revertirá solo. Si el cambio es correcto, la vía rápida es una PR con una aprobación, que tarda dos minutos. Prepara ese procedimiento antes de necesitarlo.

12. No monitorizar el propio Argo CD. Si el controlador está caído, nada se sincroniza y no te enteras. Alerta sobre argocd_app_info{sync_status="OutOfSync"} sostenido y sobre la salud de los pods de argocd (07-04).

13. Ondas de sincronización sin comprobaciones de salud. Argo CD pasa a la onda siguiente cuando la anterior está sana; si el objeto no tiene evaluador de salud (un CRD sin resource.customizations), pasa inmediatamente y el orden no sirve de nada.

Escribe un ApplicationSet que genere las tres aplicaciones de Rutas Norte con estas diferencias: dev sincroniza automáticamente desde main sin selfHeal; pre desde main con selfHeal y poda; pro desde la etiqueta release-2.4 con selfHeal, poda y server-side apply. Los tres deben ignorar spec.replicas de los Deployments. Añade el AppProject que restrinja el despliegue a los tres namespaces y prohíba crear recursos de ámbito de clúster.

rutas-norte-pro lleva dos días en OutOfSync aunque nadie ha tocado nada. Describe el procedimiento completo de diagnóstico con las órdenes exactas, identifica al menos tres causas posibles con lo estudiado en el curso, y escribe el ignoreDifferences que las resolvería.

Diseña las anotaciones necesarias para que un despliegue ocurra en este orden: (1) namespace y cuotas, (2) ExternalSecrets y ConfigMaps, (3) migración de esquema antes que nada más, (4) postgres-reservas y redis-cache, (5) api-reservas, (6) tienda-web, (7) Ingress, (8) HPA y PDB, y una prueba de humo final que marque la aplicación como degradada si falla. Explica qué pasa si la migración falla.

Solución 1

Solución 2

Solución 3

Si la migración falla: el hook PreSync no completa, así que Argo CD aborta la sincronización sin aplicar ningún manifiesto. El clúster queda exactamente como estaba, sirviendo la versión anterior. La aplicación aparece Sync Failed y el Job sigue existiendo (por BeforeHookCreation), de modo que kubectl logs job/migracion-esquema -n rutas-norte-pro da el motivo. Es el mismo comportamiento protector que los hooks de Helm de 10-03.

GitOps cierra el círculo que abrimos al principio del módulo. Rutas Norte ha pasado de 120 ficheros aplicados a mano desde un portátil a un sistema donde el repositorio es la fuente de verdad y el clúster converge hacia él continuamente.

• Los cuatro principios —declarativo, versionado e inmutable, aplicado automáticamente, reconciliado de forma continua— son el contrato. El cuarto es el que lo cambia todo.
• El modelo de extracción elimina la credencial más peligrosa: ci-rutasnorte ya no necesita acceso al clúster, solo escribir en un repositorio Git, y el apiserver deja de tener que ser accesible desde fuera.
• La deriva de configuración se detecta y se corrige sola. El cambio cultural que provoca —"la única forma de cambiar producción es una petición de cambio"— vale más que la tecnología.
• Argo CD con su Application, sus AppProject que limitan el alcance, el patrón app of apps que reduce el trabajo manual a un único kubectl apply en toda la vida del clúster, y los ApplicationSet que generan los tres entornos desde una definición. Las ondas y los hooks ordenan el despliegue y protegen la migración de esquema.
• Flux ofrece lo mismo con controladores especializados, releases de Helm reales y automatización de imágenes integrada. La elección no es irreversible: leen los mismos manifiestos.
• Los secretos tienen tres soluciones prácticas: SOPS (diffs legibles), Sealed Secrets (sin infraestructura extra) y External Secrets Operator (el secreto nunca llega a Git, con rotación automática). Para Rutas Norte, la tercera.
• Y el conflicto entre el HPA y replicas que arrastrábamos desde 09-01 queda resuelto: fuera del manifiesto e ignoreDifferences en la Application, junto con toda la familia de campos que otros controladores modifican.

Nos queda una pieza del ecosistema. Todo lo que hemos montado tiene que correr en algún sitio, y en 10-02 vimos lo que cuesta operar un clúster propio. En la siguiente lección, Kubernetes Gestionado: EKS, AKS y GKE, veremos qué te ahorra un proveedor de nube y qué sigue siendo tuyo: el modelo de responsabilidad compartida, la comparación honesta de los tres grandes, la federación de identidad que dejamos pendiente en 03-06, el uso de instancias interrumpibles para worker-notificaciones e informes-ocupacion, y el criterio de decisión final para Rutas Norte.