Módulo 7: Gitops Beyond Terraform

3. GitOps para Kubernetes: ArgoCD y Flux, nombrados

Descripción

La lección anterior te mostró tres herramientas que resuelven el mismo problema que ya conoces, con otra sintaxis. Esta lección es distinta: ArgoCD y Flux no son "GitHub Actions, pero para Kubernetes" — son un tipo de sistema fundamentalmente diferente, diseñado específicamente para un problema que esta guía nunca tuvo: mantener sincronizado, todo el tiempo, el estado de un clúster de Kubernetes contra lo que Git dice que debería existir. Vas a conocer qué son, cómo se ven sus recursos de configuración, y por qué esta guía los nombra con precisión en vez de simplemente decir "hay otras opciones para Kubernetes" — sin construir ni instalar ninguno de los dos. Esta es una frontera dura: no hay clúster de Kubernetes en esta guía, ni lo va a haber.

Conexión con el módulo

El Módulo 1, lección 4, adelantó esta lección con precisión: "el Módulo 7 (lección 4) retoma esta distinción con el detalle técnico completo" — refiriéndose a push vs. pull. Esta lección (3) es el paso previo necesario: antes de comparar los dos mecanismos en la lección 4, tienes que conocer, con nombre y forma concreta, las dos herramientas que implementan el mecanismo pull en el mundo real. Después de esta lección y la siguiente, la lección 5 se aleja un paso más del terreno de infraestructura, hacia las estrategias de despliegue de una aplicación — otro territorio que Kubernetes hace posible y que Terraform, por diseño, no tiene.

Por qué esta frontera es dura, no blanda

Ya viste fronteras en esta guía —OIDC de punta a punta (Módulo 4), conftest como sistema (Módulo 6)— donde la razón de no construir algo era una limitación técnica puntual de act o del alcance $0. Esta frontera es distinta, y vale la pena que entiendas por qué: ArgoCD y Flux necesitan un clúster de Kubernetes real (o al menos uno local, tipo kind o minikube) para instalarse y correr — no son un binario que corre sobre tu HCL de Terraform, son controladores (software que corre dentro del clúster, observando continuamente su propio estado). No hay una forma de "simular" esto con act, porque act simula runners de GitHub Actions, no clústeres de Kubernetes. Construir esto en profundidad —instalar un clúster, instalar ArgoCD dentro, conectar un repositorio, ver la primera sincronización— es exactamente el contenido de kubernetes-and-eks-in-production-guide, una guía completa dedicada a ese territorio. Esta lección te da el vocabulario y la forma exacta de esas herramientas, para que cuando llegues a esa guía —o a un trabajo real que las use— no sea la primera vez que las ves.

Qué es ArgoCD, con precisión

Según su documentación oficial, Argo CD es "a declarative, GitOps continuous delivery tool for Kubernetes" — una herramienta declarativa de entrega continua GitOps para Kubernetes. Es un proyecto de la Cloud Native Computing Foundation (CNCF), aceptado en 2020 y graduado —el nivel de madurez más alto que otorga la CNCF— en diciembre de 2022, lo que confirma que no es un proyecto experimental: es infraestructura de producción usada por miles de organizaciones.

El mecanismo, en su forma más simple: instalas ArgoCD dentro de tu clúster de Kubernetes (corre como un conjunto de Pods, igual que cualquier aplicación que ese clúster pueda correr). Le dices qué repositorio de Git observar y qué carpeta dentro de ese repositorio contiene los manifiestos de Kubernetes (YAML de Deployment, Service, etc.) que describen el estado deseado. A partir de ahí, ArgoCD compara continuamente ese estado deseado contra lo que existe de verdad en el clúster, y —si syncPolicy.automated está activado— corrige cualquier diferencia automáticamente, sin que nadie ejecute un comando.

