Configuré Argo CD en Kubernetes local — Así es como lo hice

Configuré Argo CD en Kubernetes local — Así es como lo hice

El pod llevaba once días corriendo. Estable. Saludable. Haciendo su trabajo silenciosamente dentro de mi clúster local de Kubernetes. Lo eliminé a propósito. Seis segundos después, un pod completamente nuevo apareció en su lugar. Misma especificación, misma configuración, cero tiempo de inactividad. No toqué kubectl apply. No activé ningún pipeline. No hice absolutamente nada. Argo CD vigilaba mi repositorio Git, vio que el estado deseado decía "este pod debe existir," y lo trajo de vuelta a la vida antes de que pudiera cambiar de pestaña en el navegador. Ese momento — ver un pod eliminado resucitar por sí solo en un clúster local de Docker Desktop corriendo en mi MacBook — fue cuando GitOps dejó de ser un concepto abstracto que había leído en posts del blog de CNCF y se convirtió en algo que podía sentir. Algo visceral. Tu repositorio Git se convierte en la única fuente de verdad, y Kubernetes se adapta para coincidir. No eventualmente. No después de que un pipeline se ejecute. Ahora mismo. Llevaba meses queriendo configurar Argo CD. Seguía posponiéndolo para "el próximo fin de semana." La suposición era que sería complicado — las herramientas de nivel producción generalmente lo son. Pensé que necesitaría un clúster en la nube, un pipeline CI/CD ya configurado, quizás toda una tarde peleando con Helm charts y configuraciones RBAC. La configuración real tomó menos de diez minutos. Y el proyecto que usé para probarlo — infrawhisper, una plataforma de datos e IA que estoy construyendo con componentes como un servidor API, motor de IA, procesador de flujos y un panel en tiempo real — me dio una prueba de estrés perfecta para ver si Argo CD podía manejar un despliegue local genuinamente complejo. Aquí está todo lo que hice, todo lo que aprendí, y la trampa de Docker Desktop que casi descarrila todo el proceso.

Por qué finalmente dejé de ejecutar kubectl apply a mano

Tengo una confesión. Durante un tiempo vergonzosamente largo, mi flujo de trabajo de despliegue para Kubernetes local se veía así:

1. Cambiar código
2. Construir imagen Docker
3. Ejecutar kubectl apply -f deployment.yaml
4. Darme cuenta de que olvidé actualizar el tag de la imagen
5. Editar el YAML, aplicar de nuevo
6. Preguntarme por qué los pods antiguos siguen corriendo
7. Eliminar el deployment, aplicar desde cero
8. Repetir mañana con la misma frustración Si has trabajado con Kubernetes durante algún tiempo, conoces este dolor. No es que kubectl apply esté roto — funciona bien. El problema es que te coloca a ti, el humano, en la ruta crítica de cada despliegue. Tú te conviertes en el pipeline. Y los humanos somos pipelines terribles. El problema más profundo es el drift. Aplicas un manifiesto. Un compañero de equipo (o la versión de ti mismo a las 2 AM) hace un cambio manual rápido con kubectl edit. Ahora el estado de tu clúster se ha desviado silenciosamente de lo que está en tu repositorio Git. Nadie lo nota hasta que algo se rompe. Y cuando se rompe, buena suerte averiguando si el estado "correcto" vive en Git, en el clúster, o en el historial de terminal de alguien. GitOps resuelve esto haciendo una regla innegociable: Git es la verdad. El clúster coincide con Git. Siempre. Si divergen, el clúster cambia — no Git. Según una encuesta CNCF End User Survey de mediados de 2025, casi el 60% de los clústeres de Kubernetes ahora dependen de Argo CD para la entrega de aplicaciones. Ese número sube cada trimestre. Y el 97% de los encuestados que usan Argo CD lo ejecutan en producción — frente al 93% en 2023. Esta ya no es una herramienta experimental. Es la forma estándar en que los equipos serios despliegan en Kubernetes. Pero la mayoría de las guías que encontré asumían que estás corriendo EKS o GKE. Un clúster de producción con networking adecuado, balanceadores de carga y controladores ingress ya configurados. Yo quería saber: ¿funciona esto en Docker Desktop? ¿En un clúster local donde estás experimentando, rompiendo cosas y aprendiendo? La respuesta es sí — con un workaround importante que te mostraré en el paso dos.

Qué hace realmente Argo CD (El modelo mental que importa)

