Forum aux questions sur sauvegarde Azure pour Azure Kubernetes Service

Cet article répond aux questions fréquemment posées sur sauvegarde Azure pour Azure Kubernetes Service. Pour plus d’informations sur la disponibilité de la région Azure Backup pour AKS , les scénarios pris en charge et les limitations, consultez la matrice de prise en charge.

Questions fréquentes

Pourquoi dois-je installer l’extension de sauvegarde AKS dans mon cluster AKS pour activer la sauvegarde de mon cluster AKS ?

Vous devez installer l’extension de sauvegarde AKS dans votre cluster AKS pour activer la sauvegarde, car elle intègre votre cluster au service de sauvegarde natif d’Azure, fournissant une gestion centralisée, l’automatisation et la sécurité de vos sauvegardes. L’extension interagit avec les API Kubernetes pour garantir que les charges de travail Kubernetes (volumes persistants, configurations et métadonnées) sont correctement sauvegardées et restaurées.

Quelles sont les entrées requises pour l’installation de l’extension de sauvegarde AKS ? Ces entrées ont-elles des exigences spécifiques ?

L’installation de l’extension de sauvegarde AKS nécessite un compte de stockage et un conteneur d’objets blob en tant qu’entrées. Le compte de stockage doit se trouver dans la même région que le cluster AKS et le conteneur d’objets blob doit se trouver dans le même compte de stockage. Le conteneur d’objets blob est utilisé pour stocker les données de sauvegarde et les métadonnées associées. Les exigences spécifiques pour le compte de stockage et le conteneur d’objets blob sont les suivantes :

• Le compte de stockage doit être de Standard general-purpose v2 type.
• Le conteneur d’objets blob doit être créé dans le compte de stockage avant d’installer l’extension de sauvegarde AKS.
• Le conteneur d’objets blob doit de préférence être vide avant l’installation ou au moins ne doit pas contenir de données associées à une sauvegarde, car l’extension crée sa propre structure de dossiers dans le conteneur pour stocker les données de sauvegarde et les métadonnées.
• Si le cluster AKS se trouve dans un réseau privé, le compte de stockage doit être accessible à partir du cluster AKS. Pour ce faire, utilisez un point de terminaison privé pour le compte de stockage ou configurez les règles réseau nécessaires pour autoriser l’accès du cluster AKS au compte de stockage.

Quelles sont les exigences à remplir par les NodePools du cluster AKS pour installer l’extension de sauvegarde dans celle-ci ?

Les pods associés à l’extension de sauvegarde AKS sont déployés sur les pools de nœuds du cluster AKS. Pour déployer correctement ces pods et les empêcher d’interférer avec vos ressources d’application, vérifiez les points suivants :

• Le cluster AKS doit avoir le pool de nœuds de l’agent avec le Linux système d’exploitation, y compris Azure Linux et Ubuntu.
• Le pool de nœuds de l’agent doit avoir des références SKU VMSS basées sur une architecture non ARM64.
• Le pool de nœuds de l’agent doit avoir la teinte CriticalAddOnOnly associée. Cette teinte est automatiquement ajoutée au pool de nœuds lorsque le cluster AKS est créé via le portail. Il garantit que seuls les pods d’extension critiques, tels que les pods d’extension de sauvegarde AKS, sont planifiés sur le pool de nœuds. Cela empêche les interférences avec vos charges de travail d’application et garantit que les opérations de sauvegarde sont isolées des autres charges de travail du cluster. Si la teinte n’est pas présente, vous pouvez l’ajouter manuellement avant d’installer l’extension de sauvegarde AKS.

Quelles sont les exigences en matière de processeur et de mémoire pour l’extension de sauvegarde AKS ?

Sauvegarde Azure pour AKS s’appuie sur des pods déployés dans le cluster AKS dans le cadre de l’extension de sauvegarde sous l’espace de noms dataprotection-microsoft. Pour effectuer des opérations de sauvegarde et de restauration, ces pods ont des exigences spécifiques en matière de processeur et de mémoire.

• Mémoire : requêtes - 256Mi, limites - 1280Mi
• PROCESSEUR : requêtes - 500m, limites - 1000m

Quand j’installe l’extension de sauvegarde AKS, quelles ressources Kubernetes sont déployées dans le cluster ?

Lorsque vous installez l’extension de sauvegarde AKS, les ressources liées à la sauvegarde sont déployées dans le cluster sous l’espace dataprotection-microsoft de noms. Les trois déploiements suivants sont créés dans cet espace de noms :

dataprotection-microsoft-controller dataprotection-microsoft-geneva-service dataprotection-microsoft-kubernetes-agent

En outre, étant donné que l’extension de sauvegarde AKS est basée sur les extensions Arc pour la plateforme AKS, deux déploiements supplémentaires sont créés dans l’espace kube-system de noms :

extension-agent extension-operator

Ces déploiements prennent non seulement en charge l’extension de sauvegarde, mais sont également nécessaires pour d’autres extensions, telles que Flux et Azure Machine Learning.

Lors de l’installation de l’extension de sauvegarde AKS, quelles autres ressources Azure sont créées dans l’abonnement ?

