Flux vs ArgoCD: ¿Por qué deberías usar GitOps KRM-Native?

Basado en el artículo original publicado por Pierre-Gilles Mialon.

Gitops: FluxCD o Nada

Este artículo es con opinión, y muy marcada. Está forjada a través de la experiencia con despliegues de Kubernetes a gran escala, impulsada por debates con colegas, conversaciones con mantenedores de OSS, cientos de estudiantes de CKA/CKAD entrenados... y más de una que otra caída de servicio (outage). 🙃

En una sesión reciente en KubeCon Paris 2024, los oradores intentaron argumentar que KRM no era un modelo viable para la ingeniería de plataforma.

Pero quizás no entendieron el punto. Con lo que realmente estaban luchando... era con ArgoCD.

🧠 ¿Qué es GitOps KRM-Native?

GitOps KRM-Native es más que una palabra de moda — es un patrón de arquitectura. Uno que finalmente aporta verdadera simplicidad a la ingeniería de plataforma.

Es GitOps, impulsado por el Kubernetes Resource Model (KRM), gestionando todo: desde deployments hasta IAM, DNS, bases de datos SQL gestionadas y reglas de firewall — con una única API, un único modelo y una única fuente de verdad en Git.

Con herramientas como Config Connector (GCP), Crossplane, ACK (AWS) o la salida KRM de Pulumi, toda tu infraestructura se convierte en un conjunto de recursos de Kubernetes.

🧱 Todo se declara en YAML.

• ¿Tu Deployment? YAML.
• ¿Tu VPC? YAML.
• ¿Tu Service Account? YAML.
• ¿Tu instancia de CloudSQL? YAML.
• ¿Tu Política de Alerta? YAML.

🎯 Todo es declarativo, inmutable, componible — y versionado en Git.

🌍 Por Qué GitOps KRM-Native Es el Futuro

Un contrato de despliegue para gobernarlos a todos

Como ingeniero de plataforma, estás construyendo un sistema para alojar muchas aplicaciones y servicios, posiblemente desarrolladas por docenas de equipos. Quieres:

• 🔒 Una forma segura y auditable de definir y provisionar infraestructura.
• 🧠 Un modelo entendible por humanos y máquinas.
• 🚀 Una base para habilitar la automatización, la IA y flujos de trabajo inteligentes.
• 🔄 Reducir la complejidad y el trabajo pesado (toil).

KRM cumple con todo esto — porque es:

• 🌐 API-first — Todo es impulsado por controladores de Kubernetes.
• ✍️ Declarativo — Sin scripts, sin desorden imperativo.
• 🔁 Reconciliador — Kubernetes asegura la convergencia al estado deseado.
• 🤖 AI-friendly — Todos los recursos son legibles por máquina en el mismo formato.

Ejemplo: la Aplicación Full-Stack GitOps

Supongamos que estás desplegando un microservicio que necesita:

• Un Deployment de Kubernetes.
• Un Service de GKE con LoadBalancer.
• Una base de datos PostgreSQL en CloudSQL.
• Bindings de IAM para la workload identity.
• Una regla de firewall para el tráfico backend-a-base de datos.
• Alertas y dashboards de monitoreo.

Tradicionalmente, esto significaría:

• Un repo de Terraform.
• Un Helm chart.
• Un ticket al equipo de cloud.
• Un script de devops.
• Y un pobre ingeniero intentando pegar todo (glue everything together).

Con GitOps KRM-Native, todo eso va a un único repo de Git, bajo una estructura de carpetas clara, completamente declarativo. La plataforma reconcilia el resto.

Beneficios:

• 🧩 Modelo unificado: Gestionas todos los recursos de la misma manera.
• 🔍 Visibilidad completa: El grafo de dependencias se vuelve observable.
• 🚨 Listo para AI-OPS: Los servidores MCP pueden razonar sobre tu plataforma.
• 📜 Control de versiones: Cada cambio es rastreado.
• 🛠️ Consistencia operacional: El error humano se reduce. La automatización prospera.

Si alguna vez tuviste que rastrear una caída de producción (outage) hasta un permiso de IAM faltante o una regla de firewall olvidada — verás el valor inmediatamente.

⚖️ Flux vs ArgoCD — O Por Qué Uno Abraza Kubernetes y el Otro Lo Reinventa

