ArgoCD e GitOps nel 2026: Continuous Deployment su Kubernetes e Domande da Colloquio

ArgoCD si è affermato come lo strumento GitOps di riferimento per il Continuous Deployment su Kubernetes. Con il rilascio della versione 3.4 a maggio 2026 e oltre il 64% delle aziende che adotta GitOps come meccanismo di distribuzione principale, il tema è più attuale che mai. Questo tutorial analizza i concetti fondamentali di ArgoCD, i pattern di configurazione più utilizzati e le domande da colloquio più frequenti per ruoli DevOps e platform engineering.

Come ArgoCD implementa il modello GitOps

ArgoCD opera come un insieme di microservizi all'interno di un cluster Kubernetes: un API server, un repo server, un application controller e una cache Redis. Il controller monitora i repository Git e confronta lo stato desiderato (manifest in Git) con lo stato live nel cluster. Quando viene rilevata una differenza, ArgoCD genera un avviso oppure esegue una sincronizzazione automatica, a seconda della policy configurata.

Questo modello pull-based offre un vantaggio in termini di sicurezza rispetto ai deployment push tradizionali basati su CI. Il cluster preleva le modifiche da Git anziché esporre un endpoint in ingresso per uno strumento CI. Le credenziali del cluster non escono mai dal perimetro del cluster stesso.

Il primo passo consiste nell'installare ArgoCD e definire una risorsa Application:

# 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

Il blocco source punta al repository Git contenente i manifest Kubernetes. Il blocco destination specifica il cluster e il namespace di destinazione. L'impostazione automated.selfHeal: true garantisce che qualsiasi modifica manuale eseguita con kubectl venga sovrascritta dallo stato dichiarato in Git nel giro di pochi secondi.

Sync Wave e Hook per deployment ordinati

I deployment reali raramente consistono in un singolo manifest. Le migrazioni del database devono essere eseguite prima dell'avvio dei pod applicativi. ConfigMap e Secret devono esistere prima che i Deployment li referenzino. ArgoCD risolve questo problema con le sync wave e i resource hook.

Le sync wave assegnano un ordine numerico alle risorse. I numeri più bassi vengono distribuiti per primi, e ArgoCD attende che ogni wave risulti healthy prima di procedere:

# 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

L'hook PreSync esegue il job di migrazione prima che ArgoCD applichi i manifest principali dell'applicazione. La policy di cancellazione HookSucceeded elimina il Job dopo il completamento con successo. ArgoCD 3.3 ha introdotto anche gli hook PreDelete, risolvendo il problema di lunga data delle risorse orfane durante la rimozione delle applicazioni.

Gestione multi-cluster con ApplicationSet

Gestire decine di cluster da una singola istanza ArgoCD richiede più del semplice copia-incolla dei manifest Application. Gli ApplicationSet generano risorse Application in modo dinamico a partire da template e generatori:

# 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

Il generatore cluster itera su tutti i cluster registrati con il label env: production e crea una Application per ciascun cluster. I placeholder {{name}}, {{server}} e {{metadata.labels.region}} vengono risolti dai dati di registrazione del cluster. L'aggiunta di un nuovo cluster di produzione ad ArgoCD attiva automaticamente il deployment dell'applicazione su quel cluster.

ArgoCD vs Flux: scegliere lo strumento GitOps giusto

Il confronto tra ArgoCD e Flux è uno dei temi più ricorrenti nei colloqui DevOps. Entrambi sono progetti CNCF Graduated che implementano il pattern GitOps, ma differiscono per architettura e compromessi:

| Caratteristica | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architettura | Server centralizzato con UI | Controller distribuiti per cluster | | Web UI | Dashboard integrato e maturo | Nessuna UI integrata (opzioni di terze parti) | | Supporto Helm | Rendering template lato server | Integrazione nativa Helm SDK | | Multi-cluster | Hub-and-spoke da singola istanza | Installazione indipendente per cluster | | RBAC | A livello applicazione con SSO | Solo RBAC nativo Kubernetes | | Automazione immagini | Componente Image Updater separato | Image reflector/automation integrato | | Progressive delivery | Integrazione Argo Rollouts | Integrazione Flagger | | Risorse necessarie | Maggiori (API server, repo server, Redis) | Minori (solo controller necessari) |

ArgoCD è indicato per team che danno valore alla visibilità centralizzata, a un dashboard web e a un RBAC granulare a livello applicazione. Flux è indicato per team che operano in ambienti edge o con risorse limitate, o che si affidano in modo significativo alle funzionalità native del ciclo di vita Helm. Alcune organizzazioni utilizzano entrambi: ArgoCD per i deployment applicativi dove la UI aggiunge valore, e Flux per i componenti infrastrutturali dove il funzionamento distribuito e la fedeltà Helm sono prioritari.

Struttura del repository per GitOps in produzione

Un errore comune nell'adozione di GitOps è conservare i manifest Kubernetes insieme al codice sorgente dell'applicazione. Separare il repository di configurazione dal repository dell'app offre una cronologia Git più pulita, cicli di review indipendenti e trigger CI più semplici:

# 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

La directory base contiene i manifest condivisi. Ogni overlay applica patch specifiche per l'ambiente tramite Kustomize. La pipeline CI compila e pubblica l'immagine container, quindi aggiorna il tag dell'immagine nel repository di configurazione. ArgoCD rileva il commit e sincronizza la nuova versione nel cluster.