Dans le cadre de l’installation de l’extension de sauvegarde, une identité utilisateur est également créée dans le groupe de ressources Node du cluster. Cette identité est utilisée par l’extension de sauvegarde AKS pour accéder aux ressources Azure requises pour les opérations de sauvegarde. L’identité utilisateur est affectée Storage Blob Data Contributor au rôle sur le compte de stockage pour activer l’accès pour l’extension. Chaque fois que l’extension est désinstallée du cluster AKS, l’identité est également supprimée.

Pourquoi Velero ne doit-il pas être utilisé dans le cluster en même temps que l’extension de sauvegarde AKS ?

Velero est une solution de sauvegarde tierce pour Kubernetes qui peut entrer en conflit avec l’extension de sauvegarde AKS. Il est recommandé d’utiliser uniquement l’extension de sauvegarde AKS pour les opérations de sauvegarde dans un cluster, mais pas les deux simultanément. L’extension de sauvegarde AKS déploie également des CRD Velero dans le cluster. Dans le cas où Velero autonome est installé dans le cluster AKS, ainsi que l’extension de sauvegarde et les versions utilisées par chaque installation diffèrent à tout moment peut entraîner des défaillances en raison d’incompatibilités de contrat. En outre, des configurations Velero personnalisées créées par l’utilisateur ( par exemple, une capture instantanée basée sur VolumeSnapshotClass pour Velero CSI) peuvent interférer avec la configuration de l’instantané de sauvegarde AKS. Les annotations Velero contenant des velero.io ressources différentes dans le cluster peuvent également avoir un impact sur le comportement de la sauvegarde AKS de manière non prise en charge.

Qu’est-ce qu’un groupe de ressources d’instantanés ?

Sauvegarde Azure pour AKS offre une sauvegarde de niveau opérationnel pour les clusters AKS. Ainsi, les instantanés des volumes persistants basés sur disque Azure créés pendant les opérations de sauvegarde planifiées et à la demande sont stockés dans un groupe de ressources au sein de votre abonnement. Sauvegarde Azure offre une restauration instantanée, car les instantanés incrémentiels sont stockés dans votre abonnement. Ce groupe de ressources est appelé « groupe de ressources d’instantanés ». Il est obligatoire de fournir un groupe de ressources d’instantané pendant la configuration de sauvegarde et une fois qu’il n’a pas été affecté, il ne peut pas être modifié.

Qu’est-ce qu’un groupe de ressources intermédiaire et un compte de stockage ?

Lorsque les sauvegardes doivent être restaurées à partir du niveau Coffre, un groupe de ressources intermédiaire et un compte de stockage sont requis. Pendant cette restauration, les données de sauvegarde dans le coffre sont d’abord hydratées à l’emplacement intermédiaire, puis l’extension installée dans le cluster restaure ces données dans le cluster AKS cible. Le groupe de ressources intermédiaire est utilisé pour recréer temporairement les disques sauvegardés. Le compte de stockage intermédiaire est utilisé pour stocker les ressources Kubernetes stockées dans les données de sauvegarde dans le niveau coffre. Les éléments de sauvegarde une fois créés à l’emplacement intermédiaire doivent être nettoyés manuellement.

Quels sont les types de volumes persistants pris en charge par Sauvegarde Azure pour AKS ?

Sauvegarde Azure pour AKS s’appuie sur des captures instantanées basées sur des pilotes CSI pour ses opérations de sauvegarde et de restauration. En raison de cette dépendance, seuls les volumes persistants basés sur disque Azure attachés via le pilote CSI sont actuellement pris en charge. D’autres options de stockage Azure, telles que le partage de fichiers Azure, l’objet blob Azure, le stockage conteneur Azure, Azure NetApp Files, Azure Managed Lustre et les solutions de stockage tierces, ne sont pas prises en charge pour l’instant. Dans les disques Azure, les références SKU suivantes sont prises en charge :

• SSD de qualité supérieure
• Standard SSD
• Disque dur standard

Toutefois, les disques SSD Premium v2 et Ultra ne sont pas pris en charge. En outre, quand il s’agit de disques Azure avec des paramètres d’accès réseau :

• Le niveau opérationnel prend en charge les disques d’accès public et privé de toute taille.
• Le niveau coffre prend uniquement en charge les disques d’accès public, avec une taille maximale pouvant atteindre 1 To.

Si un cluster AKS a des volumes persistants de types non pris en charge, que se passe-t-il pendant l’opération de sauvegarde ?

Si un cluster AKS contient des volumes persistants de types non pris en charge, ces volumes sont ignorés pendant l’opération de sauvegarde. La sauvegarde globale réussit toujours, mais les volumes non pris en charge ne seront pas inclus dans la sauvegarde.

Quels sont les niveaux de stockage de sauvegarde disponibles dans Sauvegarde Azure pour AKS ?

Sauvegarde Azure pour AKS prend en charge deux types de niveaux de stockage de sauvegarde :

