Google Kubernetes Engine Cluster mit Heptio Velero migrieren

Hin und wieder steht ein Umzug des kompletten Kubernetes Workload auf einen neuen Cluster an. Mögliche Gründe: Tests, ein Major-Version-Upgrade oder eine Disaster Recovery.

Vor Kurzem stand bei einem unserer Kunden die Migration eines GKE-Clusters (Google Kubernetes Engine) von einem Google Cloud Legacy VPC Network auf ein VPC Native Network an – und leider gibt es in Google Cloud keinen dokumentierten Upgrade-Pfad für Netzwerke.

Nach kurzer Recherche bin ich auf ein paar Tools gestoßen, die diese Aufgabe im Zusammenspiel extrem einfach gemacht haben.

Bestehenden Cluster klonen

Die Google Kubernetes Engine (GKE) bietet die Funktion "Neuen Cluster erstellen", über die sich ein bestehender Cluster klonen lässt:

Damit übernehmen Sie die Cluster-Konfiguration, darunter:

• Zonen
• Node Pools samt zugehöriger Konfiguration
• weitere Einstellungen wie Node Labels und mehr

Vor dem Erstellen des neuen Clusters lässt sich natürlich alles anpassen – aber im Großen und Ganzen sorgt die "Klon"-Funktion mit zwei Klicks dafür, dass alle Nodes und Labels sauber konfiguriert sind. 🚀

Wichtig: Ihre Kubernetes-Ressourcen wie Deployments, Services, Ingress oder Custom Resource Definitions werden dabei NICHT mitkopiert. Dafür brauchen Sie ein zusätzliches Tool.

Kubernetes-Ressourcen migrieren

Mit dem geklonten Cluster stand als Nächstes der Umzug aller Kubernetes-Ressourcen an, etwa:

• Workloads
• Services
• Configs
• Secrets
• Storage
• Custom Resource Definitions
• und vieles mehr …

Ein kurzer Aufruf von:

$ kubectl api-resources

zeigt auf meinem Test-Cluster 74 verschiedene Kubernetes-Ressourcentypen 😱. Heftig!

Zum Glück bin ich auf Velero von Heptio (früher Heptio Ark) gestoßen, mit dem sich Kubernetes-Cluster-Ressourcen samt Persistent Volumes sichern und wiederherstellen lassen.

Velero unterstützt Sie bei:

• Backup und Restore Ihres Kubernetes-Clusters.
• dem Kopieren von Cluster-Ressourcen von einem Cluster auf einen anderen.
• dem Replizieren Ihrer Produktivumgebung für Entwicklungs- und Testumgebungen. 🎸

Velero schien ein guter Kandidat, um die Kubernetes-Cluster-Ressourcen auf einen neuen Cluster zu replizieren – also habe ich es ausprobiert.

Velero installieren

Velero besteht aus 2 Hauptkomponenten:

1. velero-cli – ein Command-Line-Client, der lokal läuft
2. velero deployment – ein Server, der auf Ihrem Cluster läuft

Vor dem Start lohnt sich immer ein Blick auf das offizielle Release von Velero. Die aktuelle (stabile) Version ist v0.11.0.

Da ich Velero auf meinem GKE-Cluster installiere, halte ich mich an die Anleitung hier.

Der grundlegende Installationsablauf:

1. velero-cli installieren

brew install velero

(Sie können es auch manuell herunterladen – es ist nur eine Binärdatei.)

2. Einen Google Cloud Storage Bucket anlegen

gsutil mb gs://<gke-cluster-migrate-velero-placeholder-name>

3. Service Account, Berechtigungen und Policies anlegen

Anleitung unter "Create service account" hier.

4. Credentials zum GKE-Cluster hinzufügen

Anleitung unter "Credentials and configuration" hier.

Denken Sie daran, <YOUR_BUCKET> in der 05-backupstoragelocation.yaml zu ersetzen.

5. velero-server ausrollen

  kubectl apply -f config/gcp/05-backupstoragelocation.yaml
  kubectl apply -f config/gcp/06-volumesnapshotlocation.yaml
  kubectl apply -f config/gcp/10-deployment.yaml

Zeit für ein Backup!

Um den gesamten Cluster zu sichern, habe ich Folgendes verwendet:

velero backup create <BACKUP-NAME>

Beim Aufruf von velero backup create <BACKUP-NAME> passiert Folgendes:

1. Der Velero-Client spricht den Kubernetes-API-Server an, um ein Backup-Objekt anzulegen.
2. Der BackupController erkennt das neue Backup-Objekt und validiert es.
3. Der BackupController startet den Backup-Prozess und sammelt die zu sichernden Daten, indem er die Ressourcen über den API-Server abfragt.
4. Der BackupController spricht den Object-Storage-Dienst an – etwa einen GCS Bucket – und lädt die Backup-Datei hoch.

Sehr schön!

Den Status Ihres Backups sehen Sie mit:

velero get backups

Zeit für die Migration

Mit dem vollständigen Backup unseres Original-Clusters (Cluster 1) stand als Nächstes das Velero-Deployment auf dem neuen Cluster (Cluster 2) an.

Dabei waren ein paar Punkte zu beachten:

• Auf Cluster 2 musste ich das Flag --restore-only in der Server-Spec im Velero-Deployment-YAML ergänzen.
• Die BackupStorageLocation musste mit der von Cluster 1 übereinstimmen, damit die neue Velero-Server-Instanz auf denselben Bucket zeigt.
• Zum Schluss habe ich geprüft, ob die Velero-Ressourcen auf Cluster 2 mit den Backup-Dateien im Cloud Storage synchronisiert sind. Hinweis: Das Standard-Sync-Intervall beträgt 1 Minute – also kurz warten, bevor Sie nachschauen.

velero backup describe <BACKUP-NAME>

Sobald ich bestätigt hatte, dass das richtige Backup (<BACKUP-NAME>) vorliegt, konnte ich alles wiederherstellen mit:

velero restore create --from-backup <BACKUP-NAME>

Jetzt prüfen wir alles auf Cluster 2:

velero restore get

Und mit dem Restore-Namen aus dem vorherigen Befehl:

velero restore describe <RESTORE-NAME-FROM-GET-COMMAND>

Fertig!

Mit GKE "Clone Cluster" und Heptio Velero ließ sich der Cluster erfolgreich migrieren – inklusive Cluster-Konfiguration und Ressourcen.

Diese beiden Tools haben mir unzählige Stunden gespart und den gesamten Prozess – Mapping, Sichern und Wiederherstellen von Kubernetes-Ressourcen – deutlich vereinfacht.

Lust auf mehr? Schauen Sie in unserem Blog vorbei oder folgen Sie Eran auf Twitter.