
Ogni tanto può capitare di dover spostare l'intero workload Kubernetes su un nuovo cluster: per fare dei test, per aggiornare una major version o, a volte, come misura di disaster recovery.
Di recente ho dovuto migrare il cluster GKE (Google Kubernetes Engine) di un nostro cliente da una Legacy VPC Network di Google Cloud a una VPC Native Network e, purtroppo, in Google Cloud non esiste un percorso di upgrade documentato per le reti.
Dopo qualche ricerca ho scovato un paio di strumenti che, usati insieme, hanno reso l'operazione davvero semplice.
Clonare un cluster esistente
Google Kubernetes Engine (GKE) mette a disposizione la funzione "create a new cluster", che permette di clonare un cluster già esistente:

In questo modo si copiano le configurazioni del cluster, tra cui:
- Zones
- Node Pool e relativa configurazione
- Impostazioni aggiuntive come node label e altro ancora
Naturalmente, prima di creare il nuovo cluster si può modificare qualsiasi parametro, ma nel complesso questa funzione di "clone" è una bella mano: bastano due click per avere nodi e label configurati a dovere. 🚀
Attenzione però: NON verranno copiate le risorse Kubernetes come deployment, service, ingress e custom resource definition, quindi servirà un altro strumento per migrare anche queste.
Migrare le risorse Kubernetes
Ora che avevo il cluster clonato, restava da migrare tutte le risorse Kubernetes:
- Workloads
- Services
- Configs
- Secrets
- Storage
- Custom Resource Definitions
- e molto altro ancora…
Basta lanciare al volo:
$ kubectl api-resourcesper scoprire 74 tipi di risorse Kubernetes nel mio cluster di test 😱. Non male!
Per fortuna mi sono imbattuto in Velero di Heptio (ex Heptio Ark), che mi ha permesso di fare backup e restore delle risorse del cluster Kubernetes e dei persistent volume.
Velero permette di:
- Eseguire backup e restore del cluster Kubernetes.
- Copiare le risorse da un cluster a un altro.
- Replicare l'ambiente di produzione su ambienti di sviluppo e test. 🎸
Velero sembrava il candidato ideale per replicare le risorse del cluster Kubernetes su un nuovo cluster, così ho deciso di provarlo.
Installazione di Velero
Velero è composto da 2 componenti principali:
- velero-cli — un client a riga di comando che gira in locale
- velero deployment — un server che gira sul cluster
prima di partire, è sempre buona prassi dare un'occhiata alla release ufficiale di Velero; l'ultima versione stabile è la v0.11.0
Dovendo installare Velero sul mio cluster GKE, ho seguito le istruzioni qui.
Il flusso di installazione di base è questo:
- Installare velero-cli
brew install velero(in alternativa lo si può scaricare a mano: è un singolo binario)
2. Creare un bucket Google Cloud Storage
gsutil mb gs://<gke-cluster-migrate-velero-placeholder-name>3. Creare service account / permessi / policy
Vedere le istruzioni alla voce "Create service account" qui
4. Aggiungere le credenziali al cluster GKE
Vedere le istruzioni alla voce "Credentials and configuration" qui
ricordatevi di sostituire <YOUR_BUCKET> nel file 05-backupstoragelocation.yaml
5. Fare il deploy del velero-server
kubectl apply -f config/gcp/05-backupstoragelocation.yaml kubectl apply -f config/gcp/06-volumesnapshotlocation.yaml kubectl apply -f config/gcp/10-deployment.yamlÈ il momento del backup!
Per fare il backup dell'intero cluster ho usato:
velero backup create <BACKUP-NAME>Quando si lancia velero backup create <BACKUP-NAME>:
- Il client Velero chiama l'API server di Kubernetes per creare un oggetto
Backup. - Il
BackupControllerrileva il nuovo oggettoBackuped esegue la validazione. - Il
BackupControlleravvia il processo di backup, raccogliendo i dati da salvare tramite query all'API server. - Il
BackupControllerchiama il servizio di object storage – ad esempio un GCS Bucket – per caricare il file di backup.
Perfetto!
Per controllare lo stato del backup basta lanciare:
velero get backupsÈ ora di migrare
Ora che avevamo un backup completo del cluster originale ( cluster 1), dovevo fare il deploy di Velero sul nuovo cluster ( cluster 2).
Ci sono alcuni dettagli a cui ho dovuto fare attenzione:
- Sul cluster 2, ho aggiunto il flag
--restore-onlyalla server spec nello YAML di deployment di Velero - Ho verificato che la
BackupStorageLocationcoincidesse con quella del cluster 1, in modo che la nuova istanza del server Velero puntasse allo stesso bucket. - Infine, mi sono assicurato che le risorse Velero sul cluster 2 fossero sincronizzate con i file di backup nel cloud storage. L'intervallo di sincronizzazione predefinito è di 1 minuto, quindi conviene attendere prima di verificare.
velero backup describe <BACKUP-NAME>Una volta verificata la presenza del backup corretto (<BACKUP-NAME>), ho potuto ripristinare tutto con:
velero restore create --from-backup <BACKUP-NAME>A questo punto verifichiamo il tutto sul c luster 2:
velero restore gete usiamo il nome del restore restituito dal comando precedente:
velero restore describe <RESTORE-NAME-FROM-GET-COMMAND>Ed è fatta!
Grazie a "Clone Cluster" di GKE e a Heptio Velero sono riuscito a migrare il cluster senza intoppi, configurazione e risorse comprese.
Questi due strumenti mi hanno fatto risparmiare un sacco di ore e hanno semplificato di molto il processo di mappatura, backup e restore delle risorse Kubernetes.
Volete altre storie? Date un'occhiata al nostro blog oppure seguite Eran su Twitter.