• Niveau opérationnel : ce niveau est utilisé pour la rétention à court terme des sauvegardes. Il stocke les instantanés incrémentiels des volumes persistants au sein de votre abonnement en tant que sauvegarde. Ce niveau est idéal pour les restaurations rapides et les scénarios de récupération opérationnelle.
• Niveau du coffre : ce niveau est utilisé pour la rétention à long terme des sauvegardes. Il stocke les données de sauvegarde stockées dans le niveau opérationnel, les convertissent en objets blob de blocs, puis les stockent dans des comptes de stockage (appelés Coffre) dans un locataire Azure sécurisé géré par Microsoft. Ce niveau est idéal pour la conformité et les exigences réglementaires, car il vous permet de conserver les sauvegardes pendant des périodes prolongées dans un niveau de stockage à faible coût.

Vous pouvez définir le niveau de stockage de sauvegarde lorsque vous créez une stratégie de sauvegarde. La règle par défaut consiste à utiliser le niveau opérationnel pour la sauvegarde. Vous pouvez ajouter d’autres règles pour sauvegarder des données dans le niveau coffre, ainsi que le niveau opérationnel.

À quelle fréquence les sauvegardes sont-elles effectuées dans le niveau opérationnel et le niveau Coffre ?

La fréquence de sauvegarde est définie dans la stratégie de sauvegarde.

• Dans le niveau opérationnel, les sauvegardes peuvent être effectuées aussi fréquemment que toutes les 4 heures.
• Dans le niveau du coffre, une seule sauvegarde par jour peut être stockée.

Vous pouvez configurer des règles pour déplacer la première sauvegarde réussie du jour, de la semaine, du mois ou de l’année dans le niveau coffre. Ces paramètres peuvent être personnalisés en fonction des objectifs de point de récupération et des exigences de rétention.

Quel est le délai maximal que je peux attendre dans l’heure de début de la sauvegarde planifiée à partir de l’heure de sauvegarde planifiée pour Sauvegarde Azure pour AKS ?

Les sauvegardes planifiées sont effectuées dans une fenêtre de 2 heures à partir de l’heure planifiée conformément à la stratégie de sauvegarde. Ainsi, vous pouvez vous attendre à un délai maximal de 2 heures dans l’heure de début de la sauvegarde planifiée à partir de l’heure de sauvegarde planifiée pour la sauvegarde AKS.

Quelles sont les sauvegardes rapides créées dans le niveau opérationnel et éligibles pour être déplacées vers le coffre, sont déplacées vers le niveau coffre ?

Une fois qu’une sauvegarde est créée dans le niveau opérationnel et si elle est conformément aux règles définies dans la stratégie de sauvegarde, elle devient éligible immédiatement au coffre. Après cela, le transfert vers le niveau du coffre est lancé au cours des 4 prochaines heures.

Comment Azure Backup détermine-t-il quels points de récupération sont conservés chaque semaine, mensuelle ou annuelle dans une stratégie de sauvegarde ?

Une stratégie de sauvegarde qui inclut la rétention « première réussite de la semaine/mois/année » sélectionne la première sauvegarde réussie de chaque semaine, mois ou année et la conserve en fonction de la durée de rétention spécifiée. La définition de « first » est définie par le système, par exemple :

• Semaine: Dimanche est considéré comme le début de la semaine
• Mois: Le premier jour du mois
• Année: 1er janvier

Ce comportement n’est pas basé sur la date à laquelle la stratégie a été créée ou activée.

Puis-je sauvegarder un cluster AKS à l’aide de la solution Sauvegarde Azure plusieurs fois en fonction de ma définition d’application ?

Un cluster AKS peut héberger plusieurs applications simultanément, chacune étendue à différents espaces de noms. Sauvegarde Azure vous permet de sauvegarder un cluster AKS plusieurs fois en fonction des configurations d’application différentes, dans différents coffres de sauvegarde ou à l’aide de différentes stratégies de sauvegarde dans le même coffre de sauvegarde.

Comment puis-je effectuer mes sauvegardes pour un cluster AKS redondant géographiquement et disponible pour la restauration en cas de panne régionale ?

Sauvegarde Azure pour AKS prend en charge les sauvegardes géoredondantes, ce qui vous permet de restaurer vos données dans une autre région Azure en cas de panne régionale. Les données de sauvegarde sont redondantes en la répliquant vers une région jumelée Azure.

Pour rendre vos sauvegardes géographiquement redondantes, la première étape consiste à les configurer dans un coffre de sauvegarde qui a Geo-Redundancy activé et la restauration entre régions activées.

Ensuite, configurez l’instance de sauvegarde avec une stratégie de sauvegarde qui inclut des règles de rétention pour le niveau Coffre.

Avec ces paramètres en place, une fois qu’une sauvegarde est déplacée vers le niveau du coffre, elle est automatiquement répliquée dans la région Azure secondaire jumelée.

En cas de panne régionale, vous pouvez restaurer la sauvegarde à partir de la région secondaire à l’aide du portail Azure ou d’Azure CLI.

Quel est le RPO pris en charge par Sauvegarde Azure pour AKS s’il existe une disponibilité des données de sauvegarde dans la région secondaire ?

