Qu’est-ce que la sauvegarde Azure Kubernetes Service ?

  • Article

La sauvegarde Azure Kubernetes Service (AKS) est un processus natif cloud simple que vous pouvez utiliser pour sauvegarder et restaurer des applications conteneurisées et des données exécutées dans votre cluster AKS. Vous pouvez configurer des sauvegardes planifiées pour l’état du cluster et les données d’application stockées sur des volumes persistants dans Stockage sur disque Azure basés sur un pilote CSI. La solution vous offre un contrôle granulaire pour choisir un espace de noms spécifique ou un cluster entier à sauvegarder ou restaurer en stockant des sauvegardes localement dans un conteneur blob et en tant que captures instantanées de disque. Vous pouvez utiliser la sauvegarde AKS pour des scénarios de bout en bout, notamment la récupération opérationnelle, le clonage d’environnements de développement/test et les scénarios de mise à niveau de cluster.

La sauvegarde AKS s’intègre au Centre de sauvegarde dans Azure pour fournir un affichage unique qui vous permet de gérer, de monitorer, d’exploiter et d’analyser des sauvegardes à grande échelle. Vos sauvegardes sont également disponibles dans le Portail Azure sous Paramètres dans le menu des ressources d’une instance AKS.

Remarque

La sauvegarde dans un coffre et la restauration inter-région pour AKS en utilisant Sauvegarde Azure sont actuellement en préversion.

Comment fonctionne la sauvegarde AKS ?

Utilisez la sauvegarde AKS pour sauvegarder vos charges de travail AKS et vos volumes persistants déployés dans des clusters AKS. La solution nécessite l’installation d’une Extension de sauvegarde au sein du cluster AKS. Le coffre de sauvegarde communique avec l’extension pour effectuer des opérations liées à la sauvegarde et à la restauration. L’utilisation de l’extension de sauvegarde est obligatoire et elle doit être installée dans le cluster AKS pour permettre la sauvegarde et la restauration du cluster. Lorsque vous configurez la sauvegarde AKS, vous ajoutez des valeurs pour un compte de stockage et un conteneur blob dans lesquels les sauvegardes sont stockées.

Avec l’extension de sauvegarde, une identité utilisateur (appelée identité d’extension) est créée dans le groupe de ressources managé du cluster AKS. Le rôle Contributeur de compte de stockage est attribué à l’identité d’extension sur le compte de stockage où les sauvegardes sont stockées dans un conteneur blob.

Pour prendre en charge des clusters IP publics, privés et autorisés, la sauvegarde AKS nécessite l’activation de l’Accès approuvé entre le cluster AKS et le coffre de sauvegarde. L’accès approuvé permet au coffre de sauvegarde d’accéder au cluster AKS en raison d’autorisations spécifiques qui lui sont attribuées pour des opérations de sauvegarde. Pour obtenir plus d’informations sur l’accès approuvé AKS, consultez Activer des ressources Azure pour accéder aux clusters AKS en utilisant l’accès approuvé.

Remarque

La sauvegarde AKS vous permet de stocker des sauvegardes au niveau Opérationnel. Le niveau Opérationnel est un magasin de données locales (dans votre tenant comme captures instantanées). Vous pouvez désormais déplacer un point de récupération par jour et le stocker dans un niveau Coffre en tant que blob (en dehors de votre tenant) en utilisant une sauvegarde AKS. Vous pouvez également utiliser un coffre de sauvegardes pour gérer des sauvegardes.

Une fois l’extension de sauvegarde installée et l’accès approuvé activé, vous pouvez configurer des sauvegardes planifiées pour les clusters en fonction de votre stratégie de sauvegarde. Vous pouvez également restaurer les sauvegardes dans le cluster d’origine ou vers un autre cluster se trouvant dans le même abonnement et la même région. Vous pouvez choisir un espace de noms spécifique ou un cluster entier comme sauvegarde et restaurer la configuration lorsque vous configurez l’opération particulière.

La solution de sauvegarde permet d’effectuer des opérations de sauvegarde de vos sources de données AKS déployées dans le cluster et des données stockées dans le volume persistant du cluster, puis de stocker les sauvegardes dans un conteneur de blobs. Les volumes persistants basés sur disque sont sauvegardés en tant que captures instantanées de disque dans un groupe de ressources de captures instantanées. Les captures instantanées et l’état du cluster dans un blob s’associent pour former un point de récupération stocké dans votre tenant appelé niveau Opérationnel. Vous pouvez également convertir des sauvegardes (première sauvegarde réussie d’un jour, d’une semaine, d’un mois ou d’une année) du niveau Opérationnel en blobs, puis les déplacer vers un coffre (en dehors de votre tenant) une fois par jour.

