Meilleures pratiques relatives au stockage et aux sauvegardes dans Azure Kubernetes Service (AKS)

Lorsque vous créez et gérez des clusters dans Azure Kubernetes Service (AKS), il est souvent nécessaire de stocker vos applications. Assurez-vous que vous comprenez les besoins en performances des pods et les méthodes d’accès afin de pouvoir sélectionner le meilleur stockage pour votre application. La taille du nœud AKS peut avoir une incidence sur vos choix de stockage. Planifiez des méthodes pour sauvegarder et tester le processus de restauration pour le stockage attaché.

Cet article traite des meilleures pratiques de stockage pour les opérateurs de clusters. Dans cet article, vous apprenez :

  • Les types de stockage disponibles.
  • Comment définir correctement la taille des nœuds AKS pour des performances de stockage optimales.
  • Comment planifier et exploiter la mise en cache distribuée pour les lectures d’objets blob Azure répétées.
  • Les différences entre l’approvisionnement dynamique et statique des volumes.
  • Les méthodes de sauvegarde et de sécurisation de vos volumes de données.

Le choix du type de stockage adapté.

Conseils sur les bonnes pratiques

Identifiez les besoins de votre application pour choisir le stockage approprié. Utilisez un stockage sur disque SSD haute performance pour les charges de travail de production. Optez pour un stockage basé sur un réseau si vous avez besoin de multiples connexions simultanées.

Les applications nécessitent souvent différents types et vitesses de stockage. Déterminez le type de stockage le plus approprié en posant les questions suivantes.

  • Vos applications requièrent-elles un stockage qui se connecte à des pods individuels ?
  • Vos applications ont-elles besoin d’un stockage partagé sur plusieurs pods ?
  • Le stockage est-il destiné à un accès en lecture seule aux données ?
  • Le stockage sera-t-il utilisé pour écrire de grandes quantités de données structurées ?

Le tableau suivant présente les types de stockage disponibles et leurs fonctionnalités :

Cas d’utilisation Plug-in de volume Lecture/écriture unique Nombreuses lectures seules Nombreuses lectures/écritures Prise en charge de conteneur Windows Server
Configuration partagée Azure Files Oui Oui Oui Oui
Données d’application structurées Disques Azure Oui Non Non Oui
Données non structurées, opérations sur le système de fichiers BlobFuse Oui Oui Oui Non

AKS fournit deux principaux types de stockage sécurisé pour les volumes reposant sur des disques Azure ou Azure Files. Les deux utilisent le chiffrement du service de stockage (SSE) Azure par défaut, qui chiffre les données au repos. Les disques ne peuvent pas être chiffrés à l’aide d’Azure Disk Encryption au niveau des nœuds AKS. Avec les partages de fichiers Azure, il n’y a pas de limites du nombre de partages pouvant être montés sur un nœud.

Azure Files et les disques Azure sont disponibles pour les niveaux de performance Standard et Premium :

  • Disques Premium
    • Assortis de disques SSD hautes performances.
    • Recommandé pour toutes les charges de travail de production.
  • Disques Standard
    • Assortis de disques à rotation normale (HDD).
    • Idéal pour les données d’archivage ou rarement consultées.

Alors que le niveau de stockage par défaut du pilote CSI Azure Disk est SSD Premium, votre StorageClass personnalisé peut utiliser SSD Premium, SSD Standard ou HDD Standard.

Identifiez les besoins de performances de votre application et les modèles d’accès pour choisir le niveau de stockage approprié. Pour plus d’informations sur les tailles et les niveaux de performance des disques managés, consultez Vue d’ensemble des disques managés Azure.

Créer et utiliser des classes de stockage pour définir les besoins des applications

Définissez le type de stockage souhaité à l’aide des classes de stockage Kubernetes. La classe de stockage est ensuite référencée dans la spécification du pod ou du déploiement. Les définitions de classe de stockage fonctionnent ensemble pour créer le stockage approprié et le connecter aux pods.

Pour plus d’informations, consultez Classes de stockage dans AKS.

Dimensionner les nœuds en fonction des besoins de stockage

Conseils sur les bonnes pratiques

Chaque taille de nœud prend en charge un nombre maximal de disques. Différentes tailles de nœud fournissent également des quantités différentes de stockage local et de bande passante de réseau. Planifiez les exigences de votre application pour déployer la taille appropriée de nœuds.