Une fois qu’une sauvegarde est déplacée dans le niveau coffre, il peut prendre jusqu’à 12 heures pour qu’elle soit répliquée dans la région secondaire. Par conséquent, le RPO maximal d’un point de restauration à mettre à disposition dans les régions secondaires prises en charge par Sauvegarde Azure pour AKS s’il existe une disponibilité des données de sauvegarde dans la région secondaire est d’heures. Cela signifie que, en cas de panne régionale, vous pouvez restaurer vos données de sauvegarde à partir de la région secondaire avec une perte de données maximale de 24 heures.

Pourquoi dois-je fournir des attributions de rôles pour pouvoir configurer des sauvegardes, effectuer des sauvegardes planifiées et à la demande et effectuer des opérations de restauration ?

Sauvegarde Azure pour AKS utilise l’approche de privilège minimum pour découvrir, protéger et restaurer les clusters AKS dans vos abonnements. Pour ce faire, Sauvegarde Azure utilise l’identité managée du coffre de sauvegarde pour accéder à d’autres ressources Azure. Vous pouvez accorder des autorisations à l’identité managée, au système affecté ou à l’utilisateur affecté à l’aide du contrôle d’accès en fonction du rôle Azure (Azure RBAC). L’identité managée est un principal de service d’un type spécial qui ne peut être utilisé qu’avec des ressources Azure. Par défaut, le coffre de sauvegarde n’a pas l’autorisation d’accéder au cluster AKS à sauvegarder, de créer des instantanés périodiques, de supprimer des instantanés après la période de rétention et de restaurer une sauvegarde. En accordant explicitement des attributions de rôles à l’identité managée du coffre de sauvegarde, vous contrôlez la gestion des autorisations sur les ressources des abonnements.

Quelles sont les autorisations utilisées par Sauvegarde Azure lors des opérations de sauvegarde et de restauration ?

Voici les actions utilisées dans le rôle Contributeur affecté sur le cluster AKS à sauvegarder ou restaurer sur :

1. Microsoft.Compute/snapshots/read
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/delete

Voici les actions utilisées dans le rôle Contributeur aux données Blob de stockage attribuée à l’identité d’extension du cluster AKS sauvegardé ou restauré sur le compte de stockage :

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/containers/write
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
4. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
5. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
6. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Voici les actions utilisées dans le rôle Lecteur attribué sur le coffre de sauvegarde sur le cluster AKS :

1. */lire

Voici les actions utilisées dans le rôle Lecteur attribué dans le coffre de sauvegarde sur le groupe de ressources d’instantané :