Probablemente estás aquí porque has probado GitOps. Quizás ya estás ejecutando ArgoCD en producción. Quizás simplemente lo viste en una demo en una conferencia y pensaste: "¡Wow, esa UI es genial!". Y sí — lo es.

Pero aquí está el giro: esa interfaz brillante viene con equipaje arquitectónico.

🎭 UX vs Verdad: La División Filosófica

Hagámoslo simple:

• Flux: opinionado, minimalista, nativo de Kubernetes.
• ArgoCD: flexible, rico en UI, compatible con Kubernetes.

No es que uno sea mejor en todos los contextos — pero si tu objetivo es GitOps KRM-Native, una de estas herramientas se alinea más profundamente con la filosofía de diseño de Kubernetes. Y no es el que tiene pestañas y gráficos.

🔐 Permisos: Confía en la API, No en la Aplicación

Empecemos con RBAC.

• Flux delega todo al RBAC de Kubernetes. → Sin puertas traseras raras. Sin modelo de permisos duplicado. → Usas kubectl auth can-i y listo.
• ArgoCD introduce su propio modelo de acceso, superpuesto a Kubernetes, permitiendo a los usuarios realizar acciones a través de la UI independientemente de sus permisos dentro del cluster.

¿Suena conveniente? Lo es — hasta que falla. Pregúntale a cualquiera que haya visto a un desarrollador borrar accidentalmente cargas de trabajo de producción a través de la UI de ArgoCD un viernes por la noche.

Historia real:

Un equipo subió un cambio a ArgoCD, editó algo en vivo a través de la UI web (en contra de las mejores prácticas), y rompió la mitad de la plataforma — con un retraso de 24 horas debido a la reconciliación de drift. ¿Adivina en qué día cayó ese período de 24 horas? Sí, domingo.

🔄 Pull vs Push: ¿Quién Posee la Verdad?

El corazón de GitOps es que Git es la fuente de verdad. No un usuario, no un dashboard, no una UI — Git.

• Flux opera en modo pull. Vigila Git, reconcilia continuamente y aplica cambios. Es silencioso, humilde, pero sólido como una roca.
• ArgoCD por defecto usa push. Si bien el pull es técnicamente soportado, la mayoría de las implementaciones usan push por flexibilidad — y velocidad.

¿El riesgo?

Ahora tienes un plano de control mutable, accesible para humanos (y posiblemente sistemas de CI), con permisos amplios y mutación en tiempo real del estado del cluster.

Déjame preguntarte:

• ¿Confías en que una aplicación web accesible tenga las llaves de todos tus entornos?
• ¿Has oído hablar de las vulnerabilidades Zero-Day?
• ¿Puedes probar que ArgoCD no tiene una ahora mismo?

Si tu controlador de GitOps tiene un CVE, quieres que esté aislado y de solo lectura, no sentado frente a tu cluster con modo dios habilitado.

🖥️ UX y Adopción: El Arma Secreta de Argo

Seamos honestos: ArgoCD está ganando corazones con su UI. Se ve genial, funciona bien en demos, y los equipos se sienten productivos.

• ✅ Diff visual
• ✅ Sincronización con un click
• ✅ Indicadores de salud
• ✅ Dashboards de estado

Pero esa conveniencia tiene un costo:

• Aleja la toma de decisiones de Git.
• Fomenta el click-ops (que no es GitOps).
• Rompe los rastros de auditoría a menos que seas extremadamente disciplinado.

Mientras tanto, Flux es... bueno, una herramienta principalmente de CLI. Se integra maravillosamente en GitHub Actions, GitLab CI y pipelines. Se ejecuta como controladores nativos de Kubernetes. Emite eventos. Se integra con SOPS, Kustomize, OCI, Helm, multi-tenancy y modelos de operator.

Flux no se ve bien. Flux funciona bien.

🛠️ Tip: ¿Quieres una UI para Flux? Usa Headlamp — es limpia, respeta el RBAC y es componible.

⚡ Event-Driven vs Polling

Otra diferencia clave: Flux es event-driven. ArgoCD hace polling.

Esto significa:

• En ArgoCD, configuras un intervalo de sincronización (por ejemplo, 3 minutos) y esperas.
• En Flux, un nuevo commit en Git dispara un evento, y todo se reconcilia instantáneamente.

¿Resultado? Flux es más rápido, más reactivo y más nativo de Kubernetes.