Les nœuds AKS s’exécutent sous différents types et tailles de machines virtuelles Azure. Chaque taille de machine virtuelle fournit :

  • Une quantité différente de ressources fondamentales, comme le processeur et la mémoire.
  • Le nombre maximum de disques pouvant être connectés.

Selon les tailles de machine virtuelle, les performances de stockage varient également en matière d’IOPS (opérations d’entrée/sortie par seconde) maximal des disques locaux et attachés.

Si vos applications nécessitent des disques Azure comme solution de stockage, choisissez une taille de machine virtuelle de nœud appropriée. Les capacités de stockage et les quantités de processeur et de mémoire jouent un rôle majeur lorsque vous choisissez une taille de machine virtuelle.

Par exemple, si les tailles de machine virtuelle Standard_B2ms et Standard_DS2_v2 incluent une quantité similaire de ressources processeur et mémoire, leurs performances de stockage potentielles sont différentes :

Taille et type de nœud Processeurs virtuels Mémoire (Gio) Disques de données max. IOPS de disque non mis en cache max. Débit non mis en cache max. (Mbits/s)
Standard_B2ms 2 8 4 1 920 22,5
Standard_DS2_v2 2 7 8 6 400 96

Dans cet exemple Standard_DS2_v2 offre deux fois plus de disques attachés, et trois à quatre fois le volume d’E/S par seconde et de débit de disque. Si vous comparez uniquement les principales ressources de calcul et que vous comparez les coûts, vous serez tenté de choisir la taille de machine virtuelle Standard_B2ms, mais les performances de stockage risquent d’être médiocres et de présenter des limitations.

Consultez votre équipe de développement d’application pour comprendre ses besoins de capacité de stockage et de performance. Choisissez la taille de machine virtuelle appropriée pour les nœuds AKS permettant de satisfaire ou de dépasser ses besoins de performance. Évaluez régulièrement les applications afin d’ajuster la taille de machine virtuelle en fonction des besoins.

Remarque

Par défaut, la taille de disque et les performances des disques managés sont attribuées en fonction de la référence SKU de la machine virtuelle et du nombre de processeurs virtuels sélectionnés. Le dimensionnement du disque de système d’exploitation par défaut est utilisé uniquement sur les nouveaux clusters ou les pools de nœuds quand les disques de système d’exploitation éphémères ne sont pas pris en charge et qu’aucune taille de disque de système d’exploitation par défaut n’est spécifiée. Pour plus d’informations, consultez Dimensionnement du disque du système d’exploitation par défaut.

Pour plus d’informations sur les tailles de machine virtuelle disponibles, consultez Tailles des machines virtuelles Linux dans Azure.

Prendre en compte les disques de données NVMe éphémères pour des performances maximales

Conseils sur les bonnes pratiques

Prenez en compte les disques de données NVMe éphémères lorsque vous avez besoin du débit de stockage et des E/S par seconde les plus élevés, et que votre charge de travail peut tolérer la nature temporaire du stockage de nœud local. Les disques de données NVMe éphémères fournissent un stockage à faible latence et attaché à l’hôte qui offre les E/S par seconde et le débit les plus élevés disponibles dans Azure. Les disques NVMe sont disponibles sur les machines virtuelles série L, E et GPU, avec une prise en charge croissante des familles de machines virtuelles Azure v6 et v7 plus récentes, telles que la série D, la série F, la série H.

Le stockage NVMe sauvegardé améliore les charges de travail qui demandent une mise en cache à grande vitesse, un stockage temporaire ou un traitement temporaire des données. Il élimine la dépendance vis-à-vis des disques distants hautes performances, qui nécessitent généralement les configurations de machines virtuelles les plus volumineuses et les plus coûteuses pour obtenir des performances optimales.

Les scénarios courants qui tirent parti des disques de données NVMe éphémères sont les suivants :

  • Apprentissage IA ou pipelines d’inférence qui organisent de grands ensembles de données ou des points de sauvegarde entre les itérations
  • Bases de données hautes performances ou moteurs de diffusion en continu qui gèrent des réplicas ou des journaux d’activité entre les pods
  • Travaux d'analytique par lots nécessitant espace de travail temporaire ou stockage aléatoire.