Antes de recorrer la instalación, quiero darte el modelo mental que hizo que todo encajara para mí. Porque los comandos son simples. Entender por qué funcionan es lo que separa a alguien que instala Argo CD de alguien que realmente lo usa bien. Argo CD es un controlador de Kubernetes. Se ejecuta dentro de tu clúster como un conjunto de pods — un servidor, un servidor de repositorios, un controlador de aplicaciones y algunos servicios de soporte. Una vez instalado, lo apuntas a un repositorio Git y le dices: "Este directorio contiene el estado deseado de mi aplicación. Vigílalo." Desde ese momento, Argo CD opera en un bucle de reconciliación continua:

1. Observar — Consultar el repositorio Git en busca de cambios (o recibir notificaciones webhook)
2. Comparar — Calcular la diferencia entre el estado deseado en Git y el estado real en el clúster
3. Actuar — Si difieren, alertarte (sincronización manual) o aplicar automáticamente los cambios (sincronización automática) Ese tercer paso es donde vive la magia. Con auto-sync habilitado, el flujo de trabajo se convierte en:

Push a Git → Argo CD detecta cambio → Despliega automáticamente → Se auto-repara si ocurre drift

Ningún pipeline CI/CD activando un paso de despliegue. Ningún humano ejecutando comandos. Haces push del código y el clúster converge para coincidir. El ciclo de retroalimentación es tan ajustado que cambió por completo mi forma de pensar sobre los despliegues. Esto es lo que lo hizo concreto para mí: hice push de una actualización de Helm chart a mi repositorio infrawhisper a las 23:15. A las 23:15 y unos ocho segundos, Argo CD ya había sincronizado el cambio y los nuevos pods estaban desplegándose. Ni siquiera salí de mi editor de código. El mensaje de commit apareció en el panel de Argo CD — feat(deploy): add Argo CD application manifest for GitOps deployment — y el estado de sincronización decía "Sync OK." Ese nivel de inmediatez hace que los despliegues manuales se sientan como enviar instrucciones de despliegue por paloma mensajera. Una cosa más sobre el modelo mental. Argo CD no solo despliega. Vigila activamente el drift. Si alguien (o algo) cambia el estado del clúster fuera de Git — un kubectl edit manual, un script no autorizado, una eliminación accidental — Argo CD detecta la diferencia y la corrige. El clúster se sana a sí mismo. Demostraré que esto funciona con una prueba en vivo más adelante en este artículo. Pero primero, pongámoslo en marcha.

La configuración completa: Argo CD en Docker Desktop Kubernetes

Requisitos previos — Lo que necesitas antes de empezar

Necesitas exactamente dos cosas:

• Docker Desktop con Kubernetes habilitado (Configuración → Kubernetes → Enable Kubernetes → Apply & Restart). Estoy usando Docker Desktop en macOS, pero los pasos son idénticos en Windows y Linux.
• kubectl configurado y apuntando a tu clúster Docker Desktop. Verifica con:

kubectl config current-context
# Debería mostrar: docker-desktop

Si ves un contexto diferente, cambia con kubectl config use-context docker-desktop. No quieres instalar Argo CD accidentalmente en un clúster de producción. Pregúntame cómo sé que vale la pena verificar esto. Eso es todo. No se requiere Helm para la instalación básica. No se necesita cuenta de proveedor cloud. No se necesita balanceador de carga. El Kubernetes integrado de Docker Desktop es suficiente.

Paso 1 — Instalar Argo CD en tu clúster

Dos comandos. El primero crea un namespace dedicado. El segundo descarga los manifiestos oficiales de Argo CD e instala todo.

kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Esto instala Argo CD v3.3.4 (la versión estable a marzo de 2026), que incluye hooks PreDelete, actualización de tokens OIDC en segundo plano, controles RBAC mejorados e integración con KEDA. El manifiesto despliega varios componentes en el namespace argocd:

• argocd-server — El servidor API y la interfaz web
• argocd-repo-server — Clona y procesa tus repositorios Git
• argocd-application-controller — El motor de reconciliación que vigila el drift
• argocd-redis — Capa de caché
• argocd-dex-server — Autenticación SSO (opcional para configuraciones locales) Espera unos 60-90 segundos a que todos los pods alcancen el estado Running. Puedes verlos arrancar:

kubectl get pods -n argocd -w

Cuando veas cinco o seis pods mostrando 1/1 Running, estás listo para el siguiente paso. Y el siguiente paso es el que me tuvo atascado durante buenos veinte minutos.

