
Il arrive parfois que l'on doive déplacer l'intégralité d'un workload Kubernetes vers un nouveau cluster : pour des tests, une montée de version majeure ou dans le cadre d'un plan de reprise après sinistre.
Récemment, j'ai dû migrer le cluster GKE (Google Kubernetes Engine) de l'un de nos clients depuis un réseau VPC Legacy de Google Cloud vers un réseau VPC Native. Malheureusement, aucune procédure de migration n'est documentée pour les réseaux dans Google Cloud.
Après quelques recherches, j'ai déniché deux outils qui, ensemble, ont rendu l'exercice d'une simplicité déconcertante.
Cloner un cluster existant
Google Kubernetes Engine (GKE) propose une fonctionnalité Créer un nouveau cluster qui permet de cloner un cluster existant :

Cela facilite la copie des configurations du cluster, à savoir :
- Les zones
- Les Node Pools et leur configuration associée
- Les paramètres complémentaires comme les labels de nœuds, et bien d'autres
Vous pouvez bien sûr tout modifier avant de créer le nouveau cluster, mais cette fonction de clonage garantit, en deux clics, que tous les nœuds et labels sont correctement configurés. 🚀
Attention toutefois : cette opération ne copie PAS vos ressources Kubernetes telles que les deployments, services, ingress ou custom resource definitions. Il faudra donc un autre outil pour migrer l'ensemble de ces éléments.
Migrer les ressources Kubernetes
Une fois le cluster cloné, restait à migrer toutes les ressources Kubernetes :
- Workloads
- Services
- Configs
- Secrets
- Storage
- Custom Resource Definitions
- et bien d'autres encore…
Un simple :
$ kubectl api-resourcesrévèle 74 types de ressources Kubernetes sur mon cluster de test 😱. Aïe !
Heureusement, j'ai découvert Velero de Heptio (anciennement Heptio Ark), qui m'a permis de sauvegarder et restaurer les ressources de mon cluster Kubernetes ainsi que les volumes persistants.
Velero permet de :
- Sauvegarder et restaurer votre cluster Kubernetes.
- Copier les ressources d'un cluster vers un autre.
- Répliquer votre environnement de production pour des environnements de développement et de test. 🎸
Velero semblait tout indiqué pour répliquer les ressources d'un cluster Kubernetes vers un nouveau cluster : j'ai donc décidé de le tester.
Installation de Velero
Velero comporte 2 composants principaux :
- velero-cli — un client en ligne de commande qui s'exécute localement
- velero deployment — un serveur qui s'exécute sur votre cluster
Avant de se lancer, il est toujours utile de consulter la release officielle de Velero. La dernière version (stable) est la v0.11.0.
J'installe Velero sur mon cluster GKE et je suis donc les instructions disponibles ici.
Voici les grandes étapes de l'installation :
- Installer velero-cli
brew install velero(vous pouvez aussi le télécharger manuellement, il s'agit d'un seul binaire)
2. Créer un bucket Google Cloud Storage
gsutil mb gs://<gke-cluster-migrate-velero-placeholder-name>3. Créer le compte de service, les permissions et les policies
Voir les instructions de la section Create service account ici
4. Ajouter les credentials à votre cluster GKE
Voir les instructions de la section Credentials and configuration ici
pensez à remplacer <YOUR_BUCKET> dans le fichier 05-backupstoragelocation.yaml
5. Déployer le 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.yamlPlace à la sauvegarde !
Pour sauvegarder l'intégralité de mon cluster, j'ai utilisé :
velero backup create <BACKUP-NAME>Lorsque vous exécutez velero backup create <BACKUP-NAME> :
- Le client Velero appelle le serveur d'API Kubernetes pour créer un objet
Backup. - Le
BackupControllerdétecte le nouvel objetBackupet effectue les validations. - Le
BackupControllerdémarre le processus de sauvegarde. Il collecte les données à sauvegarder en interrogeant le serveur d'API pour récupérer les ressources. - Le
BackupControllerappelle le service de stockage objet — par exemple, un bucket GCS — pour téléverser le fichier de sauvegarde.
Parfait !
Pour suivre l'état de votre sauvegarde, exécutez simplement :
velero get backupsPlace à la migration
Maintenant que nous disposons d'une sauvegarde complète de notre cluster d'origine (cluster 1), il faut déployer Velero sur le nouveau cluster (cluster 2).
Quelques points ont retenu mon attention :
- Sur le cluster 2, il faut ajouter le flag
--restore-onlyà la spec du serveur dans le YAML de déploiement de Velero. - Il faut s'assurer que
BackupStorageLocationcorrespond à celui du cluster 1, afin que la nouvelle instance du serveur Velero pointe vers le même bucket. - Enfin, je me suis assuré que les ressources Velero du cluster 2 étaient synchronisées avec les fichiers de sauvegarde dans le cloud storage. À noter que l'intervalle de synchronisation par défaut est d'1 minute : patientez donc avant de vérifier.
velero backup describe <BACKUP-NAME>Après avoir confirmé que la bonne sauvegarde (<BACKUP-NAME>) était bien présente, j'ai pu tout restaurer avec :
velero restore create --from-backup <BACKUP-NAME>Vérifions maintenant le tout sur le cluster 2 :
velero restore getpuis utilisez le nom de la restauration renvoyé par la commande précédente :
velero restore describe <RESTORE-NAME-FROM-GET-COMMAND>Et voilà !
Grâce à la fonctionnalité Clone Cluster de GKE et à Heptio Velero, j'ai pu migrer le cluster avec succès, configuration et ressources comprises.
Ces deux outils m'ont fait gagner un temps précieux et simplifient considérablement l'ensemble du processus de cartographie, de sauvegarde et de restauration des ressources Kubernetes.
Envie de lire d'autres articles ? Consultez notre blog, ou suivez Eran sur Twitter.