Remarque

Sauvegarde Azure prend actuellement en charge les volumes persistants uniquement dans Stockage sur disque Azure basé sur un pilote CSI. Pendant les sauvegardes, la solution ignore d’autres types de volume persistant, tels que les blobs et le partage de fichiers Azure. Les sauvegardes sont également susceptibles d’être déplacées vers le coffre si les volumes persistants sont d’une taille inférieure ou égale à 1 To.

Configurer une sauvegarde

  • Pour configurer les sauvegardes de clusters AKS, créez d’abord un coffre de sauvegarde. Le coffre vous offre un affichage centralisé des sauvegardes configurées sur différentes sources de données. La sauvegarde AKS prend en charge les sauvegardes de niveau Opérationnel et Coffre.

    Remarque

    • Le coffre de sauvegarde et le cluster AKS que vous souhaitez sauvegarder ou restaurer doivent se trouver dans la même région et le même abonnement.
    • Le paramètre de redondance de stockage du coffre de sauvegardes (LRS/GRS) s’applique uniquement aux sauvegardes stockées dans le niveau Opérationnel. Si vous souhaitez utiliser des sauvegardes pour la récupération d’urgence, définissez la redondance de stockage comme GRS avec la restauration inter-région activée.

  • Une sauvegarde AKS déclenche automatiquement un travail de sauvegarde planifiée. Le travail copie les ressources du cluster dans un conteneur blob et crée une capture instantanée incrémentielle des volumes persistants basés sur le disque en fonction de la fréquence de sauvegarde. Les sauvegardes sont conservées dans le niveau Opérationnel et le niveau Coffre en fonction de la durée de rétention définie dans la stratégie de sauvegarde et sont supprimées une fois la durée terminée.

    Remarque

    Vous pouvez utiliser une sauvegarde AKS afin de créer plusieurs instances de sauvegarde pour un seul cluster AKS en utilisant différentes configurations de sauvegarde par instance de sauvegarde. Toutefois, chaque instance de sauvegarde d’un cluster AKS doit être créée dans un autre coffre de sauvegarde ou en utilisant une stratégie de sauvegarde distincte dans le même coffre de sauvegarde.

Gérer la sauvegarde

Une fois la configuration de sauvegarde terminée d’un cluster AKS, une instance de sauvegarde est créée dans le coffre de sauvegarde. Vous pouvez afficher l’instance de sauvegarde du cluster dans la section Sauvegarde d’une instance AKS dans le Portail Azure. Vous pouvez effectuer toutes les opérations liées à la sauvegarde pour l’instance (par exemple lancer des restaurations, effectuer un monitoring, arrêter la protection, etc.) via son instance de sauvegarde correspondante.

Par ailleurs, la sauvegarde AKS s’intègre directement au centre de sauvegarde pour vous permettre de gérer de manière centralisée la protection de tous vos clusters AKS, ainsi que d’autres charges de travail prises en charge par la sauvegarde. Le centre de sauvegarde constitue un affichage unique de toutes vos exigences de sauvegarde, telles que les travaux de monitoring et l’état des sauvegardes et restaurations. Le centre de sauvegarde vous permet de veiller à la conformité et à la gouvernance, d’analyser l’utilisation de sauvegardes et d’effectuer des opérations essentielles pour sauvegarder et restaurer des données.

Une sauvegarde AKS utilise l’identité managée pour accéder à d’autres ressources Azure. Pour configurer la sauvegarde d’un cluster AKS et effectuer une restauration à partir d’une sauvegarde antérieure, l’identité managée du coffre de sauvegarde nécessite un ensemble d’autorisations sur le cluster AKS et le groupe de ressources de captures instantanées où les instantanés sont créés et gérés. Le cluster AKS nécessite actuellement un ensemble d’autorisations sur le groupe de ressources de captures instantanées. En outre, l’extension de sauvegarde crée une identité utilisateur et affecte un ensemble d’autorisations pour accéder au compte de stockage où les sauvegardes sont stockées dans un blob. Pour accorder des autorisations à l’identité managée, vous pouvez utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure. Une identité managées est un type spécial de principal de service pouvant uniquement être utilisé avec des ressources Azure. En savoir plus sur les identités managées.

Restaurer à partir d’une sauvegarde

Il est possible de restaurer des données à partir de tous les points dans le temps pour lesquels un point de récupération existe. Un point de récupération est créé lorsqu’une instance de sauvegarde est à l’état protégé et peut être utilisée pour restaurer des données jusqu’à ce qu’elles soient conservées par la stratégie de sauvegarde.