Paso 2 — Eliminar las NetworkPolicies (La trampa de Docker Desktop)

Este es el paso que ninguna guía de "inicio rápido" mencionaba. Instalé Argo CD, intenté acceder a la UI y no obtuve nada. Connection refused. Timeout. Los pods estaban corriendo, el servicio existía, pero el port-forwarding simplemente... no funcionaba. Después de veinte minutos revisando selectores de servicio y logs de pods, encontré el problema: Argo CD viene con recursos NetworkPolicy que restringen el tráfico entre sus componentes. En un clúster real con un plugin CNI que soporte NetworkPolicies (Calico, Cilium, etc.), funcionan perfectamente. ¿En el networking integrado de Kubernetes en Docker Desktop? Rompen todo silenciosamente. El CNI predeterminado de Docker Desktop no aplica NetworkPolicies, pero las políticas aún se crean y pueden interferir con el descubrimiento de servicios de maneras sutiles. La solución es simple:

kubectl delete networkpolicies --all -n argocd

Eso es todo. Un comando. Veinte minutos de mi vida que no recuperaré. Escribo esto para que tú no pierdas los mismos veinte minutos.

Después de ejecutar esto, el port-forwarding funciona inmediatamente. Si estás ejecutando un clúster real con Calico o Cilium, sáltate este paso — quieres mantener esas políticas.

Paso 3 — Acceder al panel de Argo CD

Ahora expón el servidor Argo CD a tu máquina local:

kubectl port-forward svc/argocd-server -n argocd 8443:443

Abre tu navegador y navega a https://localhost:8443. Recibirás una advertencia de certificado — es lo esperado para un certificado autofirmado en localhost. Haz clic para continuar. Deberías ver la pantalla de inicio de sesión de Argo CD. Limpia. Minimalista. Esa interfaz oscura que señala "esta es una herramienta seria."

Paso 4 — Obtener tus credenciales de acceso

El nombre de usuario predeterminado es admin. La contraseña inicial se genera automáticamente y se almacena como un secret de Kubernetes. Extráela con:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Copia esa salida — es tu contraseña temporal. Inicia sesión con admin y la contraseña decodificada. Consejo profesional: Cambia esta contraseña inmediatamente después del primer inicio de sesión, especialmente si alguien más tiene acceso a tu red. En un entorno de desarrollo local es menos crítico, pero construir buenos hábitos importa. Puedes cambiarla a través de la CLI de Argo CD o en la UI bajo User Info → Update Password. En este punto, tienes una instalación de Argo CD completamente funcional corriendo en tu clúster local de Kubernetes. El panel está vacío — sin aplicaciones todavía. Eso cambia ahora.

Paso 5 — Crear tu manifiesto de Application

Aquí es donde Argo CD se conecta a tu repositorio Git y comienza a gestionar tus despliegues. Necesitas un manifiesto Application — un recurso personalizado de Kubernetes que le dice a Argo CD qué vigilar y dónde desplegar. Aquí está el manifiesto que usé para mi proyecto infrawhisper:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-repo.git
    targetRevision: main
    path: deploy/helm/my-app
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Permíteme explicar qué hace cada sección, porque entender estos campos te ahorra horas de depuración después: source — Dónde debe buscar Argo CD tus manifiestos:

• repoURL: Tu repositorio Git (los repositorios públicos funcionan directamente; los privados necesitan credenciales configuradas en los ajustes de Argo CD)
• targetRevision: Qué rama seguir. Yo uso main, pero puedes apuntarlo a cualquier rama, tag o SHA de commit
• path: El directorio dentro del repositorio que contiene tus manifiestos de Kubernetes o chart de Helm
• helm.valueFiles: Si estás usando Helm (yo sí), esto especifica qué archivo de valores aplicar destination — Dónde debe desplegar Argo CD:
• server: La URL del servidor API de Kubernetes. https://kubernetes.default.svc significa "despliega en el mismo clúster donde Argo CD está corriendo." Para configuraciones locales, esto es siempre lo que quieres.
• namespace: El namespace destino para los recursos de tu aplicación syncPolicy — Cómo debe comportarse Argo CD:
• automated: Habilita auto-sync. Sin esto, tendrías que hacer clic manualmente en "Sync" en la UI cada vez
• prune: true: Si eliminas un recurso de Git, Argo CD lo elimina del clúster. Sin esto, los manifiestos eliminados dejan recursos huérfanos
• selfHeal: true: Este es el más importante. Si alguien o algo cambia el estado del clúster fuera de Git, Argo CD lo revierte. Tu clúster siempre coincide con Git.
• CreateNamespace=true: Argo CD creará el namespace destino si no existe Guarda esto como application.yaml en el directorio de tu proyecto. Ajusta repoURL, path y namespace para que coincidan con tu configuración real.