Étant donné que les données NVMe sont liées à l’instance de nœud, planifiez les budgets de perturbation des pods et assurez-vous que votre application peut rapidement se reconstruire à partir d'un stockage durable ou grâce à la réplication. Les données placées sur ces disques sont perdues chaque fois qu’un nœud est désalloué, ré-imagé ou échoue.

Pour obtenir des recommandations supplémentaires sur les disques de données NVMe éphémères, consultez les meilleures pratiques pour les disques de données NVMe éphémères dans Azure Kubernetes Service (AKS). Pour exposer la capacité NVMe aux pods, utilisez Stockage de conteneurs Azure, qui peut orchestrer et créer des volumes éphémères ou persistants, soutenus par des disques NVMe locaux. Pour obtenir des conseils sur l’implémentation, consultez le stockage conteneur Azure avec AKS.

Important

Utilisez des disques de données NVMe uniquement pour les charges de travail qui peuvent tolérer la perte de données et récupérer rapidement. Conservez les données critiques pour l’entreprise sur un stockage durable, tel qu’Azure Disk ou Azure Files.

Utilisez l’accélérateur distribué pour le stockage dans le cloud (aperçu)

Conseils sur les bonnes pratiques

Envisagez l’accélérateur distribué pour le stockage cloud (DACS) lorsque les applications lisent plusieurs fois des fichiers de modèle ou des jeux de données à partir de Stockage Blob Azure. Planifiez la capacité du cache, le préchauffage et la récupération autour des modèles d’accès de votre charge de travail.

DACS utilise des disques NVMe locaux sur des nœuds de cache Linux pour mettre en cache les données du stockage Blob Azure. Il peut réduire le temps de chargement du modèle pour l’inférence IA et accélérer les lectures de jeux de données répétées pour l’entraînement. Vous activez et gérez DACS via Azure Container Storage. DACS ne provisionne pas de volumes persistants ni de classes de stockage.

Lorsque vous planifiez et utilisez DACS :

  • Dédiez le stockage du cache. Utilisez des nœuds de cache Linux avec des disques NVMe locaux dédiés à DACS. Les prérequis du cache peuvent formater ces disques. Conservez les étiquettes de nœud de cache dans la configuration du pool de nœuds afin qu’elles survivent au remplacement du nœud.
  • Taille du jeu de travail actif. Incluez une marge pour les versions de modèle qui se chevauchent et les modifications du jeu de données. Tenez compte des lecteurs simultanés, du CPU et de la mémoire du nœud, ainsi que de la bande passante réseau, pas seulement de la capacité NVMe.
  • Planifiez les lectures à froid. Envisagez de précharger les données du modèle avant les déploiements d’inférence ou le scale-out. Vérifiez les hits du cache avant d’augmenter la concurrence. La prérécupération n’immobilise pas les données et l’éviction, le remplacement de nœud ou la maintenance peuvent nécessiter un autre préchauffement. Prévoyez un trafic Blob supplémentaire lorsque les données mises en cache ne sont pas disponibles.
  • Mesurer le comportement de l’application et du cache. Comparez les lectures froides et chaudes sous concurrence attendue. Surveillez les accès au cache client, les requêtes de serveur de cache, la latence, la capacité et le trafic Blob. Les lectures réussies ou plus rapides ne prouvent pas à elles seules l'utilisation du cache, car les clients peuvent se rabattre sur Stockage Blob Azure.
  • Conservez durablement les données de référence. Stockez les fichiers de modèle et les jeux de données dans Stockage Blob Azure, de préférence sur des chemins immuables et avec version. Les données mises en cache sont éphémères et ne sont pas répliquées pour la durabilité. N’utilisez pas DACS comme stockage persistant pour les sorties d’entraînement ou les points de contrôle.

Important

DACS est en préversion. Les fonctionnalités en préversion sont fournies sans contrat de niveau de service et ne sont pas recommandées pour les charges de travail de production. Pour plus d’informations, consultez Conditions d'utilisation supplémentaires pour les versions préliminaires de Microsoft Azure.

Utiliser DACS au sein d’un cluster de confiance ; le cache n’isole pas des locataires qui ne se font pas mutuellement confiance. Accordez uniquement aux charges de travail les autorisations d’accès blob dont ils ont besoin.

Pour obtenir des conseils sur le déploiement et les opérations, consultez Gérer l’accélérateur distribué pour le stockage cloud et Surveiller l’accélérateur distribué pour le stockage cloud.