Sauvegarde Azure vous donne la possibilité de restaurer tous les éléments sauvegardés ou d’utiliser des contrôles granulaires pour sélectionner des éléments spécifiques à partir des sauvegardes en choisissant des espaces de noms et d’autres options de filtre. De plus, vous pouvez effectuer la restauration sur le cluster AKS d’origine (le cluster sauvegardé) ou sur un autre cluster AKS. Vous pouvez restaurer des sauvegardes stockées dans les niveaux Opérationnel et Coffre de cluster dans un abonnement identique ou différent. Seules les sauvegardes stockées dans un niveau Coffre peuvent être utilisées pour effectuer une restauration vers le cluster d’une région différente (région Azure jumelée).

Pour restaurer une sauvegarde stockée dans un niveau Coffre, vous devez fournir un emplacement intermédiaire dans lequel les données de sauvegarde sont alimentées. Cet emplacement intermédiaire inclut un groupe de ressources et un compte de stockage au sein de celui-ci dans la même région et un abonnement comme cluster cible pour la restauration. Pendant la restauration, des ressources spécifiques (conteneur de blobs, disque et captures instantanées de disque) sont créées dans le cadre de l’alimentation, lesquelles sont ensuite effacées une fois l’opération de restauration terminée.

Sauvegarde Azure pour AKS prend actuellement en charge les deux options suivantes lorsque vous effectuez une opération de restauration en cas de conflit de ressources (la ressource sauvegardée porte le même nom que la ressource du cluster AKS cible). Vous pouvez choisir l’une de ces options lorsque vous définissez la configuration de la restauration.

  1. Ignorer : cette option est sélectionnée par défaut. Par exemple, si vous avez sauvegardé une revendication de volume persistant (PVC) appelée pvc-azuredisk et que vous la restaurez dans un cluster cible portant le même nom, l’extension de sauvegarde ignore la restauration de la revendication PVC sauvegardée. Dans de tels scénarios, nous vous recommandons de supprimer la ressource du cluster, puis de procéder à l’opération de restauration afin que les éléments sauvegardés soient uniquement disponibles dans le cluster et qu’ils ne soient pas ignorés.

  2. Patch : cette option permet la variable mutable de mise à jour corrective dans la ressource sauvegardée sur la ressource du cluster cible. Si vous souhaitez mettre à jour le nombre de réplicas dans le cluster cible, vous pouvez opter pour la mise à jour corrective en tant qu’opération.

Remarque

Actuellement, la sauvegarde AKS n’effectue pas la suppression et la recréation des ressources dans le cluster cible si elles existent déjà. Si vous essayez de restaurer des volumes persistants dans l’emplacement d’origine, supprimez les volumes persistants existants, puis effectuez l’opération de restauration.

Utiliser des hooks personnalisés pour la sauvegarde et la restauration

Vous pouvez utiliser des hooks personnalisés pour effectuer des captures instantanées cohérentes avec les applications des volumes utilisés pour des bases de données déployées en tant que charges de travail conteneurisées.

Que sont les hooks personnalisés ?

Vous pouvez utiliser une sauvegarde AKS pour exécuter des hooks personnalisés dans le cadre d’une opération de sauvegarde et de restauration. Les hooks sont des commandes configurées permettant d’exécuter une ou plusieurs commandes qui s’exécutent dans un pod sous un conteneur pendant une opération de sauvegarde ou après une restauration. Vous définissez ces hooks en tant que ressource personnalisées et vous les déployez dans le cluster AKS que vous souhaitez sauvegarder ou restaurer. Quand la ressource personnalisée est déployée dans le cluster AKS de l’espace de noms requis, vous fournissez les informations comme entrées pour le flux afin de configurer une sauvegarde et une restauration. L’extension de sauvegarde exécute les hooks comme défini dans un fichier YAML.

Remarque

Les Hooks ne sont pas exécutés dans un interpréteur de commandes sur les conteneurs.

Une sauvegarde dans AKS dispose de deux types de hook :

  • Hooks de sauvegarde
  • Hooks de restauration

Hooks de sauvegarde

Dans un hook de sauvegarde, vous pouvez configurer les commandes pour l’exécuter avant tout traitement d’action personnalisée (hooks antérieurs), ou une fois que toutes les actions personnalisées sont terminées et que tous les éléments supplémentaires spécifiés par les actions personnalisées sont sauvegardés (hooks postérieurs).

Par exemple, voici le modèle YAML pour une ressource personnalisée à déployer en utilisant des hooks de sauvegarde :

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
  # BackupHook CR Name and Namespace
  name: bkphookname0
  namespace: default
