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

Article
09/09/2024

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 Microsoft Azure sous Paramètres dans le menu service pour une instance AKS.

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 à la fois au niveau Opérationnel et au niveau Coffre. Le niveau Opérationnel est un magasin de données local (les sauvegardes sont stockées dans votre locataire sous forme d’instantanés). Vous pouvez désormais déplacer un point de récupération par jour et le stocker dans le niveau Coffre sous forme d’objets blob (en dehors de votre locataire) à l’aide de la sauvegarde AKS. Les sauvegardes stockées dans le coffre peuvent également être utilisées pour restaurer des données dans une région secondaire (région jumelée Azure).

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. Si vous avez défini des règles de conservation des données pour le niveau Coffre, les sauvegardes sont 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.

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

Remarque

Lors de la restauration, l’extension de sauvegarde attend que le conteneur s’affiche, puis exécute les commandes exec sur celui-ci, définies dans les hooks de restauration.
Si vous effectuez une restauration sur le même espace de noms sauvegardé, les hooks de restauration ne seront pas exécutés, car seul le nouveau conteneur généré est recherché. Ceci est indépendant du choix de stratégie, ignorer ou corriger.

Modifier la ressource lors de la restauration des sauvegardes sur un cluster AKS

Vous pouvez utiliser la fonctionnalité Modification des ressources pour modifier les ressources Kubernetes sauvegardées pendant la restauration en spécifiant des patchs JSON tels que configmap déployés dans le cluster AKS.

Créer et appliquer un configmap de modificateur de ressource pendant la restauration

Pour créer et appliquer la modification des ressources, procédez comme suit :

Créez des modificateurs de ressources configmap.

Vous devez créer un configmap dans votre espace de noms privilégié à partir d’un fichier YAML qui a défini des modificateurs de ressources.

Exemple de création de commande :
```
version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: "^mysql.*$"
    namespaces:
    - bar
    - foo
    labelSelector:
        matchLabels:
          foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"
  - operation: remove
    path: "/metadata/labels/test"
```
- Le configmap ci-dessus applique le patch JSON à toutes les copies de volume persistant dans la barre d’espaces de noms et foo dont le nom commence par mysql et match label foo: bar. Le patch JSON remplace le storageClassName par premium et supprime l’étiquette test des copies du volume persistant.
- Ici, l’Espace de noms est l’espace de noms d’origine de la ressource sauvegardée, et non le nouvel espace de noms où la ressource sera restaurée.
- Vous pouvez spécifier plusieurs patchs JSON pour une ressource particulière. Les patchs sont appliqués conformément à l’ordre spécifié dans le configmap. Un patch ultérieur est appliqué dans l’ordre. Si plusieurs patchs sont spécifiés pour le même chemin d’accès, le dernier patch remplace les patchs précédents.
- Vous pouvez spécifier plusieurs resourceModifierRules dans le configmap. Les règles sont appliquées conformément à l’ordre spécifié dans le configmap.
Création d’une référence de modificateur de ressource dans la configuration de restauration

Lorsque vous effectuez une opération de restauration, indiquez le nom du ConfigMap et l’Espace de noms où il est déployé dans le cadre de la configuration de restauration. Ces détails doivent être fournis sous les Règles de modificateur de ressources.

Opérations prises en charge par le Modificateur de ressource

Ajouter

Vous pouvez utiliser l’opération Ajouter pour ajouter un nouveau bloc au json de ressource. Dans l’exemple ci-dessous, l’opération ajoute les informations d’un nouveau conteneur à la spécification avec un déploiement.

version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
    # Dealing with complex values by escaping the yaml
  - operation: add
    path: "/spec/template/spec/containers/0"
    value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"

Remove

Vous pouvez utiliser l’opération Supprimer pour supprimer une clé du json de ressource. Dans l’exemple ci-dessous, l’opération supprime l’étiquette avec test comme clé.

version: v1
resourceModifierRules:
- conditions:
      groupResource: persistentvolumeclaims
      resourceNameRegex: "^mysql.*$"
      namespaces:
      - bar
      - foo
      labelSelector:
        matchLabels:
            foo: bar
  patches:
  - operation: remove
    path: "/metadata/labels/test"

Remplacer

