A mio avviso, uno degli aspetti più interessanti della soluzione enterprise Anthos di Google è Anthos Config Management (ACM). Basta configurare un repository Git, collegarvi i vari cluster e questi standardizzeranno le configurazioni evitando il drift secondo un approccio GitOps. Un aspetto particolarmente rilevante per le grandi aziende che gestiscono centinaia o migliaia di cluster distribuiti in sedi di hosting differenti.
Automatizzare la configurazione multi-cluster di Kubernetes con Argo CD
Ispirato da ACM, mi sono chiesto se fosse possibile ricreare lo stesso tipo di funzionalità con un'altra soluzione GitOps, Argo CD. Sono lieto di poter dire che ha funzionato come previsto: le modifiche apportate ai file di configurazione nel repository Git sono state applicate a entrambi i cluster senza alcun intoppo.
Panoramica dell'architettura
Il setup
Per semplicità ho creato due cluster sul servizio Kubernetes gestito di Google Cloud, GKE, in due region distinte per simulare uno scenario East e uno West. Naturalmente, Argo CD si può installare su cluster ovunque, purché possano accedere al repository Git.
Ho preparato il seguente shell script per fare il bootstrap di tutto l'ambiente; in produzione, però, consiglio di gestire l'infrastruttura con Terraform, ove possibile.
Cluster con bootstrap completato
Nel giro di 8-10 minuti entrambi i cluster erano attivi e i workloads di Argo CD erano stati distribuiti.
Cluster Kubernetes nelle region East e West
Argo CD distribuito su ciascun cluster
App of Apps
L'aspetto peculiare di questo setup è che su ogni cluster ho installato Argo CD con un'Application iniziale basata sul pattern App of Apps e collegata al mio repository GitHub. Questo permette di aggiungere in futuro un numero qualsiasi di configurazioni al repository e di personalizzare i cluster o le app distribuite.
La sincronizzazione automatica è del tutto opzionale. Con un numero elevato di cluster la consiglio, perché consente loro di auto-ripararsi e di gestire il drift. Uno svantaggio dell'auto-sync, però, è che la funzione di rollback non è disponibile.
La cartella (path) applications/ contiene un'app (per ora), denominata k8s-config.yaml, che a sua volta è un'altra app Argo che punta a un'altra cartella con le nostre configurazioni Kubernetes.
La cartella (path) k8s-config/ contiene tutti i file YAML che vogliamo applicare ai cluster Kubernetes. In alternativa, è possibile dichiarare un'app per applicare le configurazioni in modo ricorsivo, qualora si abbiano molti file da organizzare.
Repository del codice sorgente
Per il mio esperimento ho pubblicato un repository del codice sorgente su GitHub all'indirizzo mikesparr/multi-cluster-argo-demo con la seguente struttura di directory.
Struttura del repository del codice sorgente
In questo esempio è tutto contenuto in un unico repository, ma si possono separare le responsabilità utilizzando repository diversi e assegnando a team differenti i permessi per modificarli.
L'interfaccia di Argo
Da riga di comando si può effettuare il port-forward al servizio argo-server
kubectl -n argocd port-forward svc/argo-server 8080:443
Nel browser visiti http://localhost:8080 e, quando richiesto, accetti l'eccezione di sicurezza (no https). SUGGERIMENTO: per impostazione predefinita, il login si effettua con admin e il nome completo del pod del server argocd:
Copi argocd-server-XXXXXXX come password predefinita
All'inizio compare l'applicazione (app of apps) finché non viene sincronizzata
Una volta sincronizzata l'App of Apps (applications), questa riconoscerà la prima app, k8s-config.
Dopo la sincronizzazione di entrambe le applicazioni
Cliccando sul pannello dell'app k8s-config, si ottiene una vista dettagliata di tutto ciò che è stato installato sul server.
Tutti i file YAML nella directory /k8s-config del repository vengono applicati al server
Verifica delle configurazioni dei cluster
Cambi il contesto di kubectl su ciascun cluster e controlli namespaces, serviceaccounts, roles e rolebindings per il test-namespace. Li troverà installati su entrambi i cluster. Congratulazioni!
Il cluster ha installato automaticamente i workloads dal repository Git
Video demo
Demo dal vivo: aggiunta di un pod Nginx e deployment automatico su più cluster dal repository GitHub
Potenziale illimitato
Immagini di voler aggiungere un API Gateway al proprio stack scegliendo Ambassador o Kong, entrambi configurati con CRD e YAML. Basterebbe aggiungere un'altra cartella o un altro repository, poi un nuovo file YAML dell'app all'interno della cartella applications/, e ArgoCD lo installerebbe e configurerebbe automaticamente.
Per ogni applicazione pubblicata dal team di engineering, basterebbe modificare la versione dell'immagine Docker in un manifest di Deployment, aprire una pull request per la modifica e si avrebbero così controlli manuali integrati e una chiara separazione dei ruoli. Una volta effettuato il merge della PR, Argo CD si occuperà di distribuirla sul cluster e nell'ambiente di riferimento.
Un altro caso d'uso è il supporto a deployment multi-cloud, bilanciando il traffico tramite DNS per una vera configurazione active-active. Un ulteriore scenario può essere la migrazione da un cloud a un altro.
Non vedo l'ora di esplorare altre possibilità e spero che abbia trovato utile questo modo alternativo per mantenere i cluster sincronizzati nei vari ambienti.
Pulizia
Se ha utilizzato lo script e/o il repository, non dimentichi di fare pulizia e rimuovere le risorse per evitare costi superflui. Il modo più semplice è eliminare i cluster con il comando seguente (oppure eliminare l'intero progetto).
gcloud container clusters delete west --zone us-west2-b
gcloud container clusters delete east --zone us-east1-c