Paso 6 — Desplegar y observar la magia

Aplica el manifiesto:

kubectl apply -f application.yaml

Ahora cambia a tu panel de Argo CD en https://localhost:8443. En cuestión de segundos, deberías ver tu aplicación aparecer. Argo CD comienza a sincronizar inmediatamente — clonando tu repositorio, renderizando el chart de Helm (o manifiestos simples), y aplicando los recursos a tu clúster. Para mi proyecto infrawhisper, el panel se iluminó con toda la topología de la aplicación: api-server corriendo 3 pods, dashboard con 2 pods, ai-engine con 2 pods, stream-processor con 2 pods, collector con 2 pods, más el infrawhisper-agent y el controlador ingress. Todo visible en una vista de red. El hash del commit 776a48f de mi último push estaba ahí en la UI, con el mensaje de commit que había escrito minutos antes.

La lista de contenedores de Docker Desktop contaba la misma historia desde otro ángulo — 38 contenedores corriendo, con los componentes de argocd junto a mis pods de aplicación: ai-engine, api-server, clickhouse, collector, dashboard, kafka, postgres, redis, stream-processor. Una plataforma de datos completa corriendo localmente, gestionada completamente a través de Git.

Esa es la configuración. Seis pasos, menos de diez minutos. Pero la configuración es solo la base. La verdadera pregunta es: ¿funciona realmente como promete la documentación? Ejecuté tres pruebas para averiguarlo.

La prueba de auto-reparación: Eliminando un pod a propósito

Esta es la prueba que ejecuté para demostrar que la auto-reparación funciona en un clúster local. Tenía mi componente dashboard de infrawhisper corriendo con 2 pods réplica. Un pod específico — dashboard-75fd8b8ddb-55x9h — llevaba 11 días corriendo saludablemente. Estable, sirviendo tráfico, haciendo su trabajo. Lo eliminé.

kubectl delete pod dashboard-75fd8b8ddb-55x9h -n my-app

Luego observé. No el panel de Argo CD — observé la terminal. En seis segundos:

• ANTES: dashboard-75fd8b8ddb-55x9h — Running, Edad: 11 días
• ELIMINADO: Pod terminado
• DESPUÉS: dashboard-75fd8b8ddb-lt5bn — Running, Edad: 6 segundos Un pod completamente nuevo, nombre diferente, misma especificación. El controlador ReplicaSet de Kubernetes se encargó del reemplazo inmediato (eso es comportamiento estándar de Kubernetes). Pero aquí está lo que importa: el bucle de reconciliación de Argo CD confirmó que el estado del clúster aún coincidía con el estado deseado en Git. Si la eliminación del pod hubiera causado que el despliegue general se desviara de la definición de Git — por ejemplo, si alguien hubiera reducido manualmente el número de réplicas — Argo CD también lo habría detectado y corregido. Esto no es resiliencia hipotética. Es medible. Lo vi suceder en mi portátil, en un clúster local, con herramientas que puedes instalar en diez minutos. La implicación más profunda tardó un día en calar. Con la auto-reparación habilitada, tus manifiestos de despliegue en Git no son solo archivos de configuración. Son un contrato. Una promesa sobre cómo debe verse el clúster en todo momento. Rompe el contrato manualmente, y el sistema lo hace cumplir automáticamente. Ese cambio de mentalidad — de "yo despliego cosas" a "yo declaro cosas y el sistema las mantiene" — es el núcleo de GitOps. Y se siente completamente diferente una vez que lo experimentas de primera mano.

Detección de drift: El guardián silencioso

La prueba de auto-reparación cubre eliminaciones accidentales. Pero ¿qué pasa con los cambios manuales intencionales? El tipo de cambios que ocurren cuando alguien ejecuta kubectl edit deployment para "arreglar algo rápidamente" en producción a las 3 AM. Probé esto escalando manualmente mi despliegue api-server de 3 réplicas a 1:

kubectl scale deployment api-server --replicas=1 -n my-app