El recurso central de ArgoCD se llama Application — un CRD (Custom Resource Definition, la forma en que Kubernetes permite definir tipos de recursos propios más allá de los nativos como Pod o Deployment). Así se ve uno, verificado contra la documentación oficial:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: andes-cargo-shipment-api
spec:
  source:
    repoURL: https://github.com/andes-cargo/shipment-api-manifests.git
    path: k8s/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Lee esto con el mismo ojo con el que lees un resource de Terraform: source dice de dónde viene el estado deseado (un repositorio Git y una carpeta dentro de él); destination dice a dónde aplicarlo (qué clúster, qué namespace); syncPolicy.automated con prune: true y selfHeal: true es la parte más importante de las tres — le dice a ArgoCD que corrija diferencias automáticamente (selfHeal: si alguien cambia algo directamente en el clúster, ArgoCD lo revierte para que coincida con Git) y que borre recursos que ya no están en Git (prune: si un Deployment se elimina del repositorio, ArgoCD lo elimina también del clúster). Esto es, con nombres distintos, exactamente la propiedad #4 de GitOps que ya conoces del Módulo 1 —reconciliación continua— pero llevada a un extremo que drift.yml (Módulo 5) nunca implementó: tu drift.yml detecta y avisa; selfHeal: true de ArgoCD corrige solo, sin intervención humana.

Qué es Flux, con precisión

Según su documentación oficial, Flux es una forma de gestionar infraestructura y aplicaciones de manera que todo el sistema se describa de forma declarativa y versionada, con un proceso automatizado que garantiza que el entorno desplegado coincide con el estado especificado en uno o más repositorios de Git. Igual que ArgoCD, es un proyecto CNCF —de hecho, Flux fue creado por Weaveworks, la misma empresa que acuñó el término "GitOps" en 2017 (Módulo 1, lección 4) — Flux es, en cierto sentido, la implementación de referencia del concepto que le dio nombre a todo este dominio.

Flux se organiza en controladores especializados, más granulares que el Application único de ArgoCD. Los dos recursos más importantes para entender su forma básica:

GitRepository — le dice a Flux qué repositorio observar y con qué frecuencia:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: andes-cargo-shipment-api
  namespace: flux-system
spec:
  interval: 5m0s
  url: https://github.com/andes-cargo/shipment-api-manifests.git
  ref:
    branch: main

Kustomization — le dice a Flux qué hacer con lo que encontró en ese repositorio (Flux usa este nombre porque, por defecto, espera que los manifiestos estén organizados con Kustomize, la herramienta nativa de Kubernetes para componer YAML — no confundir con la Kustomization de esta lección, que es el nombre del controlador de Flux, no de la herramienta de composición en sí):

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: andes-cargo-shipment-api
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: andes-cargo-shipment-api
  path: "./k8s/production"
  prune: true

interval: 5m0s en GitRepository le dice a Flux con qué frecuencia revisar el repositorio en busca de cambios nuevos — ese número (5m0s, formato de duración de Go) es, con otro formato, el mismo tipo de decisión que tomaste en el Módulo 5 con schedule: cron: para drift.yml, solo que aquí controla la sincronización completa, no solo la detección. sourceRef conecta el Kustomization con el GitRepository por nombre — el mismo patrón de "una pieza referencia a otra por nombre" que ya viste con needs: entre jobs de GitHub Actions (Módulo 5, lección 3), aplicado aquí entre dos tipos de recursos de Kubernetes en vez de entre dos jobs de un mismo workflow.

ArgoCD y Flux, por contraste rápido

	ArgoCD	Flux
Origen	Intuit (2018)	Weaveworks (2016-2017, la misma empresa que acuñó "GitOps")
Estado CNCF	Graduado (dic. 2022)	Graduado
Recurso central	`Application` (uno por app)	`GitRepository` + `Kustomization` (separados, más granular)
Interfaz	Dashboard web incluido, muy usado en la práctica	Principalmente CLI (`flux`) y GitOps puro, sin dashboard oficial incluido
Filosofía	Una herramienta completa, visual	Un conjunto de controladores especializados, componibles

Ninguna de las dos "gana" en un sentido absoluto — es una decisión de equipo, parecida en espíritu a la elección de GitHub Actions vs. Jenkins que ya viste: ArgoCD suele preferirse cuando el equipo valora una interfaz visual clara para ver el estado de sincronización de un vistazo; Flux suele preferirse en equipos que quieren componer piezas más pequeñas y especializadas, o que ya usan mucho Kustomize.

