Présentation de Sauvegarde pour GKE

Sauvegarde pour GKE est un service géré permettant de sauvegarder et de restaurer des charges de travail et des données persistantes dans des clusters GKE. Protéger vos charges de travail avec Sauvegarde pour GKE vous aide à répondre aux exigences de reprise après sinistre, à prendre en charge les pipelines d'intégration et de déploiement continus (CI/CD), à cloner des charges de travail et à atteindre les objectifs de point de récupération (RPO).

Le service se compose de deux principaux composants d'architecture :

  • Une API de plan de contrôle : une Google Cloud API REST qui gère les ressources cloud de sauvegarde et de restauration.
  • Un agent dans le cluster : un module complémentaire GKE qui s'exécute dans chaque cluster où vous sauvegardez ou restaurez des charges de travail.

Fonctionnalités de sauvegarde et de restauration des charges de travail

Lorsqu'il est activé, Sauvegarde pour GKE s'intègre à la console GKE, à Google Cloud CLI et aux API REST pour fournir des workflows unifiés pour le développement et les opérations.

Une sauvegarde de charge de travail capture deux formes de données :

  • Sauvegarde de configuration : ensemble de fichiers manifestes de ressources Kubernetes extraits du serveur d'API du cluster qui enregistre l'état de vos ressources Kubernetes.
  • Sauvegarde de volume : ensemble d'instantanés de volume correspondant aux PersistentVolumeClaim ressources référencées dans la sauvegarde de configuration.

Vous pouvez sauvegarder toutes les charges de travail d'un cluster ou sélectionner des charges de travail spécifiques à protéger par espace de noms ou par application. Vous pouvez sauvegarder les charges de travail d'un cluster et les restaurer dans un autre cluster. Vous pouvez également planifier des sauvegardes automatiques pour qu'elles s'exécutent selon des plannings récurrents, afin de pouvoir récupérer rapidement les charges de travail en cas de panne.

Sauvegarde pour GKE prend en charge les opérations intra-projet et multiprojets. Vous pouvez créer des plans de sauvegarde et des plans de restauration dans le même Google Cloud projet que votre cluster, ou coordonner les sauvegardes et les restaurations sur plusieurs projets pour isoler les environnements ou répondre aux exigences de conformité.

La restauration d'une charge de travail recrée des ressources Kubernetes et des volumes persistants dans le cluster cible. Une fois que Sauvegarde pour GKE a créé les fichiers manifestes de ressources, GKE réconcilie la charge de travail en planifiant des pods sur les nœuds et en démarrant les conteneurs.

Lors d'une opération de restauration, vous pouvez appliquer des règles de transformation facultatives pour modifier les configurations de ressources avant leur création dans le cluster cible. Les règles de transformation correspondent aux ressources Kubernetes spécifiées et remplacent les valeurs d'attribut, par exemple en mettant à jour les classes de stockage ou en modifiant les références d'espace de noms.

Scénarios de sauvegarde et de restauration compatibles

Vous pouvez combiner des champs d'application de sauvegarde sélectifs, des champs d'application de restauration et des règles de transformation pour prendre en charge des scénarios tels que les suivants :

  • Reprise après sinistre : sauvegardez toutes les charges de travail d'un cluster et restaurez-les dans un cluster distinct d'une autre région.
  • Rollback sélectif : sauvegardez toutes les charges de travail, mais effectuez un rollback sélectif d'une seule charge de travail corrompue ou mal configurée dans le cluster source.
  • Clonage d'espace de noms : sauvegardez les ressources d'un espace de noms et restaurez-les dans un nouvel espace de noms au sein du même cluster ou d'un cluster différent.
  • Migration de charge de travail : migrez ou clonez des charges de travail d'application d'un cluster GKE à un autre.
  • Mises à jour de la configuration du stockage : mettez à jour les paramètres de stockage lors de la restauration, par exemple en déplaçant une charge de travail d'un disque persistant zonal vers un disque persistant régional.

Pour sauvegarder des charges de travail, l'agent Sauvegarde pour GKE doit être activé sur le cluster source. Pour restaurer des charges de travail, le cluster cible doit déjà exister et l'agent Sauvegarde pour GKE doit y être activé.

