# ArgoCD y GitOps en 2026: Despliegue Continuo en Kubernetes y Preguntas de Entrevista > Tutorial completo de ArgoCD y GitOps para despliegue continuo en Kubernetes. Cubre Application CRDs, sync waves, gestion multi-cluster con ApplicationSets y preguntas frecuentes de entrevista con ejemplos YAML practicos. - Published: 2026-06-05 - Updated: 2026-06-05 - Author: SharpSkill - Tags: argocd, gitops, kubernetes, continuous-deployment, devops, interview - Reading time: 10 min --- ArgoCD se consolido como la herramienta dominante de GitOps para despliegue continuo en Kubernetes. Con la [version 3.4](https://github.com/argoproj/argo-cd/releases) publicada en mayo de 2026, y mas del 64% de las empresas reportando GitOps como su mecanismo principal de entrega, comprender esta tecnologia resulta indispensable para cualquier profesional de DevOps o ingenieria de plataformas. Este articulo recorre los conceptos fundamentales de ArgoCD, los patrones de configuracion que aparecen en entornos productivos y las preguntas de entrevista mas frecuentes para roles de infraestructura y operaciones. > **Que es GitOps?** > > GitOps es una metodologia de despliegue donde Git funciona como la unica fuente de verdad tanto para el codigo de la aplicacion como para la configuracion de infraestructura. Un agente GitOps ejecutandose dentro del cluster reconcilia de forma continua el estado real del cluster con el estado deseado declarado en un repositorio Git, corrigiendo automaticamente cualquier desviacion. ## Como ArgoCD implementa el modelo GitOps ArgoCD opera como un conjunto de microservicios dentro de un cluster de Kubernetes: un servidor API, un servidor de repositorios, un controlador de aplicaciones y una cache Redis. El controlador monitorea los repositorios Git y compara el estado deseado (los manifiestos almacenados en Git) con el estado activo del cluster. Cuando detecta una diferencia, ArgoCD puede emitir una alerta o sincronizar automaticamente segun la politica configurada. Este modelo basado en pull ofrece una ventaja de seguridad significativa frente a los despliegues push tradicionales impulsados por CI. El cluster extrae los cambios desde Git en lugar de exponer un endpoint de entrada para que una herramienta de CI inyecte cambios. Las credenciales del cluster nunca abandonan el perimetro del propio cluster. El primer paso consiste en instalar ArgoCD y definir un recurso Application: ```yaml # argocd-application.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-web-app namespace: argocd spec: project: default source: repoURL: https://github.com/acme/my-web-app-config targetRevision: main path: overlays/production destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true # Remove resources deleted from Git selfHeal: true # Revert manual changes in the cluster syncOptions: - CreateNamespace=true ``` El bloque `source` apunta al repositorio Git que contiene los manifiestos de Kubernetes. El bloque `destination` especifica a que cluster y namespace se despliega. Configurar `automated.selfHeal: true` garantiza que cualquier cambio manual realizado con kubectl se sobreescriba con el estado declarado en Git en cuestion de segundos. ## Sync Waves y Hooks para despliegues ordenados Los despliegues en el mundo real rara vez consisten en un unico manifiesto. Las migraciones de base de datos necesitan ejecutarse antes de que los pods de la aplicacion inicien. Los ConfigMaps y Secrets deben existir antes de que los Deployments los referencien. ArgoCD resuelve esto con sync waves y resource hooks. Las sync waves asignan un orden numerico a los recursos. Los numeros mas bajos se despliegan primero, y ArgoCD espera a que cada wave alcance un estado saludable antes de avanzar a la siguiente: ```yaml # migration-job.yaml apiVersion: batch/v1 kind: Job metadata: name: db-migrate annotations: argocd.argoproj.io/sync-wave: "-1" # Runs before wave 0 argocd.argoproj.io/hook: PreSync # Executes before main sync argocd.argoproj.io/hook-delete-policy: HookSucceeded spec: template: spec: containers: - name: migrate image: acme/my-web-app:latest command: ["python", "manage.py", "migrate"] restartPolicy: Never ``` El hook `PreSync` ejecuta el Job de migracion antes de que ArgoCD aplique los manifiestos principales de la aplicacion. La politica de eliminacion `HookSucceeded` limpia el Job despues de completarse exitosamente. ArgoCD 3.3 introdujo los hooks `PreDelete`, resolviendo el problema recurrente de recursos huerfanos durante la eliminacion de aplicaciones. ## Gestion multi-cluster con ApplicationSets Administrar decenas de clusters desde una unica instancia de ArgoCD requiere algo mas que copiar y pegar manifiestos Application. Los [ApplicationSets](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/) generan recursos Application de forma dinamica a partir de plantillas y generadores: ```yaml # applicationset-clusters.yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-web-app-all-clusters namespace: argocd spec: generators: - clusters: selector: matchLabels: env: production template: metadata: name: 'my-web-app-{{name}}' spec: project: default source: repoURL: https://github.com/acme/my-web-app-config targetRevision: main path: 'overlays/{{metadata.labels.region}}' destination: server: '{{server}}' namespace: production syncPolicy: automated: prune: true selfHeal: true ``` El generador de clusters itera sobre todos los clusters registrados que coinciden con la etiqueta `env: production` y crea una Application por cada uno. Los placeholders `{{name}}`, `{{server}}` y `{{metadata.labels.region}}` se resuelven a partir de los datos de registro del cluster. Agregar un nuevo cluster de produccion a ArgoCD dispara automaticamente el despliegue de la aplicacion en ese cluster sin intervencion adicional. ## ArgoCD vs Flux: como elegir la herramienta GitOps adecuada La comparacion entre ArgoCD y Flux es uno de los temas mas recurrentes en [entrevistas de DevOps](/technologies/devops/interview-questions/kubernetes-basics). Ambos son proyectos graduados de la CNCF que implementan el patron GitOps, pero difieren en arquitectura y compromisos de diseno: | Caracteristica | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Arquitectura | Servidor centralizado con UI | Controladores distribuidos por cluster | | Interfaz web | Dashboard integrado | Sin UI nativa (opciones de terceros) | | Soporte Helm | Renderizado de plantillas en servidor | Integracion nativa con Helm SDK | | Multi-cluster | Hub-and-spoke desde instancia unica | Instalacion independiente por cluster | | RBAC | Nivel de aplicacion con SSO | Solo RBAC nativo de Kubernetes | | Automatizacion de imagenes | Componente Image Updater separado | Reflector/automatizacion de imagenes integrado | | Entrega progresiva | Integracion con Argo Rollouts | Integracion con Flagger | | Huella de recursos | Mayor (API server, repo server, Redis) | Menor (solo controladores necesarios) | ArgoCD se adapta mejor a equipos que valoran la visibilidad centralizada, un dashboard web robusto y RBAC granular a nivel de aplicacion. Flux se adapta a equipos que operan entornos edge o con restricciones de recursos, o que dependen fuertemente de las capacidades nativas del ciclo de vida de Helm. Algunas organizaciones [utilizan ambas herramientas](https://codefresh.io/learn/argo-cd/argo-cd-vs-flux-6-key-differences-and-how-to-choose/): ArgoCD para despliegues de aplicaciones donde la interfaz visual aporta valor, y Flux para componentes de infraestructura donde la operacion distribuida y la fidelidad con Helm resultan prioritarias. ## Estructura de repositorios para GitOps en produccion Un error frecuente en la adopcion de GitOps consiste en almacenar los manifiestos de Kubernetes junto al codigo fuente de la aplicacion. Separar el repositorio de configuracion del repositorio de la aplicacion proporciona un historial de Git mas limpio, ciclos de revision independientes y triggers de CI mas simples: ``` # Recommended repository structure my-web-app-config/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ staging/ kustomization.yaml # Patches for staging replica-count.yaml production/ kustomization.yaml # Patches for production replica-count.yaml hpa.yaml ``` El directorio base contiene los manifiestos compartidos. Cada overlay aplica parches especificos del entorno mediante [Kustomize](https://kustomize.io/). El pipeline de CI compila y publica la imagen del contenedor, luego actualiza el tag de imagen en el repositorio de configuracion. ArgoCD detecta el commit y sincroniza la nueva version al cluster. > **Reconciliacion activada por webhooks** > > Configurar receptores de webhooks desde GitHub, GitLab o Bitbucket permite activar la reconciliacion de ArgoCD de forma inmediata ante cada push. Esto elimina el intervalo de polling predeterminado de 3 minutos y logra deteccion de despliegues en menos de 10 segundos. Se recomienda mantener el intervalo de polling en 5-10 minutos como mecanismo de respaldo. ## Funcionalidades de ArgoCD 3.4 que conviene conocer ArgoCD 3.4, publicado en mayo de 2026, se enfoca en operaciones de Day 2 con funcionalidades que aparecen con frecuencia en entrevistas para roles senior de DevOps: **Pausa de reconciliacion por cluster** permite a los operadores congelar la sincronizacion de ArgoCD durante incidentes en produccion. Esto evita que ArgoCD revierta hotfixes de emergencia aplicados directamente al cluster mientras el equipo resuelve el problema: ```yaml # Pause reconciliation on a specific cluster apiVersion: v1 kind: Secret metadata: name: prod-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster annotations: argocd.argoproj.io/pause-reconciliation: "true" stringData: server: https://prod-cluster.example.com config: | { "tlsClientConfig": { "insecure": false } } ``` **Globs en valores de Helm** reemplazan las listas extensas de `valueFiles` con patrones, reduciendo conflictos de merge en equipos que mantienen multiples archivos de valores por entorno: ```yaml # Before ArgoCD 3.4 source: helm: valueFiles: - values.yaml - values-production.yaml - values-production-eu.yaml - values-production-eu-secrets.yaml # With ArgoCD 3.4 value globs source: helm: valueFiles: - values.yaml - values-production*.yaml ``` ## Preguntas frecuentes de entrevista sobre ArgoCD Estas preguntas aparecen de forma recurrente en entrevistas de DevOps e ingenieria de plataformas. Evaluan la comprension de los principios de GitOps, no unicamente la sintaxis de ArgoCD. Para una preparacion mas amplia sobre Kubernetes, el [modulo avanzado de Kubernetes](/technologies/devops/interview-questions/kubernetes-advanced) cubre temas de scheduling, security contexts y controladores personalizados. > **Profundidad en la entrevista** > > Las entrevistas para roles senior esperan que los candidatos expliquen trade-offs y modos de fallo, no solo que enumeren funcionalidades. Conviene preparar ejemplos concretos de experiencia en produccion: un incidente donde el self-heal genero problemas, una migracion que requirio sync waves, o un rollout multi-cluster que necesito entrega progresiva. **"Explique la diferencia entre sincronizacion automatica y manual en ArgoCD."** La sincronizacion automatica aplica los cambios al cluster tan pronto como ArgoCD detecta una diferencia entre Git y el estado activo. La sincronizacion manual requiere un trigger explicito desde la UI, la CLI o la API. La sincronizacion automatica con `selfHeal: true` corrige drift de forma continua, lo cual constituye el estandar para entornos de produccion donde la consistencia de configuracion resulta critica. La sincronizacion manual se adapta mejor a entornos de staging donde los equipos prefieren revisar los cambios antes de aplicarlos. **"Que ocurre cuando ArgoCD detecta drift entre Git y el cluster?"** ArgoCD compara el estado deseado (manifiestos de Git renderizados a traves de Helm, Kustomize o YAML plano) contra el estado activo del cluster. Si la sincronizacion automatica esta habilitada con selfHeal, ArgoCD revierte el cluster al estado de Git de forma inmediata. Si selfHeal esta deshabilitado, ArgoCD marca la aplicacion como OutOfSync y espera intervencion manual. El diff de recursos queda visible en la UI, mostrando exactamente que campos divergieron. **"Como se manejan las migraciones de base de datos en un flujo GitOps?"** Las migraciones se ejecutan como Jobs con hook PreSync y un numero de sync wave negativo. El Job de migracion se ejecuta antes de que ArgoCD despliegue la nueva version de la aplicacion. Si la migracion falla, la sincronizacion se aborta y la version anterior de la aplicacion permanece en ejecucion. La politica de eliminacion `HookSucceeded` limpia los Jobs de migracion exitosos. Para escenarios de rollback, los scripts de migracion deben disenarse como operaciones idempotentes. **"Compare ArgoCD y Flux para una configuracion multi-cluster en produccion."** ArgoCD administra multiples clusters desde un unico plano de control, proporcionando visibilidad centralizada a traves de su dashboard y RBAC unificado en todos los clusters. Flux se ejecuta de forma independiente en cada cluster, reduciendo el radio de explosion ya que una falla en el plano de control solo afecta a un cluster. Con mas de 100 clusters, el modelo centralizado de ArgoCD requiere un cluster de gestion robusto, mientras que el enfoque distribuido de Flux elimina ese unico punto de fallo. La eleccion depende de si el equipo prioriza la simplicidad operativa (ArgoCD) o el aislamiento de fallas (Flux). El [modulo de seguridad en pipelines CI/CD](/technologies/devops/interview-questions/cicd-pipeline-security) cubre preguntas relacionadas sobre la proteccion de pipelines de despliegue. **"Que es un ApplicationSet y en que escenarios se utiliza?"** Un ApplicationSet es un controlador que genera recursos Application de ArgoCD a partir de plantillas. Utiliza generadores (cluster, directorio Git, lista, matrix, merge) para producir multiples Applications desde una unica definicion. Los casos de uso tipicos incluyen desplegar la misma aplicacion en todos los clusters de produccion, generar aplicaciones por inquilino en una plataforma SaaS multi-tenant, o crear Applications para cada directorio en un monorepo. ## Conclusion - ArgoCD 3.4 (mayo 2026) incorpora pausa de reconciliacion y globs en valores de Helm, apuntando a las necesidades operativas de Day 2 en clusters de Kubernetes productivos - El modelo GitOps basado en pull elimina la necesidad de exponer credenciales del cluster a herramientas de CI, manteniendo los secretos dentro del perimetro del cluster - Las sync waves y los hooks resuelven el ordenamiento de despliegues: migraciones antes de pods de aplicacion, ConfigMaps antes de Deployments, limpieza despues de la eliminacion - Los ApplicationSets automatizan el despliegue multi-cluster generando recursos Application a partir de etiquetas de cluster, directorios Git o listas personalizadas - Separar el repositorio de configuracion del repositorio de la aplicacion produce un historial de Git mas limpio, ciclos de revision independientes y triggers de CI mas simples - ArgoCD se adapta a la gestion multi-cluster centralizada gracias a su dashboard y RBAC; Flux se adapta a entornos distribuidos, con restricciones de recursos o fuerte dependencia de Helm - La preparacion para entrevistas sobre GitOps debe cubrir deteccion de drift, estrategias de sincronizacion, modos de fallo y escenarios concretos de produccion en lugar de definiciones memorizadas --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/es/blog/devops/argocd-gitops-kubernetes-continuous-deployment-interview-questions