Durante unos quince segundos, el clúster tuvo 1 pod api-server en lugar de los 3 definidos en mi repositorio Git. Entonces el bucle de reconciliación de Argo CD detectó el drift, comparó el estado real contra Git, y lo escaló de vuelta a 3. Sin alarma. Sin intervención manual. El panel de Argo CD mostró brevemente el estado de la app como "Degraded" (lo cual es preciso — ejecutar menos réplicas de las deseadas es degradado), luego volvió a "Healthy" una vez que la reconciliación se completó. Este es el comportamiento que hace que GitOps sea transformador para los equipos. No solo previene problemas — los corrige activamente. Y crea un registro de auditoría. Cada operación de sincronización aparece en el historial de Argo CD. Puedes ver exactamente cuándo ocurrió el drift y cuándo se corrigió. Intenta conseguir eso con kubectl apply.

Auto-Sync: Push a Git, observa cómo se despliega

La tercera prueba fue la más simple y la más satisfactoria. Cambié un valor en el values.yaml de mi chart de Helm — aumenté el número de réplicas del dashboard de 2 a 3 — hice commit y push a main. Tenía el panel de Argo CD abierto en un navegador y mi terminal ejecutando kubectl get pods -n my-app -w uno al lado del otro. En aproximadamente quince segundos después del push, Argo CD detectó el nuevo commit, descargó el chart actualizado, renderizó los manifiestos y aplicó el cambio. Un tercer pod de dashboard comenzó a arrancar mientras yo observaba. El estado de sincronización en el panel se actualizó para mostrar el nuevo hash del commit. El mensaje de commit que acababa de escribir estaba ahí mismo en la UI. Sin pipeline. Sin configuración de webhook. Sin script de despliegue. Hice push del código y el clúster cambió. Esa es la promesa de GitOps, y en un clúster local de Docker Desktop ejecutando Argo CD v3.3.4, cumplió exactamente como se anunciaba.

Lo que Argo CD hace bien — Y donde es honesto

Después de ejecutar esta configuración durante varios días en mi proyecto infrawhisper, aquí está mi evaluación honesta. Lo que es genuinamente impresionante:

• El panel solo ya justifica la instalación. Ver toda la topología de tu aplicación — cada deployment, servicio, pod e ingress — en un mapa visual es algo que kubectl nunca puede darte. Para mi proyecto infrawhisper con sus más de doce componentes, esto pasó de "estaría bien tenerlo" a "¿cómo trabajaba sin esto?" en unas tres horas.
• La velocidad de sincronización es real. Esperaba minutos. Obtuve segundos. El retraso entre hacer push a Git y ver el cambio en vivo en el clúster fue consistentemente inferior a 20 segundos en mi configuración local.
• El rollback es un clic. Argo CD mantiene un historial de cada sincronización. Si un despliegue sale mal, haces clic en "Rollback" y seleccionas un commit anterior. El clúster revierte. Intenta hacer eso con kubectl apply y una oración.
• El renderizado de Helm charts se hace por ti. No necesité ejecutar helm template ni helm install localmente. El repo-server de Argo CD renderiza el chart y aplica la salida. Esto significa que tu repositorio Git solo necesita el código fuente del chart — Argo CD se encarga del resto. Lo que desearía que alguien me hubiera dicho:
• La sobrecarga de recursos no es trivial. En Docker Desktop, los componentes de Argo CD añadieron aproximadamente 500MB-700MB de uso de RAM y varios núcleos de CPU de actividad en segundo plano. En una máquina moderna, no hay problema. En un portátil más antiguo, lo notarás. Mi Docker Desktop ya estaba ejecutando 38 contenedores para el stack de infrawhisper — añadir los pods de Argo CD encima empujó el uso total de memoria más allá de 8GB.
• Los repositorios privados necesitan configuración adicional. Si tu repositorio Git es privado (la mayoría lo son), necesitas configurar credenciales de repositorio en los ajustes de Argo CD. Esto implica una clave SSH, un token de acceso personal, o una GitHub App. La documentación oficial lo cubre bien, pero es un paso extra que las guías de "instalación con dos comandos" convenientemente omiten.
• El flujo del password inicial del admin es torpe. Decodificar en Base64 un secret de Kubernetes para obtener tu primera contraseña funciona, pero no es una gran experiencia de desarrollador. Me encantaría ver un asistente de configuración interactivo para instalaciones locales.
• Las NetworkPolicies en Docker Desktop son una verdadera pérdida de tiempo. Ya cubrí esto en los pasos de configuración, pero vale la pena repetirlo: si estás ejecutando en Docker Desktop y las cosas no se conectan, elimina las NetworkPolicies primero. Este único problema probablemente causa más configuraciones locales de Argo CD abandonadas que cualquier bug real. Si prefieres que alguien construya este tipo de infraestructura desde cero — clústeres de Kubernetes, pipelines GitOps, todo el stack de ingeniería de plataformas — acepto proyectos de DevOps e ingeniería cloud. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Dónde encaja esto en un flujo de trabajo real