Vous pouvez utiliser l’opération Remplacer pour remplacer une valeur pour le chemin mentionné par une autre. Dans l’exemple ci-dessous, l’opération remplace storageClassName dans la revendication de volume persistant par premium.

version: v1
resourceModifierRules:
- conditions:
     groupResource: persistentvolumeclaims
     resourceNameRegex: "^mysql.*$"
     namespaces:
     - bar
     - foo
     labelSelector:
        matchLabels:
           foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"

Copy

Vous pouvez utiliser l’opération Copier pour copier une valeur d’un chemin d’accès des ressources définies vers un autre chemin.

version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
  - operation: copy
    from: "/spec/template/spec/containers/0"
    path: "/spec/template/spec/containers/1"

Test

Vous pouvez utiliser l’opération Test pour vérifier si une valeur particulière est présente dans la ressource. Si la valeur est présente, le patch est appliqué. Si la valeur n’est pas présente, le patch n’est pas appliqué. Dans l’exemple ci-dessous, l’opération vérifie si les revendications de volume persistant ont premium en tant que storageClassName et les remplace par standard, si true.
```
version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: ".*"
    namespaces:
    - bar
    - foo
  patches:
  - operation: test
    path: "/spec/storageClassName"
    value: "premium"
  - operation: replace
    path: "/spec/storageClassName"
    value: "standard"
```
Patch JSON

Ce configmap applique le patch JSON à tous les déploiements dans les espaces de noms par défaut et « nginxwith the name that starts withnginxdep ». Le patch JSON met à jour le nombre de réplicas sur 12 pour tous ces déploiements.
```
version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"
```

Correctif de fusion JSON

Ce ConfigMap appliquera le patch de fusion JSON à tous les déploiements dans les espaces de noms par défaut et nginx dont le nom commence par nginxdep. Le patch de fusion JSON ajoute/met à jour l’étiquette « app » avec la valeur « nginx1 ».

version: v1
resourceModifierRules:
  - conditions:
      groupResource: deployments.apps
      resourceNameRegex: "^nginxdep.*$"
      namespaces:
        - default
        - nginx
    mergePatches:
      - patchData: |
          {
            "metadata" : {
              "labels" : {
                "app" : "nginx1"
              }
            }
          }

Correctif de fusion stratégique

Ce ConfigMap appliquera le patch de fusion stratégique à tous les pods de l’espace de noms par défaut dont le nom commence par nginx. Le patch de fusion stratégique met à jour l’image de nginx de conteneur vers mcr.microsoft.com/cbl-mariner/base/nginx:1.22

version: v1
resourceModifierRules:
- conditions:
    groupResource: pods
    resourceNameRegex: "^nginx.*$"
    namespaces:
    - default
  strategicPatches:
  - patchData: |
      {
        "spec": {
          "containers": [
            {
              "name": "nginx",
              "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22"
            }
          ]
        }
      }

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 Coffre : Pour stocker les données de sauvegarde pendant une durée plus longue et à un coût inférieur à celui des instantanés, la sauvegarde AKS prend en charge le magasin de données standard du coffre. 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.
Frais de stockage de sauvegarde : Sauvegarde Azure pour AKS prend également en charge les sauvegardes au niveau Coffre. Vous pouvez effectuer cette opération en définissant des règles de conservation des données pour coffre standard dans la stratégie de sauvegarde, avec un point de restauration par jour pouvant être déplacé dans le coffre. Les points de restauration stockés dans le niveau Coffre font l’objet d’une facturation de frais distincts appelés frais de stockage de sauvegarde en fonction du nombre total de données stockées (en Go) et du type de redondance activé sur le coffre de sauvegarde.

Étape suivante

Prérequis pour la sauvegarde Azure Kubernetes Service

Partager via

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

Comment fonctionne la sauvegarde AKS ?

Configurer une sauvegarde

Gérer la sauvegarde

Restaurer à partir d’une sauvegarde

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

Que sont les hooks personnalisés ?

Hooks de sauvegarde

Hooks de restauration

Modifier la ressource lors de la restauration des sauvegardes sur un cluster AKS

Créer et appliquer un configmap de modificateur de ressource pendant la restauration

Opérations prises en charge par le Modificateur de ressource

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

Comprendre les tarifs

Étape suivante

Commentaires

Ressources supplémentaires