Architecture de service

Sauvegarde pour GKE répartit les responsabilités entre un Google Cloud plan de contrôle service et un agent dans le cluster :

  • Le service Sauvegarde pour GKE : s'exécute dans Google Cloud l'infrastructure et sert de plan de contrôle centralisé. Le service fournit une API REST basée sur les ressources et alimente l'interface Sauvegarde pour GKE dans la Google Cloud console.
  • L'agent Sauvegarde pour GKE : s'exécute en tant que charge de travail dans chaque cluster GKE où des opérations de sauvegarde ou de restauration ont lieu. L'agent communique avec le service Sauvegarde pour GKE pour exécuter les tâches de sauvegarde et de restauration.

Le diagramme de l'architecture suivant illustre les interactions entre les outils utilisateur, le service Sauvegarde pour GKE et l'agent dans le cluster :

Schéma d'architecture montrant les clients utilisateur interagissant avec le service Sauvegarde pour GKE, qui se coordonne avec un agent du cluster pour sauvegarder et restaurer les ressources Kubernetes et les volumes persistants.

Comme illustré dans le schéma :

  1. Les clients envoient des requériques : les utilisateurs gèrent les sauvegardes et les restaurations via la Google Cloud console, Google Cloud CLI ou kubectl. Ces requêtes ciblent l'API consommateur (v1).
  2. Le plan de contrôle orchestre les jobs : le service Sauvegarde pour GKE traite les requêtes et se coordonne avec l'agent dans le cluster via l'API d'agent interne (v1agent).
  3. L'agent exécute les opérations : l'agent Sauvegarde pour GKE interagit avec le serveur d'API Kubernetes local pour capturer les fichiers manifestes de configuration ou appliquer les ressources restaurées.
  4. Les données sont stockées de manière sécurisée : les fichiers manifestes de configuration et les instantanés de volume de disque persistant sont stockés dans un projet locataire dédié géré par Google, isolé des ressources de calcul du cluster.

Service de plan de contrôle et ressources cloud

Le service Sauvegarde pour GKE expose une API REST qui gère les ressources dans la hiérarchie des ressources Google Cloud. Vous interagissez avec quatre principaux types de ressources :

Ressources opérationnelles

Les ressources opérationnelles représentent des exécutions individuelles de sauvegarde et de restauration :

  • Backup: représente la sauvegarde à un moment donné d'un cluster GKE ou d'un sous-ensemble de charges de travail. La création d'une ressource Backup lance le processus de sauvegarde, qui extrait les fichiers manifestes de configuration Kubernetes et lance les instantanés de volume de disque persistant. La suppression d'une ressource Backup supprime définitivement les artefacts de configuration et les instantanés de volume stockés.
  • Restore: représente la restauration des données et des configurations d'une ressource Backup spécifique dans un cluster GKE cible. La création d'une ressource Restore déclenche le workflow de restauration. La suppression d'une ressource Restore supprime l'historique d'exécution de la restauration de la base de données sans affecter les ressources exécutées dans le cluster.

Ressources de configuration

Les ressources de configuration définissent des règles réutilisables pour créer des sauvegardes et exécuter des restaurations :

  • BackupPlan : modèle de configuration qui définit quand et comment créer une chaîne de ressources Backup. Un plan de sauvegarde spécifie le cluster source, le champ d'application de la sauvegarde (toutes les charges de travail, les espaces de noms sélectionnés ou les applications protégées spécifiques), la planification, les paramètres de conservation et la région de stockage. Si vous stockez des sauvegardes dans une région différente de celle du cluster source, des frais de transfert de données réseau sortantes s'appliquent. Pour en savoir plus, consultez la page Tarifs de Sauvegarde pour GKE.
  • RestorePlan: modèle de configuration qui définit comment exécuter des restaurations à partir d'un plan de sauvegarde spécifié dans un cluster cible. Un plan de restauration spécifie le cluster cible, le champ d'application de la restauration, les règles de gestion des conflits de ressources, les règles de restauration des données de volume et les règles de transformation facultatives. Le cluster cible doit exister avant que vous puissiez créer un plan de restauration.