Recuerda, Kubernetes no se trata de programar cron jobs — se trata de convergencia reactiva.

🔐 Gestión de Secretos: Flux Es Simplemente Más Inteligente

Gestionar secretos en GitOps es doloroso. Flux abraza esto integrándose con SOPS de forma nativa (out-of-the-box).

• Tus secretos están encriptados en reposo (YAML + PGP/AES/GCP KMS).
• Se commitean a Git — pero de forma segura.
• Se desencriptan solo dentro del cluster.
• Es determinístico, a prueba de auditorías y funciona en CI.

¿El enfoque de ArgoCD?

"GitOps no es para secretos." — Literalmente en la documentación

En cambio, ArgoCD pasa el problema a vaults, sincronizaciones externas o herramientas de side-channel. Buena suerte uniendo eso en un modelo de despliegue unificado.

🆚 GitOps vs Gitless GitOps — O Cómo OCI y la Seguridad Están Dando Forma a la Próxima Frontera

Ah, GitOps. Nos encanta.

• 🧠 Git como la única fuente de verdad.
• 🛠️ CI construye el artefacto.
• 🤖 Las herramientas de CD (como Flux o ArgoCD) sincronizan el estado declarado en Kubernetes.

Pero recientemente, ha surgido un nuevo sabor de las sombras de KubeCon EU 2025 — algo a la vez familiar y radical: Gitless GitOps.

Vamos a desempacarlo.

🛢️ Gitless GitOps: ¿Qué Es?

En resumen, Gitless GitOps reemplaza los repositorios de Git con artefactos OCI (Open Container Initiative) almacenados en registros de contenedores.

En lugar de sincronizar YAMLs desde Git:

• CI construye tus manifests (por ejemplo, con Kustomize o Helm).
• El resultado se empaqueta como un artefacto OCI.
• Ese artefacto se almacena en un registro como ghcr.io, gcr.io, harbor, ArtifactRegistry, etc.
• Las herramientas de CD extraen (pull) y aplican esos bundles OCI directamente.

La fuente de verdad ahora es un artefacto firmado e inmutable, no una rama de Git.

🔒 ¿Por Qué Cambiar Lo Que Funciona?

Porque Git — con toda su grandeza — tiene algunas desventajas en cadenas de suministro de grado de producción:

🔐 1. Seguridad de la Cadena de Suministro de Software

Los flujos de trabajo basados en OCI permiten:

• Firmado de artefactos con cosign.
• Escaneo de vulnerabilidades.
• Publicación de SBOM (Software Bill of Materials).
• Seguimiento de procedencia con niveles SLSA.

Esto hace que Gitless GitOps sea ideal para entornos de alta conformidad: finanzas, salud, defensa.

Con Git, validar que un YAML no fue manipulado es difícil. Con OCI, es criptográficamente verificable.

🧱 2. Replicación de Registros y Resiliencia en el Edge

A diferencia de los servidores de Git, los registros OCI se replican fácilmente entre regiones y zonas.

Esta es una gran ventaja para:

• 🌍 Entornos de edge.
• 🛰️ Sistemas air-gapped.
• 🧪 Disaster recovery.

¿Necesitas desplegar el mismo manifest en 50 clusters de edge? La replicación OCI es tu amigo.

🔐 3. No Se Necesita Acceso a Git en CD

En GitOps tradicional:

• Tu controlador extrae (pull) de Git.
• Gestionas claves SSH, PATs, tokens OAuth.
• Esperas que nadie las secuestre.

En Gitless GitOps:

• Las herramientas de CD extraen (pull) artefactos de solo lectura, preconstruidos, desde tu registro.
• No se necesitan credenciales de Git.
• El acceso se gestiona a través de scopes OCI y tokens de corta duración.

Tu superficie de ataque acaba de reducirse. 🎯

🚀 Mejoras de Rendimiento

Gitless GitOps elimina la sobrecarga del git pull. No más hacer checkout de repos completos. No más parsear cientos de YAMLs en cada sincronización.

Obtienes un único artefacto, firmado, validado y listo para usar.

Eso hace que Gitless sea rápido. Y en CD, velocidad = seguridad.

🔁 ¿Pero Sigue Siendo GitOps?

Sí... y no.

Todavía:

• Mantienes un estado deseado declarado.
• Confías en los controladores para aplicarlo.
• Esperas que la reconciliación asegure la convergencia.

Pero ya no necesitas acceso directo a Git.

Entonces, ¿sigue siendo "GitOps"?

• 👉 Filosóficamente: sí.
• 👉 Técnicamente: Git ya no es un requisito estricto.

🛠️ Flux Abraza Gitless

¿Una razón más por la que FluxCD brilla?

Flux tiene soporte de primera clase para artefactos OCI:

• Puedes definir recursos OCIRepository.
• Referenciarlos en Kustomization.
• Integrar firmado, verificación, promoción.

¿ArgoCD? No tanto. El soporte es experimental, fragmentado y mayormente impulsado por la comunidad.

Si hablas en serio sobre GitOps basado en OCI, Flux está millas por delante.

😬 Consecuencias en el Mundo Real

Los equipos aman ArgoCD... hasta que algo sale mal:

• Un override clickeado en la UI se desvía de Git → se reconcilia tarde → rompe producción.
• Una política mal configurada permite acceso demasiado amplio.
• Una plantilla se edita sin control de versiones.
• Alguien piensa "es solo un campo" — y de repente tus logs desaparecen.

Lo he visto. Probablemente ustedes también.

🛠️ Helm vs Kustomize — O Por Qué Las Plantillas Son El Tipo Incorrecto De Magia

Si la batalla entre ArgoCD y Flux es sobre filosofía, entonces Helm vs Kustomize es sobre artesanía.

Helm es popular. Extremadamente popular. Da a los equipos la ilusión de velocidad, reusabilidad y estructura. Pero bajo el capó... a menudo es un campo minado basado en plantillas que explota bajo presión.

¿Kustomize? Es más silencioso, más opinionado, y a veces frustrante al principio. Pero una vez que lo dominas, nunca miras atrás.

Vamos a desglosarlo.

🧙♂️ Helm: La Ilusión de Simplicidad

Helm es como los frameworks de JavaScript: Lo resuelve todo a la vez — hasta que no lo hace.

• ¿Go templating en YAML? ✔️
• ¿Variables globales pasadas a través de archivos values? ✔️
• ¿Lógica condicional? ✔️
• ¿Rutas de renderizado complejas? ✔️
• ¿Debugging de YAML usando --dry-run y --debug mientras rezas? ✔️

Sí, Helm te da superpoderes. Pero vienen con un precio alto: complejidad a largo plazo.

🚨 Dolor en el mundo real:

• Intentas añadir un flag simple a un chart.
• Ese flag rompe la configuración de otro equipo.
• Introduces sentencias if para manejar casos de uso.
• De repente tienes 20 condicionales.
• Alguien intenta "arreglarlo" con un subchart.
• Ahora tu CI está rota y nadie sabe por qué.

Y cuando falla, ¿adivina quién recibe el pager a las 2 AM?

🪜 Kustomize: Exigente, Pero Honesto

Kustomize adopta un enfoque diferente.

En lugar de renderizar plantillas, compone recursos.

• Sin lógica.
• Sin if/else.
• Solo overlays, patches y transformers.

Es declarativo de principio a fin.

Esto lo hace un poco más difícil al principio — tienes que entender el modelo, planificar tu estructura, escribir tu base correctamente. ¿Pero una vez que eso está hecho?

• ✨ Nunca falla de formas sorprendentes.
• ✨ Puedes leerlo.
• ✨ Tu sucesor puede leerlo.
• ✨ Incluso un robot puede leerlo.

🧩 Composición vs Templating

Aquí está la clave:

Las plantillas requieren interpretación. Las composiciones son solo configuración.

En escenarios de respuesta a incidentes, la simplicidad salva vidas. Si alguna vez tuviste que solucionar problemas en un Helm chart con cinco condicionales anidados mientras tu SLO arde... sabes a lo que me refiero.

Kustomize reduce la carga cognitiva. Puedes ejecutar kustomize build y ver el estado real.

No hay proyección mental. Lo que ves es lo que Kubernetes obtiene.

😴 La Trampa de Helm: La Pereza Disfrazada de Velocidad

Seamos honestos: Helm se usa en todas partes no porque sea bueno — sino porque es fácil de empezar.

La mayoría de las empresas:

• Crean un Helm chart "compartido" para gobernarlos a todos.
• Añaden cientos de condicionales para diferentes apps.
• Lo usan en todas partes hasta que se vuelve inmanejable.

Luego el equipo de SRE pasa los siguientes 6 meses intentando refactorizarlo.

🧨 Pregúntate:

• ¿Cuántos incidentes vinieron de cambios en Helm charts?
• ¿Cuántos secretos se filtraron debido al renderizado de plantillas?
• ¿Cuántos desarrolladores culparon a "Kubernetes" cuando Helm era el verdadero villano?

He visto docenas de plataformas caídas por la complejidad de los Helm charts.

😬 YAML Ya Es Suficientemente Difícil

Seamos honestos: YAML no es la idea de nadie de un formato agradable.

Ahora añade Go templating, lógica sensible a la indentación y anidamiento.

🔁 ¿El resultado? Escribes YAML dentro de strings dentro de Go templates dentro de YAML. ¿Qué podría salir mal?

Kustomize evita todo esto. No es sexy. Pero es limpio.

¿Y no es eso lo que todos queremos cuando estamos solucionando problemas en prod?

⚠️ Cuando Tienes Que Usar Helm

Hay un caso de uso legítimo para Helm: cuando el vendor te da un chart y no puedes evitarlo.

A veces está certificado. A veces es la única instalación soportada. A veces está tan fuertemente acoplado que escribir tus propios manifests sería una locura.

Eso está bien.

Pero incluso aquí, Flux vuelve a ganar.

¿Por qué?

• Flux usa la librería oficial de Helm.
• Flux gestiona releases de Helm de forma nativa.
• Flux soporta el seguimiento adecuado de dependencias con HelmRelease y HelmChart.

Mientras tanto, ArgoCD... renderiza el chart a través de helm template y aplica la salida.

Así es: Argo en realidad no respeta la API de Helm. La simula.

🎻 ¿Helm Como Orquestador? No Tan Rápido…

Aquí hay otro patrón peligroso:

Los equipos usan Helm no solo como un motor de plantillas — sino como un orquestador.

Definen el orden de instalación, dependencias, reintentos, hooks, todo dentro de Helm.

Pero aquí está el problema:

• Kubernetes ya es un orquestador.
• Helm ahora está orquestando recursos que también están siendo orquestados.
• Terminas con reconciliación de reconciliación.

Esta es una receta para drift, duplicación y confusión.

🤖 Orquestación GitOps Real = Operators

Si necesitas orquestación — orquestación real, inteligente y consciente de dependencias — deberías estar usando operators.

Los operators son ciudadanos de primera clase de Kubernetes. Exponen CRDs. Siguen el patrón controller. Respetan la lógica de convergencia.

¿Y la mejor parte?

Se integran limpiamente con GitOps.

Puedes declarar operator, CRDs en Git, reconciliarlos con Flux, y todo se comporta como debería.

No luches contra el modelo. Abrázalo.

💡 Construir Operators Es Más Fácil De Lo Que Piensas

¿Tienes miedo de escribir operators? No lo tengas.

Ni siquiera necesitas Go — a menos que quieras.

• Prueba Shell Operator para prototipos rápidos.
• Usa Operator SDK para lógica de grado de producción.

Un operator bien construido te permite encapsular la lógica una vez y reutilizarla de forma segura. No más hacks de Helm. No más pegamento de CLI. No más "simplemente vuelve a ejecutar el job."

🔐 Los Ingenieros de Plataforma Son Solo Profesionales del Pegamento — Así Que Usa Menos Pegamento

Si has estado en ingeniería de plataforma por más de cinco minutos, probablemente te has dado cuenta de esto:

Nuestro verdadero trabajo no es escribir código — es eliminar el caos con estructura.

Y hacemos eso pegando herramientas juntas. CI con CD. Git con infra. Secretos con apps. DNS con servicios.

Pero aquí está la trampa: Cuanto más pegamento usas, más frágil se vuelve tu plataforma.

🧪 Cuanto Menos Pegamento, Mejor

🧠 Regla general:

El mejor pegamento es el que no necesitas.

En una plataforma GitOps robusta, quieres minimizar la superposición de herramientas:

• ✅ Un repositorio de Git por propósito (infra, apps, etc.)
• ✅ Una CI (por ejemplo, GitHub Actions, GitLab CI)
• ✅ Una CD (Flux 🤓)
• ✅ Un modelo (KRM)
• ✅ Una fuente de estado (Git o OCI)