El punto que esta lección no puede demostrar, y por qué

No hay un bloque "Qué esperar" en esta lección, y eso es intencional, no un olvido: act no ejecuta clústeres de Kubernetes, así que ningún kubectl apply -f de los YAML de arriba corrió en ningún momento durante la escritura de esta lección. Si quisieras confirmar esta sintaxis por tu cuenta, con $0, la ruta real sería instalar kind (Kubernetes-in-Docker) o minikube en tu máquina, instalar ArgoCD o Flux dentro de ese clúster local, y conectar un repositorio real — el contenido exacto de los primeros módulos de kubernetes-and-eks-in-production-guide. Esta lección te preparó con el vocabulario y la forma exacta para ese momento, no con la experiencia práctica de haberlo hecho.

Errores comunes

Pensar que ArgoCD/Flux son "un GitHub Actions especial para Kubernetes" (el más común). Qué pasa: alguien, después de seis módulos pensando en términos de "un pipeline que corre pasos", asume que ArgoCD también es un pipeline con steps, solo que apuntado a Kubernetes. Por qué pasa: la palabra GitOps aparece en ambos contextos, y el cerebro busca el modelo mental más cercano que ya tiene. Cómo detectarlo: si buscas, en el YAML de Application de arriba, algo parecido a steps: o jobs: y no lo encuentras. Cómo corregirlo: ArgoCD y Flux no tienen "pasos" en el sentido de un pipeline — son controladores que corren continuamente, comparando estado, no un proceso que arranca, corre una secuencia, y termina. La lección 4 profundiza esta diferencia con el detalle técnico exacto.

Confundir el Kustomization de Flux con Kustomize, la herramienta. Qué pasa: alguien lee kind: Kustomization y asume que es exactamente lo mismo que un archivo kustomization.yaml de la herramienta nativa de Kubernetes Kustomize. Por qué pasa: el nombre es, a propósito, el mismo — y no es coincidencia, Flux construye sobre Kustomize. Cómo detectarlo: si no distingues entre "el CRD Kustomization de Flux, que le dice al controlador qué sincronizar" y "el archivo kustomization.yaml que Kustomize usa para componer manifiestos dentro de una carpeta". Cómo corregirlo: son dos cosas relacionadas pero distintas — el Kustomization de Flux (el YAML de esta lección) es la instrucción de sincronización; puede apuntar, path adentro, a una carpeta que sí use kustomization.yaml de Kustomize para componer sus manifiestos, o a una carpeta de YAML plano sin Kustomize en absoluto.

Creer que esta lección te da suficiente para instalar ArgoCD o Flux en un trabajo real (de sobreconfianza, ya visto en la lección 1). Qué pasa: alguien lee los dos YAML de esta lección y se siente listo para configurar GitOps de Kubernetes en producción. Por qué pasa: los ejemplos son concretos y verificados, y eso genera una falsa sensación de completitud. Cómo detectarlo: si no podrías explicar, sin buscarlo, cómo instalar ArgoCD dentro de un clúster (el primer paso, antes de que exista ningún Application que aplicar). Cómo corregirlo: esta lección te da la forma de los recursos y el vocabulario —Application, GitRepository, Kustomization, syncPolicy, selfHeal— no la experiencia de instalación, configuración de RBAC, gestión de secretos dentro del clúster, ni troubleshooting real. Eso es, explícitamente, el contenido de kubernetes-and-eks-in-production-guide.

Ejercicios

Ejercicio 1 — Nombra el recurso central de cada herramienta. Sin mirar esta lección, ¿cuál es el nombre del recurso principal de ArgoCD, y cuáles son los dos recursos principales de Flux que trabajan juntos?

Ver solución

ArgoCD: Application — un único CRD que agrupa source (de dónde viene el estado deseado), destination (a dónde se aplica) y syncPolicy (cómo se sincroniza). Flux: GitRepository (qué repositorio observar y con qué frecuencia) y Kustomization (qué hacer con lo que se encontró ahí, referenciando al GitRepository por nombre vía sourceRef) — dos recursos separados que trabajan en conjunto, en vez del recurso único de ArgoCD.