Novità di ArgoCD 3.4 da conoscere

ArgoCD 3.4, rilasciato a maggio 2026, si concentra sulle operazioni Day 2 con funzionalità che emergono frequentemente nei colloqui per ruoli DevOps senior:

Pause cluster reconciliation consente agli operatori di congelare la sincronizzazione ArgoCD durante gli incident in produzione. Questo impedisce ad ArgoCD di annullare gli hotfix di emergenza applicati direttamente al cluster mentre il team risolve il problema:

# 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 } }

Helm value glob sostituiscono gli array valueFiles prolissi con pattern, riducendo i conflitti di merge nei team che mantengono numerosi file di valori specifici per ambiente:

# 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

Domande da colloquio su ArgoCD più frequenti

Queste domande compaiono regolarmente nei colloqui per ruoli DevOps e platform engineering. Testano la comprensione dei principi GitOps, non solo la sintassi di ArgoCD. Per una preparazione Kubernetes più completa, il modulo Kubernetes Advanced copre scheduling, security context e custom controller.

"Spiegare la differenza tra sync automatico e sync manuale in ArgoCD."

Il sync automatico applica le modifiche al cluster non appena ArgoCD rileva una differenza tra Git e lo stato live. Il sync manuale richiede un trigger esplicito dalla UI, dalla CLI o dall'API. Il sync automatico con selfHeal: true corregge continuamente il drift ed è lo standard per gli ambienti di produzione dove la consistenza della configurazione è critica. Il sync manuale è adatto agli ambienti di staging dove i team vogliono revisionare le modifiche prima dell'applicazione.

"Cosa succede quando ArgoCD rileva un drift tra Git e il cluster?"

ArgoCD confronta lo stato desiderato (manifest Git renderizzati tramite Helm, Kustomize o YAML semplice) con lo stato live nel cluster. Se il sync automatico con selfHeal è abilitato, ArgoCD riporta immediatamente il cluster allo stato Git. Se selfHeal è disabilitato, ArgoCD segna l'applicazione come OutOfSync e attende un intervento manuale. Il diff delle risorse è visibile nella UI, mostrando esattamente quali campi sono divergenti.

"Come gestire le migrazioni del database in un workflow GitOps?"

Le migrazioni del database vengono eseguite come Job PreSync hook con un numero di sync wave negativo. Il Job di migrazione viene eseguito prima che ArgoCD distribuisca la nuova versione dell'applicazione. Se la migrazione fallisce, la sincronizzazione si interrompe e la versione precedente dell'applicazione resta attiva. La policy di cancellazione HookSucceeded elimina i Job di migrazione completati con successo. Per gli scenari di rollback, gli script di migrazione devono essere progettati come operazioni idempotenti.

"Confrontare ArgoCD e Flux per un setup multi-cluster in produzione."

ArgoCD gestisce più cluster da un singolo control plane, offrendo visibilità centralizzata attraverso il suo dashboard e RBAC unificato su tutti i cluster. Flux opera in modo indipendente in ogni cluster, riducendo il blast radius poiché un guasto del control plane colpisce un solo cluster. Con 100+ cluster, il modello centralizzato di ArgoCD richiede un management cluster robusto, mentre l'approccio distribuito di Flux elimina quel single point of failure. La scelta dipende dalla priorità del team tra semplicità operativa (ArgoCD) e isolamento dei guasti (Flux). Il modulo CI/CD Pipeline Security tratta domande correlate sulla sicurezza delle pipeline di deployment.

"Cos'è un ApplicationSet e quando si utilizza?"

Un ApplicationSet è un controller che genera risorse Application ArgoCD a partire da template. Utilizza generatori (cluster, Git directory, list, matrix, merge) per produrre più Application da una singola definizione. I casi d'uso tipici includono il deployment della stessa applicazione su tutti i cluster di produzione, la generazione di applicazioni per-tenant in una piattaforma SaaS multi-tenant, o la creazione di Application per ogni directory in un monorepo.

Conclusione

• ArgoCD 3.4 (maggio 2026) introduce pause reconciliation e Helm value glob, rispondendo alle esigenze operative Day 2 nei cluster Kubernetes in produzione
• Il modello GitOps pull-based elimina la necessità di esporre le credenziali del cluster agli strumenti CI, mantenendo i secret all'interno del perimetro del cluster
• Sync wave e hook risolvono l'ordinamento dei deployment: migrazioni prima dei pod applicativi, ConfigMap prima dei Deployment, pulizia dopo la cancellazione
• Gli ApplicationSet automatizzano il deployment multi-cluster generando risorse Application da label di cluster, directory Git o liste personalizzate
• I repository di configurazione vanno separati dai repository dell'app per una cronologia Git più pulita, cicli di review indipendenti e trigger CI più semplici
• ArgoCD è adatto alla gestione multi-cluster centralizzata con dashboard e RBAC; Flux è adatto ad ambienti distribuiti, con risorse limitate o fortemente basati su Helm
• La preparazione ai colloqui per ruoli GitOps dovrebbe coprire rilevamento del drift, strategie di sync, modalità di guasto e scenari produttivi concreti piuttosto che definizioni memorizzate