Cada vez que añades "solo una herramienta más" para llenar un vacío — estás introduciendo:

• Una interfaz que mantener.
• Una superficie de seguridad.
• Un costo cognitivo.
• Una nueva fuente de verdad (también conocida como un nuevo lugar para que se escondan los bugs).

La ingeniería de plataforma no se trata de construir máquinas de Rube Goldberg. Se trata de componer herramientas simples de la forma más simple posible.

🗂️ Nombres de Namespace: Tu Primera UX

Kubernetes usa namespaces. Eso no es opcional — es fundamental.

Malos nombres = mala UX. Y no solo para humanos.

Veamos este comportamiento de DNS:

• foo → resuelve foo en el namespace actual.
• foo.bar → resuelve foo en el namespace bar.
• 👉 Eso es determinístico.
• 👉 Eso es predecible.
• 👉 Eso es tu amigo.

Ahora, esto es lo que no debes hacer:

• 🚫 mynamespace-dev-staging-prod
• 🚫 namespace-team1-infra-env8

¿Por qué?

• Rompe patrones estándar.
• Confunde el descubrimiento.
• Dificulta la automatización.
• Señala que estás sobrecargando un cluster con múltiples entornos 😬.

☠️ Los Peligros de los Clusters Multi-Entorno

Algunos equipos piensan que están ahorrando dinero poniendo dev, staging y prod en el mismo cluster.

No lo están.

En cambio, están pagando con:

• 💥 Incidentes de seguridad.
• 🔥 Despliegues accidentales.
• 👻 Errores fantasma de recursos compartidos.
• 🤯 Lógica de pipeline compleja.

Los clusters son baratos. Los ingenieros no. Los incidentes son caros. También lo son las demandas.

Usa clusters separados por entorno.

Quieres:

• Cluster: prod-eu-west1
• Namespace: payment
• App: api-gateway

🧭 Entonces tu ruta en Git se convierte en:

clusters/prod-eu-west1/payment/api-gateway/

Y tu KRM se aplica limpiamente:

• Namespace: payment
• Kustomization: api-gateway
• GitPath: clusters/prod-eu-west1/payment/api-gateway

🧩 Es sistemático, determinístico, CI-friendly y legible para humanos.

🧠 Propaga las Rutas de Git a Kubernetes

¿La mejor estrategia de GitOps?

Deja que tu estructura de Git defina la estructura de tu cluster.

De esa manera:

• Reduces la complejidad.
• Reduces los errores.
• Haces imposible enrutar mal un despliegue.

¿Quieres que tu CI construya el artefacto correcto, lo suba al cluster correcto y lo aplique en el namespace correcto?

• 👉 No necesitas archivos de configuración.
• 👉 Necesitas rutas consistentes.

Esto también habilita:

• ✅ Lógica de despliegue predecible.
• ✅ Observabilidad más fácil.
• ✅ Mejor control de acceso.
• ✅ Límites de permisos más limpios.

📦 El Contexto Es Rey

Evita repetirte — especialmente en YAML.

Usa ConfigMaps para definir primitivas base como:

• projectId
• environment
• region
• sharedVPC
• dnsZone

Deja que se propaguen a través de overlays.

📌 Decláralo una vez. Refiérelo en todas partes.

De esa manera, ¿cuando tu proyecto de GCP cambia? Actualizas una línea — no 400 archivos YAML.

También es tu boleto dorado para despliegues multi-región. O tu estrategia de Disaster Recovery (DR).

A veces, sin darte cuenta, estás escribiendo tu Plan de Continuidad del Negocio... en YAML. De nada, CIO. 😎

🧬 DRY + GitOps = Poder

Si tus YAMLs están bien estructurados, con valores base comunes y overlays de entorno:

• Solo defines secretos, políticas, labels, límites de recursos una vez.
• Eliminas la repetición.
• Eliminas la ambigüedad.
• Ganas auditabilidad.

Esto hace que tu plataforma sea fácil de replicar, fácil de probar y fácil de escalar.

Ya sea que estés desplegando a dev, staging, prod, o eu-west2, es solo cuestión de cambiar variables de contexto.

✨ El contexto lo es todo. Trátalo como oro.