spec:
  # BackupHook is a list of hooks to execute before and after backing up a resource.
  backupHook:
    # BackupHook Name. This is the name of the hook that will be executed during backup.
    # compulsory
  - name: hook1
    # Namespaces where this hook will be executed.
    includedNamespaces: 
    - hrweb
    excludedNamespaces:
    labelSelector:
    # PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
    preHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute.
          command:
            - /bin/uname
            - -a
          # OnError specifies how Velero should behave if it encounters an error executing this hook  
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          timeout: 10s
      - exec:
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: webcontainer
          onError: Continue
    # PostHooks is a list of BackupResourceHooks to execute after backing up an item.
    postHooks:
      - exec:
          container: webcontainer
          command:
            - /bin/uname
            - -a
          onError: Continue
          timeout: 10s

Hooks de restauration

Avec le script de hook de restauration, les commandes personnalisées ou les scripts sont écrits pour être exécutés dans les conteneurs d’un pod AKS restauré.

Voici le modèle YAML pour une ressource personnalisée à déployer en utilisant des hooks de restauration :

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
  name: restorehookname0
  namespace: default
spec:
  # RestoreHook is a list of hooks to execute after restoring a resource.
  restoreHook:
    # Name is the name of this hook.
  - name: myhook-1  
    # Restored Namespaces where this hook will be executed.
    includedNamespaces: 
    excludedNamespaces:
    labelSelector:
    # PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
    postHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute from within a container after a pod has been restored.
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          # OnError specifies how Velero should behave if it encounters an error executing this hook
          # default value is Continue
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          execTimeout: 30s
          # WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
          waitTimeout: 5m

Découvrez comment utiliser des hooks pendant une sauvegarde AKS.

Quel niveau de stockage de sauvegarde ne prend pas en charge la sauvegarde AKS ?

Sauvegarde Azure pour AKS prend en charge deux niveaux de stockage comme magasin de données de sauvegarde :

  • Niveau Opérationnel : l’extension de sauvegarde installée dans le cluster AKS prend d’abord la sauvegarde en récupérant des captures instantanées de volume via un pilote CSI et stocke l’état du cluster dans un conteneur de blobs dans votre propre tenant. Ce niveau prend en charge un objectif de point de récupération (RPO) plus faible avec la durée minimale de quatre heures entre deux sauvegardes. En outre, pour les volumes basés sur Azure Disk, le niveau Opérationnel prend en charge les restaurations plus rapides.

  • Niveau standard de coffre (préversion) : pour stocker des données de sauvegarde pendant une durée plus longue à un coût inférieur à celui des captures instantanées, la sauvegarde AKS prend en charge le magasin de données au niveau Coffre standard. En fonction des règles de rétention définies dans la stratégie de sauvegarde, la première sauvegarde réussie (du jour, de la semaine, du mois ou de l’année) est déplacée vers un conteneur de blobs en dehors de votre tenant. Ce magasin de données permet non seulement une rétention plus longue, mais il offre également une protection contre les rançongiciels. Vous pouvez également déplacer des sauvegardes stockées dans le coffre d’une autre région (région Azure jumelée) pour la récupération en activant la Redondance géographique et la Restauration inter-région dans le coffre de sauvegarde.

Remarque

Vous pouvez stocker des données de sauvegarde dans un magasin de données standard au niveau du coffre via une stratégie de sauvegarde en définissant des règles de rétention. Seul un point de récupération planifié par jour est déplacé vers un niveau Coffre. Cependant, vous pouvez déplacer un nombre de sauvegardes à la demande vers le coffre selon la règle sélectionnée.

Comprendre les tarifs

Vous encourez des frais pour :

  • Frais d’instance protégée : Sauvegarde Azure pour AKS facture des frais d’instance protégée par espace de noms et par mois. Lorsque vous configurez une sauvegarde pour un cluster AKS, une instance protégée est créée. Chaque instance a un nombre spécifique d’espaces de noms qui sont sauvegardés tel que défini dans la configuration de sauvegarde. Pour obtenir plus d’informations sur la tarification des sauvegardes AKS, voir Tarification des sauvegardes cloud et sélectionner Azure Kubernetes Service en tant que charge de travail

  • Frais d’instantané : Sauvegarde Azure pour AKS protège un volume persistant basé sur disque en prenant des captures instantanées stockées dans le groupe de ressources de votre abonnement Azure. Ces captures instantanées entraînent des frais de stockage d’instantanés. Les instantanés n’étant pas copiés dans le coffre de sauvegarde, aucun frais de stockage de sauvegarde ne s’applique. Pour obtenir plus d’informations sur la tarification des captures instantanées, consultez Tarification des disques managés.

Étape suivante

Prérequis pour la sauvegarde Azure Kubernetes Service