Sauvegarde pour GKE

Qu’est ce que fait la Sauvegarde pour GKE

La sauvegarde pour GKE permet de sauvegarder deux types de données :

• Sauvegarde de configuration : ensemble de descriptions de ressources Kubernetes.
• Sauvegarde de volume : ensemble de volumes correspondant aux ressources PersistentVolumeClaim.

La sauvegarde et la restauration pour GKE dispose de différent scénario qui sont :

• Vous pouvez choisir les charges de travail que vous souhaitez sauvegarder ou restaurer, ou bien sauvegarder ou restaurer toutes les charges de travail.
• Vous pouvez sauvegarder les charges de travail d'un cluster et les restaurer dans un autre cluster.
• Vous pouvez programmer l'exécution automatique de vos sauvegardes, ce qui vous permet de récupérer rapidement vos charges de travail en cas d'incident.

Cas d’utilisation

Pour la sauvegarde et la restauration nous disposons de différents scénarios, par exemple :

• Sauvegarder toutes les charges de travail d'un cluster et les restaurer dans un cluster distinct pour la reprise après sinistre.
• Sauvegarder toutes les charges de travail, mais effectuer un rollback sélectif d'un seul workload dans le cluster source.
• Sauvegarder les ressources dans un espace de noms et les restaurer dans un autre espace de noms.
• Migrer ou cloner un workload d'un cluster vers un autre.
• Modifier les paramètres de stockage d'un workload (par exemple, déplacer le workload d'un disque persistant zonal vers un disque persistant régional).

Architecture de sauvegarde dans GKE

L’architecture de la sauvegarde de GKE consiste en 2 composants:

• Un service qui s'exécute dans Google Cloud et accepte une API REST basée sur les ressources. Ce service sert de plan de contrôle à Sauvegarde pour GKE. Le service inclut des éléments de l'interface utilisateur de Google Cloud Console qui interagissent avec cette API.
• Un agent qui s'exécute dans chaque cluster où des sauvegardes ou des restaurations sont effectuées. L'agent exécute les opérations de sauvegarde et de restauration dans ces clusters en interagissant avec l'API Sauvegarde pour GKE.

Le schéma suivant montre la relation entre les différents composants de la sauvegarde pour GKE :

Passons à la pratique

Avant tout, il vous faudra activer les API pour backup restore et Kubernetes Engine sur GCP. Pour cela:

1. allez dans le menu de GCP
2. sélectionnez “API et services”
3. allez sur “+ ACTIVER DES API ET DES SERVICES”.

Il ne vous restera plus qu’à chercher “Kubernetes Engine API“ et “Backup for GKE API” afin de les activer.

Prérequis

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.

Création du cluster GKE avec le service de sauvegarde de GKE

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é.

Création des planifications de sauvegarde

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

Création des planifications de restauration

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.

Le mot de la fin

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.