⚖️ Drift: El Asesino Silencioso — Por Qué La Precisión Es Un Superpoder De Ops

Seamos realistas por un segundo.

🧑💻 A los desarrolladores les encanta la libertad.

🧑🔧 A los operators les encanta la predictibilidad.

Ambos son válidos. Pero cuando eres responsable de ejecutar producción — la precisión lo es todo.

Porque si tu definición no coincide con lo que se está ejecutando en tu cluster...

💥 Ocurre el drift.

💥 ¿Qué Es Drift?

Drift es la diferencia entre:

• Lo que crees que has desplegado (tu estado en Git), y
• Lo que realmente se está ejecutando en Kubernetes.

Es el duende invisible que causa:

• 🔍 Pesadillas de debugging.
• 🧪 Tests rotos.
• 📉 Mentiras de observabilidad.
• 🔄 Comportamiento inesperado después de reinicios.
• 😤 Momentos de "¡Pero funcionaba ayer!".

Drift es la antítesis de GitOps. Y la mayoría de los equipos ni siquiera se dan cuenta de cuánto drift tienen — hasta que es demasiado tarde.

🔄 ¿Por Qué Ocurre el Drift?

El drift se cuela cuando:

• Alguien edita un recurso en vivo a través de kubectl o una UI.
• Un secreto se actualiza fuera de banda (out-of-band).
• Un pipeline de CI aplica algo pero olvida hacer commit.
• Se hacen parches manuales durante incidentes y nunca se reconcilian.
• Los recursos son generados por herramientas que no hacen el viaje de vuelta (round-trip) a Git.

¿El resultado? Tu fuente de verdad ya no es... verdadera.

🛠️ Herramientas GitOps: Cómo Manejan el Drift

Hablemos de las herramientas GitOps y su actitud hacia el drift:

Si valoras la confianza en tu sistema, quieres el primer grupo. Si disfrutas persiguiendo fantasmas, ve con el segundo.

🧠 Operators Piensan en Sistemas

Aquí está la cosa:

Para los devs, el fallo suele ser sobre bugs de lógica.

Para los ops, el fallo suele ser sobre desajuste de estado (state mismatch).

Los devs piensan:

• "¿Por qué esta función no devuelve lo correcto?"

Los ops piensan:

• "¿Por qué este recurso existe en staging, pero no en prod?"
• "¿Por qué este secreto es diferente de lo que está en Git?"
• "¿Por qué este config map sigue aquí cuando fue eliminado hace 2 semanas?"

Estos no son bugs en el código. Son bugs en la realidad de la infraestructura.

🎯 Precisión = Confianza

En Ops, la precisión es supervivencia.

• Un RoleBinding incorrecto → tu app no puede hablar con la DB.
• Una regla de firewall faltante → el tráfico cae silenciosamente.
• Un typo en una env var → la app crashea.
• Un volumen sobrante → los costos se disparan.
• Un secreto desajustado → el login falla en producción.

Por eso herramientas como Flux y Kustomize importan tanto. Te dan fuertes garantías:

• ✅ Lo que está en Git es lo que está en el cluster.
• ✅ Sin drift. Sin sorpresas.
• ✅ Sin estado misterioso.

🔒 Config Sync: El Martillo del Drift

¿Quieres ser aún más estricto?

🛡️ Config Sync de Google incluye un admission controller que:

• Rechaza ediciones manuales a recursos declarados.
• Enforza Git como la única entrada permitida.
• Bloquea kubectl apply si no viene de Git.

Este es el enfoque sin concesiones para la prevención del drift.

Puede sonar rígido — pero en entornos regulados, es una bendición.

🎵 You Can’t Always Get What You Want…

Como dirían los Rolling Stones:

“You can’t always get what you want, But if you try sometimes, you just might find... You get what you need.”

Kustomize + Flux = exactamente eso.

Sin ruido de templating. Sin adivinar. Sin lógica secreta de --dry-run. Solo infraestructura pura, declarativa — que se mantiene declarada.

Eso es lo que necesitas.

🔗 Links y recursos útiles

Get Started with Flux

Get Started with Flux.

flux-iconCreated with Sketch.Flux

GitHub - fluxcd/flux2-kustomize-helm-example: A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm.

A GitOps workflow example for multi-env deployments with Flux, Kustomize and Helm. - fluxcd/flux2-kustomize-helm-example

GitHubfluxcd