Opérations de l'agent dans le cluster

L'agent Sauvegarde pour GKE s'exécute en tant que charge de travail dans chaque cluster GKE où vous activez la protection des données. L'agent effectue les tâches suivantes :

  • Orchestration des sauvegardes:
    • Interroge le serveur d'API Kubernetes pour obtenir les fichiers manifestes de charge de travail correspondant au champ d'application du plan de sauvegarde.
    • Sérialise les fichiers manifestes de ressources dans une archive chiffrée et importe l'archive dans un stockage géré par Google.
    • Déclenche des instantanés de volume pour les volumes persistants associés aux ressources PersistentVolumeClaim.
  • Orchestration des restaurations:
    • Récupère l'archive de ressources à partir du stockage.
    • Applique les règles de transformation et les règles de résolution des conflits configurées.
    • Recrée les ressources Kubernetes dans le cluster cible.
    • Provisionne les volumes persistants à partir d'instantanés et les lie aux charges de travail dans le cluster cible.

Vous n'interagissez pas directement avec les pods de l'agent. Lorsque vous créez une ressource cloud Backup ou Restore, le service Sauvegarde pour GKE crée automatiquement les ressources personnalisées correspondantes (BackupJob ou RestoreJob) dans le cluster, que l'agent détecte et exécute.

Pour définir une logique personnalisée de sauvegarde et de restauration (par exemple, mettre en pause les écritures de base de données ou exécuter des scripts de pré-sauvegarde), vous pouvez définir ProtectedApplication des ressources personnalisées dans votre cluster.

Pour obtenir des informations historiques sur l'agent en preview pour les clusters GKE antérieurs à la version 1.24, consultez la section Abandon de l'agent en preview.

Redondance zonale et haute disponibilité

Sauvegarde pour GKE offre une haute disponibilité régionale en répliquant les composants de service et les données de sauvegarde dans plusieurs zones d'une Google Cloud région :

  • Résilience du plan de contrôle : le service de plan de contrôle Sauvegarde pour GKE est déployé dans au moins trois zones de chaque région compatible, ce qui garantit que les opérations d'API se poursuivent sans interruption si une zone individuelle subit une panne.
  • Réplication du stockage : les archives de configuration de sauvegarde et les instantanés de volume de disque persistant sont stockés avec une redondance régionale dans plusieurs zones.
  • Réplication gérée : le service s'appuie sur une infrastructure de stockage régionale Google Cloud pour gérer automatiquement la réplication, sans nécessiter de configuration manuelle au niveau de la zone.

Limites

Sauvegarde pour GKE protège les charges de travail Kubernetes et les volumes de disque persistant, mais exclut l'infrastructure de cluster et les services externes.

Sauvegarde pour GKE ne sauvegarde pas les ressources suivantes :

  • Configurations d'infrastructure de cluster : paramètres au niveau du cluster tels que les pools de nœuds, les types de machines, le nombre de nœuds, la configuration réseau et les fonctionnalités de cluster activées. Pour reproduire les configurations de cluster, utilisez des outils de type Infrastructure as Code tels que Terraform.
  • Binaires d'images de conteneurs : images de conteneurs référencées par les fichiers manifestes de pods. Sauvegarde pour GKE sauvegarde les fichiers manifestes YAML qui pointent vers les images de conteneurs, mais ne stocke pas les couches d'image. Vous devez conserver les images de conteneurs dans un registre d'artefacts tel qu' Artifact Registry.
  • Services et bases de données externes : état ou configuration des services situés en dehors du cluster Kubernetes, tels que les instances Cloud SQL, les buckets Cloud Storage ou les équilibreurs de charge externes.
  • Types de volumes de disque non persistants : types de volumes de stockage autres que les volumes persistants de disque persistant, tels que les partages NFS ou les instances Google Cloud NetApp Volumes. Toutefois, vous pouvez protéger les charges de travail sauvegardées par des instances Filestore à l'aide de hooks de sauvegarde personnalisés. Pour en savoir plus, consultez la section Gérer les volumes Filestore avec Sauvegarde pour GKE.

Étape suivante