1. Microsoft.Authorization/*/read
2. Microsoft.Resources/subscriptions/resourceGroups/read

Voici les actions utilisées dans le rôle Contributeur d’instantané de disque attribué sur le coffre de sauvegarde sur le groupe de ressources d’instantané au cas où les sauvegardes doivent être stockées dans le niveau coffre :

1. Microsoft.Compute/snapshots/delete
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/read
4. Microsoft.Compute/snapshots/beginGetAccess/action
5. Microsoft.Compute/snapshots/endGetAccess/action
6. Microsoft.Compute/disks/beginGetAccess/action

Voici les actions utilisées dans le rôle Opérateur de données pour disques managés attribués sur le coffre de sauvegarde sur le groupe de ressources d’instantané au cas où les sauvegardes doivent être stockées au niveau du coffre :

1. Microsoft.Compute/disks/download/action
2. Microsoft.Compute/snapshots/download/action

Voici les actions utilisées dans le rôle Lecteur de données blob du stockage attribué sur le coffre de sauvegarde sur le compte de stockage au cas où les sauvegardes doivent être stockées dans le niveau coffre :

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Voici les actions utilisées dans le rôle Contributeur affecté sur le coffre de sauvegarde sur le groupe de ressources intermédiaire au cas où les sauvegardes doivent être restaurées à partir du niveau coffre :

1. Microsoft.Resources/subscriptions/resourceGroups/read
2. Microsoft.Authorization/*/read
3. Microsoft.Compute/snapshots/*
4. Microsoft.Compute/disks/*

Voici les actions utilisées dans le rôle Contributeur de compte de stockage attribué sur le coffre de sauvegarde sur le compte de stockage intermédiaire au cas où les sauvegardes doivent être restaurées à partir du niveau coffre :

1. Microsoft.Authorization/*/read
2. Microsoft.Storage/storageAccounts/*

Voici les actions utilisées dans le rôle Propriétaire des données blob de stockage attribuées sur le coffre de sauvegarde sur le compte de stockage intermédiaire au cas où les sauvegardes doivent être restaurées à partir du niveau coffre :

1. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*

Les captures instantanées de tous les volumes persistants dans une configuration de sauvegarde sont-elles prises en même temps, ou y a-t-il un délai ?

La sauvegarde Azure pour AKS ne prend actuellement pas en charge la prise d’instantanés de tous les PVS en millisecondes exactement. Bien que les opérations d’instantané soient lancées en parallèle, il peut y avoir de légères retards entre les captures instantanées PV individuelles en raison de l’infrastructure et du minutage de l’API. Pour obtenir une cohérence entre plusieurs PVS, Sauvegarde Azure prend en charge les sauvegardes cohérentes avec les applications à l’aide de hooks. Les hooks permettent aux utilisateurs de suspendre les écritures d’applications avant la capture instantanée et de les reprendre par la suite. Cette approche améliore la cohérence et imite la cohérence des incidents, bien qu’elle ne soit pas équivalente à de véritables instantanés simultanés ou à une cohérence coordonnée au niveau de la base de données.

Que se passe-t-il si je sélectionne l’option « Ignorer » pour les ressources Kubernetes, y compris les PVC pendant une restauration AKS ?

La sélection de « Ignorer » signifie que le processus de restauration ne tente pas de recréer des ressources Kubernetes. Si des ressources correspondantes existent déjà dans le cluster cible, elles seront réutilisées as-is. S’il n’existe pas, Sauvegarde Azure tente de les recréer dynamiquement. En cas de VV, vérifiez que les définitions et autorisations StorageClass compatibles existent dans l’environnement cible.

Pourquoi mon cluster restauré tente-t-il de monter des PVCs à partir du cluster source d’origine ?

Cela se produit généralement lorsque le cluster restauré fait référence à des volumes persistants (PVS) qui pointent toujours vers le groupe de ressources source d’origine. AKS sépare les ressources de cluster en deux groupes de ressources : un pour le plan de contrôle et un autre pour l’infrastructure (comme les disques). Si le mappage PVC-to-PV n’a pas été correctement mis à jour lors de la restauration, les charges de travail restaurées peuvent tenter d’attacher des PVS sources, ce qui entraîne des erreurs. Assurez-vous que le processus de restauration remapise correctement les PVC sur des pc nouveaux ou existants dans le groupe de ressources du cluster cible.

Étapes suivantes

• Matrice de prise en charge d’Azure Backup pour AKS

Cet article répond aux questions fréquemment posées sur sauvegarde Azure pour Azure Kubernetes Service. Pour plus d’informations sur la disponibilité de la région Azure Backup pour AKS , les scénarios pris en charge et les limitations, consultez la matrice de prise en charge.

Questions fréquentes

Vous devez installer l’extension de sauvegarde AKS dans votre cluster AKS pour activer la sauvegarde, car elle intègre votre cluster au service de sauvegarde natif d’Azure, fournissant une gestion centralisée, l’automatisation et la sécurité de vos sauvegardes. L’extension interagit avec les API Kubernetes pour garantir que les charges de travail Kubernetes (volumes persistants, configurations et métadonnées) sont correctement sauvegardées et restaurées.

L’installation de l’extension de sauvegarde AKS nécessite un compte de stockage et un conteneur d’objets blob en tant qu’entrées. Le compte de stockage doit se trouver dans la même région que le cluster AKS et le conteneur d’objets blob doit se trouver dans le même compte de stockage. Le conteneur d’objets blob est utilisé pour stocker les données de sauvegarde et les métadonnées associées. Les exigences spécifiques pour le compte de stockage et le conteneur d’objets blob sont les suivantes :

• Le compte de stockage doit être de Standard general-purpose v2 type.
• Le conteneur d’objets blob doit être créé dans le compte de stockage avant d’installer l’extension de sauvegarde AKS.
• Le conteneur d’objets blob doit de préférence être vide avant l’installation ou au moins ne doit pas contenir de données associées à une sauvegarde, car l’extension crée sa propre structure de dossiers dans le conteneur pour stocker les données de sauvegarde et les métadonnées.
• Si le cluster AKS se trouve dans un réseau privé, le compte de stockage doit être accessible à partir du cluster AKS. Pour ce faire, utilisez un point de terminaison privé pour le compte de stockage ou configurez les règles réseau nécessaires pour autoriser l’accès du cluster AKS au compte de stockage.

Les pods associés à l’extension de sauvegarde AKS sont déployés sur les pools de nœuds du cluster AKS. Pour déployer correctement ces pods et les empêcher d’interférer avec vos ressources d’application, vérifiez les points suivants :

• Le cluster AKS doit avoir le pool de nœuds de l’agent avec le Linux système d’exploitation, y compris Azure Linux et Ubuntu.
• Le pool de nœuds de l’agent doit avoir des références SKU VMSS basées sur une architecture non ARM64.
• Le pool de nœuds de l’agent doit avoir la teinte CriticalAddOnOnly associée. Cette teinte est automatiquement ajoutée au pool de nœuds lorsque le cluster AKS est créé via le portail. Il garantit que seuls les pods d’extension critiques, tels que les pods d’extension de sauvegarde AKS, sont planifiés sur le pool de nœuds. Cela empêche les interférences avec vos charges de travail d’application et garantit que les opérations de sauvegarde sont isolées des autres charges de travail du cluster. Si la teinte n’est pas présente, vous pouvez l’ajouter manuellement avant d’installer l’extension de sauvegarde AKS.

Sauvegarde Azure pour AKS s’appuie sur des pods déployés dans le cluster AKS dans le cadre de l’extension de sauvegarde sous l’espace de noms dataprotection-microsoft. Pour effectuer des opérations de sauvegarde et de restauration, ces pods ont des exigences spécifiques en matière de processeur et de mémoire.

• Mémoire : requêtes - 256Mi, limites - 1280Mi
• PROCESSEUR : requêtes - 500m, limites - 1000m

Lorsque vous installez l’extension de sauvegarde AKS, les ressources liées à la sauvegarde sont déployées dans le cluster sous l’espace dataprotection-microsoft de noms. Les trois déploiements suivants sont créés dans cet espace de noms :

dataprotection-microsoft-controller dataprotection-microsoft-geneva-service dataprotection-microsoft-kubernetes-agent

En outre, étant donné que l’extension de sauvegarde AKS est basée sur les extensions Arc pour la plateforme AKS, deux déploiements supplémentaires sont créés dans l’espace kube-system de noms :

extension-agent extension-operator

Ces déploiements prennent non seulement en charge l’extension de sauvegarde, mais sont également nécessaires pour d’autres extensions, telles que Flux et Azure Machine Learning.

Dans le cadre de l’installation de l’extension de sauvegarde, une identité utilisateur est également créée dans le groupe de ressources Node du cluster. Cette identité est utilisée par l’extension de sauvegarde AKS pour accéder aux ressources Azure requises pour les opérations de sauvegarde. L’identité utilisateur est affectée Storage Blob Data Contributor au rôle sur le compte de stockage pour activer l’accès pour l’extension. Chaque fois que l’extension est désinstallée du cluster AKS, l’identité est également supprimée.

Velero est une solution de sauvegarde tierce pour Kubernetes qui peut entrer en conflit avec l’extension de sauvegarde AKS. Il est recommandé d’utiliser uniquement l’extension de sauvegarde AKS pour les opérations de sauvegarde dans un cluster, mais pas les deux simultanément. L’extension de sauvegarde AKS déploie également des CRD Velero dans le cluster. Dans le cas où Velero autonome est installé dans le cluster AKS, ainsi que l’extension de sauvegarde et les versions utilisées par chaque installation diffèrent à tout moment peut entraîner des défaillances en raison d’incompatibilités de contrat. En outre, des configurations Velero personnalisées créées par l’utilisateur ( par exemple, une capture instantanée basée sur VolumeSnapshotClass pour Velero CSI) peuvent interférer avec la configuration de l’instantané de sauvegarde AKS. Les annotations Velero contenant des velero.io ressources différentes dans le cluster peuvent également avoir un impact sur le comportement de la sauvegarde AKS de manière non prise en charge.

Sauvegarde Azure pour AKS offre une sauvegarde de niveau opérationnel pour les clusters AKS. Ainsi, les instantanés des volumes persistants basés sur disque Azure créés pendant les opérations de sauvegarde planifiées et à la demande sont stockés dans un groupe de ressources au sein de votre abonnement. Sauvegarde Azure offre une restauration instantanée, car les instantanés incrémentiels sont stockés dans votre abonnement. Ce groupe de ressources est appelé « groupe de ressources d’instantanés ». Il est obligatoire de fournir un groupe de ressources d’instantané pendant la configuration de sauvegarde et une fois qu’il n’a pas été affecté, il ne peut pas être modifié.

Lorsque les sauvegardes doivent être restaurées à partir du niveau Coffre, un groupe de ressources intermédiaire et un compte de stockage sont requis. Pendant cette restauration, les données de sauvegarde dans le coffre sont d’abord hydratées à l’emplacement intermédiaire, puis l’extension installée dans le cluster restaure ces données dans le cluster AKS cible. Le groupe de ressources intermédiaire est utilisé pour recréer temporairement les disques sauvegardés. Le compte de stockage intermédiaire est utilisé pour stocker les ressources Kubernetes stockées dans les données de sauvegarde dans le niveau coffre. Les éléments de sauvegarde une fois créés à l’emplacement intermédiaire doivent être nettoyés manuellement.

Sauvegarde Azure pour AKS s’appuie sur des captures instantanées basées sur des pilotes CSI pour ses opérations de sauvegarde et de restauration. En raison de cette dépendance, seuls les volumes persistants basés sur disque Azure attachés via le pilote CSI sont actuellement pris en charge. D’autres options de stockage Azure, telles que le partage de fichiers Azure, l’objet blob Azure, le stockage conteneur Azure, Azure NetApp Files, Azure Managed Lustre et les solutions de stockage tierces, ne sont pas prises en charge pour l’instant. Dans les disques Azure, les références SKU suivantes sont prises en charge :

• SSD de qualité supérieure
• Standard SSD
• Disque dur standard

Toutefois, les disques SSD Premium v2 et Ultra ne sont pas pris en charge. En outre, quand il s’agit de disques Azure avec des paramètres d’accès réseau :

• Le niveau opérationnel prend en charge les disques d’accès public et privé de toute taille.
• Le niveau coffre prend uniquement en charge les disques d’accès public, avec une taille maximale pouvant atteindre 1 To.

Si un cluster AKS contient des volumes persistants de types non pris en charge, ces volumes sont ignorés pendant l’opération de sauvegarde. La sauvegarde globale réussit toujours, mais les volumes non pris en charge ne seront pas inclus dans la sauvegarde.

Sauvegarde Azure pour AKS prend en charge deux types de niveaux de stockage de sauvegarde :

• Niveau opérationnel : ce niveau est utilisé pour la rétention à court terme des sauvegardes. Il stocke les instantanés incrémentiels des volumes persistants au sein de votre abonnement en tant que sauvegarde. Ce niveau est idéal pour les restaurations rapides et les scénarios de récupération opérationnelle.
• Niveau du coffre : ce niveau est utilisé pour la rétention à long terme des sauvegardes. Il stocke les données de sauvegarde stockées dans le niveau opérationnel, les convertissent en objets blob de blocs, puis les stockent dans des comptes de stockage (appelés Coffre) dans un locataire Azure sécurisé géré par Microsoft. Ce niveau est idéal pour la conformité et les exigences réglementaires, car il vous permet de conserver les sauvegardes pendant des périodes prolongées dans un niveau de stockage à faible coût.

Vous pouvez définir le niveau de stockage de sauvegarde lorsque vous créez une stratégie de sauvegarde. La règle par défaut consiste à utiliser le niveau opérationnel pour la sauvegarde. Vous pouvez ajouter d’autres règles pour sauvegarder des données dans le niveau coffre, ainsi que le niveau opérationnel.

La fréquence de sauvegarde est définie dans la stratégie de sauvegarde.

• Dans le niveau opérationnel, les sauvegardes peuvent être effectuées aussi fréquemment que toutes les 4 heures.
• Dans le niveau du coffre, une seule sauvegarde par jour peut être stockée.

Vous pouvez configurer des règles pour déplacer la première sauvegarde réussie du jour, de la semaine, du mois ou de l’année dans le niveau coffre. Ces paramètres peuvent être personnalisés en fonction des objectifs de point de récupération et des exigences de rétention.

Les sauvegardes planifiées sont effectuées dans une fenêtre de 2 heures à partir de l’heure planifiée conformément à la stratégie de sauvegarde. Ainsi, vous pouvez vous attendre à un délai maximal de 2 heures dans l’heure de début de la sauvegarde planifiée à partir de l’heure de sauvegarde planifiée pour la sauvegarde AKS.

Une fois qu’une sauvegarde est créée dans le niveau opérationnel et si elle est conformément aux règles définies dans la stratégie de sauvegarde, elle devient éligible immédiatement au coffre. Après cela, le transfert vers le niveau du coffre est lancé au cours des 4 prochaines heures.

Une stratégie de sauvegarde qui inclut la rétention « première réussite de la semaine/mois/année » sélectionne la première sauvegarde réussie de chaque semaine, mois ou année et la conserve en fonction de la durée de rétention spécifiée. La définition de « first » est définie par le système, par exemple :

• Semaine: Dimanche est considéré comme le début de la semaine
• Mois: Le premier jour du mois
• Année: 1er janvier

Ce comportement n’est pas basé sur la date à laquelle la stratégie a été créée ou activée.

Un cluster AKS peut héberger plusieurs applications simultanément, chacune étendue à différents espaces de noms. Sauvegarde Azure vous permet de sauvegarder un cluster AKS plusieurs fois en fonction des configurations d’application différentes, dans différents coffres de sauvegarde ou à l’aide de différentes stratégies de sauvegarde dans le même coffre de sauvegarde.

Sauvegarde Azure pour AKS prend en charge les sauvegardes géoredondantes, ce qui vous permet de restaurer vos données dans une autre région Azure en cas de panne régionale. Les données de sauvegarde sont redondantes en la répliquant vers une région jumelée Azure.

Pour rendre vos sauvegardes géographiquement redondantes, la première étape consiste à les configurer dans un coffre de sauvegarde qui a Geo-Redundancy activé et la restauration entre régions activées.

Ensuite, configurez l’instance de sauvegarde avec une stratégie de sauvegarde qui inclut des règles de rétention pour le niveau Coffre.

Avec ces paramètres en place, une fois qu’une sauvegarde est déplacée vers le niveau du coffre, elle est automatiquement répliquée dans la région Azure secondaire jumelée.

En cas de panne régionale, vous pouvez restaurer la sauvegarde à partir de la région secondaire à l’aide du portail Azure ou d’Azure CLI.

Une fois qu’une sauvegarde est déplacée dans le niveau coffre, il peut prendre jusqu’à 12 heures pour qu’elle soit répliquée dans la région secondaire. Par conséquent, le RPO maximal d’un point de restauration à mettre à disposition dans les régions secondaires prises en charge par Sauvegarde Azure pour AKS s’il existe une disponibilité des données de sauvegarde dans la région secondaire est d’heures. Cela signifie que, en cas de panne régionale, vous pouvez restaurer vos données de sauvegarde à partir de la région secondaire avec une perte de données maximale de 24 heures.

Sauvegarde Azure pour AKS utilise l’approche de privilège minimum pour découvrir, protéger et restaurer les clusters AKS dans vos abonnements. Pour ce faire, Sauvegarde Azure utilise l’identité managée du coffre de sauvegarde pour accéder à d’autres ressources Azure. Vous pouvez accorder des autorisations à l’identité managée, au système affecté ou à l’utilisateur affecté à l’aide du contrôle d’accès en fonction du rôle Azure (Azure RBAC). L’identité managée est un principal de service d’un type spécial qui ne peut être utilisé qu’avec des ressources Azure. Par défaut, le coffre de sauvegarde n’a pas l’autorisation d’accéder au cluster AKS à sauvegarder, de créer des instantanés périodiques, de supprimer des instantanés après la période de rétention et de restaurer une sauvegarde. En accordant explicitement des attributions de rôles à l’identité managée du coffre de sauvegarde, vous contrôlez la gestion des autorisations sur les ressources des abonnements.

Voici les actions utilisées dans le rôle Contributeur affecté sur le cluster AKS à sauvegarder ou restaurer sur :

1. Microsoft.Compute/snapshots/read
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/delete

Voici les actions utilisées dans le rôle Contributeur aux données Blob de stockage attribuée à l’identité d’extension du cluster AKS sauvegardé ou restauré sur le compte de stockage :

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/containers/write
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
4. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
5. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
6. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

Voici les actions utilisées dans le rôle Lecteur attribué sur le coffre de sauvegarde sur le cluster AKS :

1. */lire