Ejercicio 2 — Traza la propiedad de GitOps que selfHeal: true implementa. De las cuatro propiedades de GitOps que aprendiste en el Módulo 1, lección 4 (declarativo, Git como fuente de verdad, aplicación automática, reconciliación continua), ¿cuál implementa selfHeal: true de ArgoCD, y en qué se diferencia de cómo esta guía implementó esa misma propiedad?

Ver solución

selfHeal: true implementa la propiedad #4: reconciliación continua contra Git. La diferencia con esta guía: drift.yml (Módulo 5) implementa esa propiedad de forma pasiva — corre terraform plan en un horario y avisa si algo cambió, pero no corrige nada automáticamente (la corrección requiere que alguien revise el plan y apruebe un apply, igual que cualquier otro cambio). selfHeal: true la implementa de forma activa — ArgoCD detecta la diferencia y la corrige por sí solo, sin que nadie apruebe nada, en el momento en que la detecta. Es una decisión de diseño más agresiva, con sus propios riesgos (¿qué pasa si alguien cambió algo en el clúster a propósito, por una razón operativa válida, y ArgoCD lo revierte sin preguntar?) que esta guía no explora, porque está fuera de su alcance.

Ejercicio 3 — Explica por qué esta lección no tiene un bloque "Qué esperar". En dos o tres frases, explicá a un compañero por qué, a diferencia de casi todas las lecciones manos a la obra de esta guía, esta lección no muestra la salida literal de ningún comando ejecutado.

Ver solución

Una explicación completa suena, más o menos, así: "Todo lo que esta guía ejecutó hasta ahora corrió con act, que simula un runner de GitHub Actions dentro de Docker — pero ArgoCD y Flux no son workflows de GitHub Actions, son controladores que corren dentro de un clúster de Kubernetes real (o al menos un clúster local como kind). act no tiene forma de simular eso, así que no hay ningún comando que esta lección pudiera haber corrido de verdad sin instalar primero un clúster completo — exactamente el trabajo que le corresponde a kubernetes-and-eks-in-production-guide, no a esta guía."

Resumen y siguiente paso

En esta lección conociste ArgoCD y Flux con precisión técnica: qué son (herramientas GitOps para Kubernetes, ambas proyectos graduados de la CNCF), cómo se ve su configuración central (Application en ArgoCD; GitRepository + Kustomization en Flux), y por qué selfHeal: true lleva la reconciliación continua un paso más allá de lo que drift.yml implementa en esta guía. Confirmaste, con una frontera dura y explicada, por qué esta lección nombra sin construir: ninguna de las dos herramientas corre sin un clúster de Kubernetes real, algo que está, por diseño, fuera del alcance de esta guía.

Antes de avanzar deberías poder: nombrar el recurso central de ArgoCD y los dos de Flux; explicar qué hace selfHeal: true y en qué se diferencia de drift.yml; y decir, sin dudar, en qué guía del ecosistema aprenderías a instalar y usar cualquiera de las dos de verdad.

La lección 4 toma todo lo que acabas de conocer y lo compara, punto por punto, contra el mecanismo que sí construiste en esta guía — la distinción técnica exacta entre push-based y pull-based GitOps, cerrando el hilo que el Módulo 1 dejó abierto a propósito.

Recursos

Argo CD — Documentation — documentación oficial de ArgoCD, fuente de la definición y el YAML de Application usados en esta lección.
CNCF — Argo — estado de graduación de ArgoCD en la Cloud Native Computing Foundation.
Flux — Concepts — documentación oficial de Flux, fuente de su definición.
Flux — GitRepository y Flux — Kustomization — referencia exacta de los dos CRD usados en esta lección.
CNCF — Flux — estado de graduación de Flux en la CNCF, ya citado en el Módulo 1, lección 4.
kubernetes-and-eks-in-production-guide (NIEVA) — la guía donde ArgoCD y Flux se instalan y usan de verdad, frontera dura de esta lección.

← Anterior2. GitLab CI, CircleCI y Jenkins por contraste Siguiente →4. *Push-based* vs. *pull-based*: dos GitOps, un principio