La sauvegarde pour GKE permet de sauvegarder deux types de données :
La sauvegarde et la restauration pour GKE dispose de différent scénario qui sont :
Pour la sauvegarde et la restauration nous disposons de différents scénarios, par exemple :
L’architecture de la sauvegarde de GKE consiste en 2 composants:
Le schéma suivant montre la relation entre les différents composants de la sauvegarde pour GKE :
Avant tout, il vous faudra activer les API pour backup restore et Kubernetes Engine sur GCP. Pour cela:
Il ne vous restera plus qu’à chercher “Kubernetes Engine API“ et “Backup for GKE API” afin de les activer.
Afin de pouvoir activer le service de sauvegarde pour GKE, il faut obligatoirement activer le service “Workload idendity” dans la section “Sécurité”.
Par contre petite attention, si vous activez le service Workload Identity, seuls les nouveaux pod utiliseront le service, les anciens pod ne seront pas mis à jour.. Si vous souhaitez migrer les workloads existant vers Workload Identity cela va entraîner la modification immédiate du pool de nœuds. Cela empêche les charges de travail d'utiliser le compte de service Compute Engine par défaut et peut entraîner des interruptions.
La première étape consiste à disposer d’un cluster GKE, pour cela allez dans le menu de GCP et allez dans Kubernetes Engine :
Cliquez sur “Configurer” sur “GKE Standard” afin de pouvoir arriver sur la page de configuration de votre cluster. Pour la création du cluster, dans notre cas, nous allons laisser les différentes valeurs par défaut. Les seules modifications que nous devons faire sont dans la partie “Fonctionnalités“, ou nous allons cocher la case d’activation du service de sauvegarde pour GKE.
Si vous disposez déjà d’un cluster GKE, mais que la fonctionnalité de sauvegarde de GKE n’est pas activée, il suffira d’aller sur votre cluster GKE déjà existant et de l’éditer et de cocher la case “Activez le service de sauvegarde pour GKE” avec le pré-requis du “Workload Idendity” comme nous avons indiqué plus haut.
Pour simplifier l’exemple, nous créons les ressources à la main mais je vous recommande de gérer votre infrastructure avec de l’IaC (Infrastructure as Code). Voici un exemple de création du cluster GKE avec Terraform en activant le service de sauvegarde GKE :
resource "google_container_cluster" "gke_cluster" {
provider = "google-beta"
name = "my-gke-cluster"
location = "us-central1"
remove_default_node_pool = true
initial_node_count = 1
maintenance_policy {
daily_maintenance_window {
# en heure GMT
start_time = "04:00"
}
}
addons_config {
gke_backup_agent_config {
enabled = true
}
}
}
resource "google_container_node_pool" "main_gke_simple_node_pool" {
cluster = google_container_cluster.gke_cluster.name
name = "node-pool"
location = "us-central1"
initial_node_count = 1
autoscaling {
min_node_count = 1
max_node_count = 6
}
node_config {
preemptible = false
machine_type = n1-standard-8
oauth_scopes = [
"https://www.googleapis.com/auth/logging.write",
"https://www.googleapis.com/auth/monitoring",
]
}
management {
auto_repair = true
auto_upgrade = true # Will follow the master version
}
}
Comme nous pouvons voir la partie importante dans le terraform ci-dessus et ce bloc qui permet d’activer la sauvegarde pour GKE.
addons_config {
gke_backup_agent_config {
enabled = true
}
Comme nous pouvons le constater ci-dessus, nous retrouvons bien dans la section “Caractéristiques” le service de sauvegarde pour GKE activé.
Maintenant que nous avons un cluster GKE opérationnel avec la fonctionnalité de sauvegarde de GKE activée; pour profiter de ce service nous devons créer un plan de sauvegarde et un “restore plan”. A l’heure actuelle, nous ne pouvons pas créer cette ressources via de l’IaC avec Terraform comme pour la création du cluster et l’activation du service, nous pouvons seulement passer par la CLI gcloud et la console GCP.
Pour pouvoir créer une ressource dans la partie “sauvegarde pour GKE” il vous faudra bénéficier du droit “gke backup admin” et vous retrouverez cette interface sauvegarde pour GKE dans Kubernetes.
Dans un premier temps, nous allons créer le “plan de sauvegarde” définissant une cible de et une fréquence de sauvegarde Pour cela il nous faudra cibler le cluster et la région où seront stockées les sauvegardes.
Ces sauvegardes sont stockées en façon régionale sur les infrastructures de Google et gérées par Google, nous n’avons pas la main dessus.
Dans un second temps, il nous faut choisir notre scénario de sauvegarde et son champ d’application (cluster, namespace, applications, secret, volumes) et si l'on souhaite chiffrer les sauvegardes. Pour le chiffrement des sauvegardes il vous faudra utiliser KMS (Key Management System) la solution de chiffrement de Google, soit par une clé de chiffrement que nous pouvons fournir, soit une clé de chiffrement créée par Google.
Enfin, il faut définir la fréquence à laquelle les sauvegardes seront créées. Cela se fera via une expression cron. Il faudra également définir le temps de rétention des sauvegardes et son temps de protection en cas de suppression par inadvertance.
Voici la solution via la CLI gcloud pour la création de notre plan de sauvegarde
gcloud alpha container backup-restore backup-plans create backup-schedule \
--project=${var.gcp_project} \
--location=${var.gcp_region} \
--cluster=${google_container_cluster.primary.id} \
--all-namespaces \
--include-secrets \
--include-volume-data \
--cron-schedule="${var.gke_backup_cron_schedule}" \
--encryption-key=${var.kms_encryption_key} \
--locked
Maintenant que nous avons créé notre plan de sauvegarde, nous pouvons créer notre plan de restauration basé sur notre plan de sauvegarde créé ci-dessus.
Afin de créer une restauration de la sauvegarde, il est nécessaire de créer un plan de restauration. Pour cela, lors de la première étape du plan nous devons choisir sur quel cluster nous voulons que les sauvegardes soient restaurées. En effet, nous pouvons restaurer sur un autre cluster que celui ou la sauvegarde a été opéré et nous devons aussi lui donner le plan de sauvegarde que nous avons créé plus haut.
Au même titre que pour le plan de sauvegarde, nous devons définir le scénario de restauration et définir comment il va gérer les conflits lors de la restauration.
Voici la commande gcloud de la création du plan de restauration comme nous venons de le faire via la console GCP.
gcloud alpha container backup-restore restore-plans create restore-schedule \
--project=${var.gcp_project} \
--location=${var.gcp_region} \ --backup-plan=projects/${var.gcp_project}/locations/${var.gcp_region}/backupPlans/backup-schedule \
--cluster=${google_container_cluster.primary.id} \
--cluster-resource-conflict-policy=${var.cluster_resource_conflict_policy} \
--namespaced-resource-restore-mode=${var.namespaced_resource_restore_mode} \
--volume-data-restore-policy=${var.volume_data_restore_policy} \
--cluster-resource-restore-scope=${var.cluster_resource_restore_scope} \
--all-namespaces
Pour créer une sauvegarde il faudra aller dans la section “sauvegarde pour GKE” et cliquer sur “démarrer une sauvegarde au niveau du “plans de sauvegarde”
Nous pouvons voir l’intégralité de nos sauvegardes que ce soit ceux déclenchés manuellement ou automatiquement dans la console GCP.
Et si nous voulons restaurer une de ces sauvegardes, il suffit cliquer sur “configurer une restauration” sur la sauvegarde voulue et vous n’aurez plus qu’à choisir votre plan de restauration comme ci-dessous.
La nouvelle fonctionnalité de sauvegarde des données et des manifestes pour des clusters GKE apportent beaucoup de chose surtout pour des clusters GKE en production, car à tout moment la question de sauvegarde des données et des ressources sur un cluster Kubernetes devient un élément important, les solutions open source tel que Velero ne sont pas aussi performante et beaucoup plus compliquées à utiliser.