Voici les actions utilisées dans le rôle Lecteur attribué dans le coffre de sauvegarde sur le groupe de ressources d’instantané :

1. Microsoft.Authorization/*/read
2. Microsoft.Resources/subscriptions/resourceGroups/read

Voici les actions utilisées dans le rôle Contributeur d’instantané de disque attribué sur le coffre de sauvegarde sur le groupe de ressources d’instantané au cas où les sauvegardes doivent être stockées dans le niveau coffre :

1. Microsoft.Compute/snapshots/delete
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/read
4. Microsoft.Compute/snapshots/beginGetAccess/action
5. Microsoft.Compute/snapshots/endGetAccess/action
6. Microsoft.Compute/disks/beginGetAccess/action

Voici les actions utilisées dans le rôle Opérateur de données pour disques managés attribués sur le coffre de sauvegarde sur le groupe de ressources d’instantané au cas où les sauvegardes doivent être stockées au niveau du coffre :

1. Microsoft.Compute/disks/download/action
2. Microsoft.Compute/snapshots/download/action

Voici les actions utilisées dans le rôle Lecteur de données blob du stockage attribué sur le coffre de sauvegarde sur le compte de stockage au cas où les sauvegardes doivent être stockées dans le niveau coffre :

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Voici les actions utilisées dans le rôle Contributeur affecté sur le coffre de sauvegarde sur le groupe de ressources intermédiaire au cas où les sauvegardes doivent être restaurées à partir du niveau coffre :

1. Microsoft.Resources/subscriptions/resourceGroups/read
2. Microsoft.Authorization/*/read
3. Microsoft.Compute/snapshots/*
4. Microsoft.Compute/disks/*

Voici les actions utilisées dans le rôle Contributeur de compte de stockage attribué sur le coffre de sauvegarde sur le compte de stockage intermédiaire au cas où les sauvegardes doivent être restaurées à partir du niveau coffre :

1. Microsoft.Authorization/*/read
2. Microsoft.Storage/storageAccounts/*

Voici les actions utilisées dans le rôle Propriétaire des données blob de stockage attribuées sur le coffre de sauvegarde sur le compte de stockage intermédiaire au cas où les sauvegardes doivent être restaurées à partir du niveau coffre :

1. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*

La sauvegarde Azure pour AKS ne prend actuellement pas en charge la prise d’instantanés de tous les PVS en millisecondes exactement. Bien que les opérations d’instantané soient lancées en parallèle, il peut y avoir de légères retards entre les captures instantanées PV individuelles en raison de l’infrastructure et du minutage de l’API. Pour obtenir une cohérence entre plusieurs PVS, Sauvegarde Azure prend en charge les sauvegardes cohérentes avec les applications à l’aide de hooks. Les hooks permettent aux utilisateurs de suspendre les écritures d’applications avant la capture instantanée et de les reprendre par la suite. Cette approche améliore la cohérence et imite la cohérence des incidents, bien qu’elle ne soit pas équivalente à de véritables instantanés simultanés ou à une cohérence coordonnée au niveau de la base de données.

La sélection de « Ignorer » signifie que le processus de restauration ne tente pas de recréer des ressources Kubernetes. Si des ressources correspondantes existent déjà dans le cluster cible, elles seront réutilisées as-is. S’il n’existe pas, Sauvegarde Azure tente de les recréer dynamiquement. En cas de VV, vérifiez que les définitions et autorisations StorageClass compatibles existent dans l’environnement cible.

Cela se produit généralement lorsque le cluster restauré fait référence à des volumes persistants (PVS) qui pointent toujours vers le groupe de ressources source d’origine. AKS sépare les ressources de cluster en deux groupes de ressources : un pour le plan de contrôle et un autre pour l’infrastructure (comme les disques). Si le mappage PVC-to-PV n’a pas été correctement mis à jour lors de la restauration, les charges de travail restaurées peuvent tenter d’attacher des PVS sources, ce qui entraîne des erreurs. Assurez-vous que le processus de restauration remapise correctement les PVC sur des pc nouveaux ou existants dans le groupe de ressources du cluster cible.

Étapes suivantes

• Matrice de prise en charge d’Azure Backup pour AKS