Ejecutar Argo CD localmente no es solo un ejercicio de aprendizaje. Es la primera etapa de un flujo de trabajo que escala directamente a producción. Esta es la progresión que planeo para mi proyecto infrawhisper: Etapa 1 (donde estoy ahora): Clúster local de Docker Desktop con Argo CD gestionando despliegues Helm. Perfecto para desarrollo, probar comportamientos de sincronización y validar manifiestos antes de que toquen un clúster real. Etapa 2: Mover los mismos manifiestos — sin cambios — a un clúster de staging en AWS EKS o un clúster autogestionado. El manifiesto Application de Argo CD permanece idéntico. Solo cambia el destination.server. Etapa 3: Despliegue en producción con Argo CD gestionando múltiples entornos a través de ApplicationSets. Mismo repositorio Git, diferentes archivos de valores por entorno, Argo CD manejando el despliegue a cada uno. La idea clave: el manifiesto Application que escribí en el paso 5 de esta guía no cambia entre etapas. El chart de Helm no cambia. La política de sincronización no cambia. Estoy construyendo el flujo de producción ahora, en mi portátil, con las mismas herramientas que usaré cuando infrawhisper entre en producción. Eso no es un beneficio secundario de Argo CD local — es el beneficio principal. Los ingenieros de plataforma representan ahora el 37% de los usuarios de Argo CD según la encuesta CNCF, y esta es exactamente la razón. Los patrones que estableces localmente se trasladan directamente a producción. No hay un paso de "reescribir el pipeline de despliegue" cuando estés listo para lanzar.

Las cinco cosas que Argo CD te da que kubectl apply nunca podrá

Después de vivir con esta configuración, puedo articular exactamente lo que cambió. No en términos abstractos — en términos concretos de flujo de trabajo diario: 1. Auto Sync elimina el paso de despliegue por completo. Push a Git. Vete. El clúster se actualiza. Esto suena menor hasta que te das cuenta de cuántas veces al día ejecutas kubectl apply. Para mí, eran 15-20 veces durante desarrollo activo. Cada una es un cambio de contexto, una ventana de terminal, una oportunidad de aplicar el manifiesto equivocado en el namespace equivocado. Todo eliminado. 2. La auto-reparación atrapa errores que nunca notarías. Eliminaciones accidentales de pods. Scripts no autorizados. Autoescaladores mal configurados. Argo CD detecta el drift y lo corrige. En mi stack de infrawhisper con más de 10 microservicios, esto no es un lujo — es la diferencia entre un entorno local estable y uno que se deteriora lentamente. 3. La detección de drift crea responsabilidad. Cada cambio manual se revierte y se registra. Esto es seguridad e higiene operacional en uno. Puedes ver quién (o qué) cambió el clúster, cuándo y cómo Argo CD lo corrigió. 4. El panel visual reemplaza una docena de comandos kubectl. Estado de pods, conteo de réplicas, health checks, historial de sincronización, topología de aplicación — todo en una pestaña del navegador. Antes ejecutaba kubectl get pods, kubectl get svc, kubectl describe deployment y kubectl logs en sucesión rápida solo para entender el estado de mi clúster. Ahora miro el panel de Argo CD. 5. El rollback se convierte en un solo clic. No "encontrar el último commit funcional, hacer checkout del manifiesto, aplicarlo, verificar que funcionó." Un clic. Seleccionar el commit. Listo. Para un proyecto como infrawhisper con servicios interdependientes, solo esto justifica la configuración.

Lo que haría diferente la próxima vez

Si tuviera que configurar esto de nuevo desde cero, tres cosas cambiarían: Instalaría la CLI de Argo CD desde el principio. La UI web es excelente para visualización, pero la CLI (argocd) es más rápida para gestionar aplicaciones, sincronizar y verificar estado desde la terminal. No la instalé inicialmente porque quería mantener la configuración mínima, y me arrepentí en menos de un día. Instálala con:

brew install argocd

Usaría ApplicationSets desde el día uno. Mi proyecto infrawhisper tiene un solo manifiesto Application, pero a medida que añada más entornos (staging, producción), necesitaré un Application por entorno. ApplicationSets te permiten crear plantillas de recursos Application — una definición que genera múltiples Applications basadas en parámetros. Empezar con este patrón temprano ahorra una migración después. Configuraría las credenciales del repositorio inmediatamente. Empecé con un fork de repositorio público para pruebas, luego me moví a mi repositorio privado real. El paso de configuración de credenciales interrumpió mi flujo. Configúralo primero, incluso si tu repositorio es actualmente público. Tu yo del futuro te lo agradecerá.

Primeros pasos: La lista de verificación de diez minutos

Aquí está la versión condensada. Si has leído todo lo anterior y solo quieres los pasos en una pantalla:

# 1. Verifica tu contexto de Kubernetes
kubectl config current-context  # Debería ser: docker-desktop
# 2. Instala Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 3. Espera a los pods (unos 60-90 segundos)
kubectl get pods -n argocd -w
# 4. Elimina las NetworkPolicies (¡solo Docker Desktop!)
kubectl delete networkpolicies --all -n argocd
# 5. Port-forward la UI
kubectl port-forward svc/argocd-server -n argocd 8443:443
# 6. Obtén la contraseña de admin
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d
# 7. Inicia sesión en https://localhost:8443 (admin + contraseña decodificada)
# 8. Aplica tu manifiesto Application
kubectl apply -f application.yaml

Ocho comandos. Menos de diez minutos. Un pipeline GitOps completamente funcional corriendo en tu portátil. Argo CD soporta Helm charts, Kustomize, Jsonnet y manifiestos YAML simples — así que sea cual sea tu formato de despliegue actual, se conecta sin reescribir nada. Para mi proyecto infrawhisper, usé Helm porque el chart ya estaba estructurado para despliegues parametrizados. Pero si tienes un directorio de manifiestos YAML sin procesar, simplemente apunta el source.path del Application a ese directorio y elimina la sección helm. Argo CD se encarga del resto.

Preguntas frecuentes

¿Funciona Argo CD con Docker Desktop Kubernetes?

Sí. Argo CD se ejecuta en el Kubernetes integrado de Docker Desktop con un workaround necesario: eliminar las NetworkPolicies predeterminadas en el namespace argocd, ya que el CNI de Docker Desktop no las maneja correctamente. Después de eso, todas las funciones — auto-sync, auto-reparación, detección de drift y el panel web — funcionan de manera idéntica a los clústeres alojados en la nube.

¿Cuánta RAM usa Argo CD en un clúster local?

Espera 500MB-700MB de RAM adicional para los componentes del plano de control de Argo CD (server, repo-server, application-controller, redis, dex). En una máquina con 16GB+ de RAM, es insignificante. En máquinas con 8GB que ejecutan otras cargas de trabajo pesadas, puede que necesites ajustar los límites de recursos en los manifiestos de Argo CD.

¿Puede Argo CD desplegar desde un repositorio Git privado?

Sí, pero necesitas configurar credenciales de repositorio en los ajustes de Argo CD primero. Las opciones incluyen claves SSH, tokens de acceso personal o GitHub Apps. Configúralo a través de la UI de Argo CD (Settings → Repositories) o mediante la CLI argocd antes de crear tu manifiesto Application.

¿Qué pasa si cambio algo manualmente en el clúster?

Con selfHeal: true en la política de sincronización de tu Application, Argo CD detecta el drift y revierte automáticamente el clúster para que coincida con Git. El panel muestra brevemente la aplicación como "OutOfSync" o "Degraded," luego la corrige dentro del siguiente ciclo de reconciliación (típicamente menos de 30 segundos). El evento de drift se registra en el historial de sincronización para auditoría.

¿Es la configuración local de Argo CD igual que la de producción?

Casi idéntica. El manifiesto Application, las políticas de sincronización y la configuración del chart de Helm se transfieren directamente a un clúster de producción. Los únicos cambios son la URL destination.server (apuntando a tu clúster de producción en lugar de kubernetes.default.svc) y los archivos de valores específicos del entorno. Este es uno de los argumentos más fuertes para empezar localmente — construyes patrones de producción desde el día uno.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io