Approvisionner les volumes de manière dynamique

Conseils sur les bonnes pratiques

Pour réduire la charge de gestion et permettre la mise à l’échelle, évitez de créer et d’affecter des volumes persistants de manière statique. Optez pour un approvisionnement dynamique. Dans vos classes de stockage, définissez la stratégie de demande de récupération appropriée pour réduire les coûts de stockage inutiles une fois les pods supprimés.

Pour lier un stockage aux pods, utilisez des volumes persistants. Les volumes persistants peuvent être créés manuellement ou dynamiquement. La création manuelle de volumes persistants ajoute une surcharge de gestion et limite votre capacité d’ajustement. Utilisez plutôt un approvisionnement de volume persistant dynamique pour simplifier la gestion du stockage et permettre à vos applications de se développer et de s’ajuster en fonction des besoins.

Diagramme montrant des revendications de volumes persistants dans un cluster AKS (Azure Kubernetes Service).

Une revendication de volume persistant vous permet de créer des espaces de stockage de manière dynamique en fonction des besoins. Les disques Azure sous-jacents sont créés en fonction des requêtes des pods. Dans la définition de pod, demandez un volume à créer et à rattacher à un chemin d’accès de montage spécifique.

Pour en savoir plus sur les concepts relatifs à la création et à l’utilisation dynamique des volumes, consultez Revendications de volume persistant.

Pour voir ces volumes en action, découvrez comment créer et utiliser un volume persistant de manière dynamique avec des disques Azure ou Azure Files.

Dans le cadre de vos définitions de classe de stockage, définissez la propriété reclaimPolicy de manière appropriée. Cette stratégie de récupération contrôle le comportement de la ressource de stockage Azure sous-jacente quand le pod est supprimé. La ressource de stockage sous-jacente peut être supprimée ou conservée en vue de son utilisation par un pod futur. Définissez la valeur reclaimPolicy sur Conserver ou Supprimer.

Identifiez les besoins de votre application et implémentez des contrôles réguliers pour le stockage conservé afin de réduire la quantité de stockage non utilisée et facturée.

Pour plus d’informations sur les options de classe de stockage, consultez les stratégies de récupération de stockage.

Sécuriser et sauvegarder vos données

Conseils sur les bonnes pratiques

Sauvegardez vos données à l’aide d’un outil adapté à votre type de stockage, tel que Velero ou Sauvegarde Azure. Vérifiez l’intégrité et la sécurité de ces sauvegardes.

Lorsque vos applications stockent et exploitent des données conservées sur des disques ou dans des fichiers, vous devez effectuer des sauvegardes ou des captures instantanées régulières de ces données. Les disques Azure peuvent utiliser des technologies de capture instantanée intégrées. Vos applications pour pourraient avoir à vider les écritures sur le disque avant d’effectuer l’opération de capture instantanée. Velero peut sauvegarder des volumes persistants avec des ressources de cluster et des configurations supplémentaires. Si vous ne pouvez pas supprimer l’état de vos applications, sauvegardez les données à partir de volumes persistants et testez régulièrement les opérations de restauration pour vérifier l’intégrité des données et les processus nécessaires.

Identifiez les limitations des différentes approches en matière de sauvegarde de données et déterminez si vous devez suspendre vos données avant la capture instantanée. Les sauvegardes de données ne vous permettent pas nécessairement de restaurer votre environnement d’application de déploiement de cluster. Pour plus d’informations sur ces scénarios, consultez Best practices for business continuity and disaster recovery in AKS (Meilleures pratiques pour la continuité d’activité et la récupération d’urgence dans AKS).

Si vous utilisez DACS, protégez les fichiers de modèle et les jeux de données faisant autorité dans Stockage Blob Azure plutôt que de sauvegarder le contenu du cache éphémère. Conservez la configuration du cache dans le contrôle de version et testez la recréation et le réchauffement du cache après le remplacement du nœud ou la récupération du cluster. DACS n’est pas une solution de sauvegarde.

Étapes suivantes

Cet article se concentre sur les meilleures pratiques de stockage dans AKS. Pour plus d’informations sur les principes fondamentaux du stockage dans Kubernetes, consultez Options de stockage pour les applications dans AKS (Azure Kubernetes Service).

Pour plus d’informations sur la mise en cache distribuée pour les données Blob Azure, consultez les articles suivants :