Partager via

Options de stockage pour les applications dans AKS (Azure Kubernetes Service)

  • Article

Les applications qui s’exécutent dans Azure Kubernetes Service (AKS) peuvent avoir besoin de stocker et de récupérer des données. Bien que certaines charges de travail d’applications puissent utiliser un stockage local et rapide sur des nœuds superflus et vides, d’autres nécessitent un stockage qui persiste sur des volumes de données plus réguliers au sein de la plateforme Azure.

Plusieurs pods doivent peut-être :

  • Partager les mêmes volumes de données.
  • Ré-attacher des volumes de données si le pod est de nouveau planifié sur un nœud différent.

Vous pouvez également avoir besoin de collecter et de stocker des données sensibles ou des informations de configuration d’application dans des pods.

Cet article présente les concepts fondamentaux qui fournissent le stockage à vos applications dans AKS :

Diagramme montrant les options de stockage pour les applications dans un cluster AKS (Azure Kubernetes Service).

Dimensionnement du disque de système d’exploitation par défaut

Lorsque vous créez un cluster ou que vous ajoutez un nouveau pool de nœuds à un cluster existant, le nombre de processeurs virtuels détermine par défaut la taille du disque du système d'exploitation. Le nombre de processeurs virtuels est basé sur la référence SKU de la machine virtuelle. Le tableau suivant liste les tailles de disque de système d’exploitation par défaut pour chaque référence SKU de machine virtuelle :

Cœurs de référence SKU de machine virtuelle (processeurs virtuels) Niveau du disque de système d’exploitation par défaut IOPS provisionnées Débit approvisionné (Mbits/s)
1 à 7 P10/128G 500 100
8 à 15 P15/256G 1100 125
16 à 63 P20/512G 2300 150
64+ P30/1024G 5 000 200

Important

Le dimensionnement du disque de système d’exploitation par défaut est utilisé seulement sur les nouveaux clusters ou 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. La taille du disque de système d’exploitation par défaut peut avoir un impact sur les performances ou le coût de votre cluster. Vous ne pouvez pas changer la taille du disque de système d’exploitation après la création du cluster ou du pool de nœuds. Ce dimensionnement de disque par défaut affecte les clusters ou les pools de nœuds créés en juillet 2022 ou ultérieurement.

Disque de système d’exploitation éphémère

Par défaut, Azure réplique automatiquement le disque du système d’exploitation d’une machine virtuelle dans le Stockage Azure pour éviter toute perte de données lors du déplacement de la machine virtuelle vers un autre hôte. Toutefois, comme les conteneurs ne sont pas conçus pour avoir un état local persistant, ce comportement offre une valeur limitée tout en offrant certains inconvénients. Ces inconvénients incluent, sans toutefois s’y limiter, un approvisionnement de nœuds plus lent et une latence en lecture/écriture plus élevée.

En revanche, les disques de système d’exploitation éphémères sont stockés uniquement sur l’ordinateur hôte, comme un disque temporaire. Avec cette configuration, vous obtenez une latence de lecture/écriture plus faible, ainsi que des mises à l’échelle des nœuds et des mises à niveau de cluster plus rapides.

Notes

Lorsque vous ne demandez pas explicitement de disques managés Azure pour le système d’exploitation, AKS utilise par défaut un système d’exploitation éphémère, si possible, pour une configuration de pool de nœuds donnée.

Les exigences en matière de taille et les recommandations pour les disques de système d’exploitation éphémères sont disponibles dans la documentation sur les machines virtuelles Azure. Voici quelques considérations générales concernant le dimensionnement :

  • Si vous avez choisi d’utiliser la taille de machine virtuelle par défaut AKS de la référence SKU Standard_DS2_v2 avec la taille de disque du système d’exploitation par défaut de 100 Gio, la taille de machine virtuelle par défaut prend en charge le système d’exploitation éphémère, mais ne dispose que d’une taille de cache de 86 Gio. Cette configuration utilise par défaut des disques managés si vous ne le spécifiez pas explicitement. Si vous demandez un système d’exploitation éphémère, vous recevez une erreur de validation.

  • Si vous demandez la même référence SKU Standard_DS2_v2 avec un disque de système d’exploitation de 60 Gio, cette configuration utilise par défaut un système d’exploitation éphémère. La taille demandée de 60 Gio est inférieure à la taille maximale du cache de 86 Gio.

  • Si vous sélectionnez la référence SKU Standard_D8s_v3 avec un disque de système d’exploitation de 100 Go, cette taille de machine virtuelle prend en charge le système d’exploitation éphémère et dispose de 200 Gio d’espace de cache. Si vous ne spécifiez pas le type de disque de système d’exploitation, le pool de nœuds reçoit le système d’exploitation éphémère par défaut.

La dernière génération de la série de machines virtuelles n’a pas de cache dédié, mais uniquement un stockage temporaire. Par exemple, si vous avez sélectionné la taille de machine virtuelle Standard_E2bds_v5 avec la taille de disque de système d’exploitation par défaut de 100 Gio, elle prend en charge les disques de système d’exploitation éphémères, mais ne dispose que de 75 Go de stockage temporaire. Cette configuration utilise par défaut des disques managés du système d’exploitation si vous ne le spécifiez pas explicitement. Si vous demandez un disque de système d’exploitation éphémère, vous recevez une erreur de validation.

  • Si vous demandez la même taille de machine virtuelle Standard_E2bds_v5 avec un disque de système d’exploitation de 60 Gio, cette configuration utilise par défaut des disques de système d’exploitation éphémères. La taille demandée de 60 Gio est inférieure au stockage temporaire maximal de 75 Gio.

  • Si vous sélectionnez la référence SKU Standard_E4bds_v5 avec un disque de système d’exploitation de 100 Gio, cette taille de machine virtuelle prend en charge le système d’exploitation éphémère et dispose de 150 Gio de stockage temporaire. Si vous ne spécifiez pas le type de disque de système d’exploitation, Azure approvisionne par défaut un disque de système d’exploitation éphémère au pool de nœuds.

Clés gérées par le client

Vous pouvez gérer le chiffrement de votre disque de système d’exploitation éphémère avec vos propres clés sur un cluster AKS. Pour plus d’informations, consultez Utiliser une clé gérée par le client avec un disque Azure sur AKS.

Volumes

Kubernetes traite généralement des pods individuels comme des ressources éphémères et jetables. Les applications ont des approches différentes à leur disposition pour l’utilisation et la persistance des données. Un volume représente un moyen de stocker, de récupérer et de conserver les données entre les pods et tout au long du cycle de vie des applications.

Les volumes traditionnels sont créés en tant que ressources Kubernetes soutenues par Stockage Azure. Vous pouvez créer manuellement des volumes de données à affecter directement aux pods ou demander à Kubernetes de les créer automatiquement. Les volumes de données peuvent utiliser : Disque Azure, Azure Files, Azure NetApp Files ou Objets blob Azure.

Notes

En fonction du SKU VM que vous utilisez, le pilote Azure Disk CSI peut avoir une limite de volume par nœud. Pour certaines machines virtuelles très performantes (par exemple, 16 cœurs), la limite est de 64 volumes par nœud. Pour identifier la limite par référence SKU de machine virtuelle, passez en revue la colonne Nombre maximal de disques de données pour chaque référence SKU de machine virtuelle proposée. Pour obtenir la liste des références SKU de machine virtuelle proposées et leurs limites de capacité détaillées correspondantes, consultez Tailles de machine virtuelle à usage général.

Pour vous aider à déterminer le meilleur ajustement pour votre charge de travail entre Azure Files et Azure NetApp Files, passez en revue les informations fournies dans l’article Comparaison entre Azure Files et Azure NetApp Files.

Azure Disk

Utilisez Disque Azure pour créer une ressource DataDisk Kubernetes. Les types de disques comprennent :

  • SSD Premium (recommandé pour la plupart des charges de travail)
  • Disques Ultra
  • SSD Standard
  • HDD Standard

Conseil

Pour la plupart des charges de travail de production et de développement, utilisez des SSD Premium.

Un disque Azure étant monté en tant que ReadWriteOnce, il n’est disponible que pour un unique nœud. Pour les volumes de stockage accessibles par des pods sur plusieurs nœuds simultanément, utilisez Azure Files.

Azure Files

Utilisez Azure Files pour monter un partage SMB (Server Message Block) version 3.1.1 ou NFS (Network File System) version 4.1. Azure Files vous permet de partager des données entre plusieurs nœuds et pods, et peut utiliser :

  • Le stockage Premium Azure , soutenu par un disque SSD hautes performances
  • Le stockage Standard Azure, soutenu par des HDD normaux

Azure NetApp Files

  • Stockage Ultra
  • Stockage Premium
  • Stockage standard

Stockage Blob Azure

Utilisez Stockage Blob Azure pour créer un conteneur de stockage d’objets blob et le monter à l’aide du protocole NFS v3.0 ou BlobFuse.

  • Objets blob de blocs

Types de volume

Les volumes Kubernetes représentent plus qu’un simple disque traditionnel pour le stockage et la récupération d’informations. Les volumes Kubernetes peuvent également servir à injecter des données dans un pod en vue de leur utilisation par ses conteneurs.

Voici certains types de volumes courants dans Kubernetes :

emptyDir

Couramment utilisé comme espace temporaire pour un pod. Tous les conteneurs au sein d’un pod peuvent accéder aux données sur le volume. Les données écrites dans ce type de volume persistent uniquement pendant la durée de vie du pod. Une fois le pod supprimé, le volume est supprimé. Ce volume utilise généralement le stockage sur disque du nœud local sous-jacent, bien qu’il puisse aussi se trouver uniquement dans la mémoire du nœud.

secret

Vous pouvez utiliser les volumes secrets pour injecter des données sensibles dans des pods, telles que des mots de passe.

  1. Créez un secret en vous servant de l’API Kubernetes.
  2. Définissez votre pod ou votre déploiement et demandez un secret spécifique.
    • Les secrets sont fournis uniquement aux nœuds avec un pod planifié qui en a besoin.
    • Le secret est stocké dans tmpfs. Il n’est pas écrit sur le disque.
  3. Lorsque vous supprimez le dernier pod sur un nœud nécessitant un secret, ce dernier est supprimé du tmpfs du nœud.
    • Les secrets sont stockés dans un espace de noms donné et ne sont accessibles que par des pods se trouvant dans cet espace de noms.

configMap

Vous pouvez utiliser configMap pour injecter des propriétés de paires clé-valeur dans des pods, telles que des informations de configuration d’application. Définissez des informations de configuration d’application en tant que ressource Kubernetes, facilement mises à jour et appliquées à de nouvelles instances de pods lorsqu’elles sont déployés.

Tout comme l’utilisation d’un secret :

  1. Créez un élément Configmap à l’aide de l’API Kubernetes.
  2. Demandez l’élément configmap quand vous définissez un pod ou un déploiement.
    • Les ressources ConfigMaps sont stockées dans un espace de noms donné et ne sont accessibles que par des pods se trouvant dans cet espace de noms.

Volumes persistants

Les volumes sont définis et créés dans le cadre du cycle de vie d’un pod et sont conservés jusqu’à ce que le pod soit supprimé. Le stockage d’un pod est censé être conservé si le pod est replanifié sur un autre hôte pendant un événement de maintenance, en particulier dans les ressources StatefulSet. Un volume persistant est une ressource de stockage créée et gérée par l’API Kubernetes, et qui peut exister au-delà de la durée de vie d’un pod donné.

Vous pouvez utiliser les services suivants du stockage Azure pour fournir le volume persistant :

Comme indiqué dans la section Volumes, le choix de disques Azure ou d’Azure Files est souvent déterminé par le niveau de performance ou la nécessité d’un accès simultané aux données.

Diagramme montrant les volumes persistants dans un cluster AKS (Azure Kubernetes Service).

Un administrateur de cluster peut créer statiquement un volume persistant, ou un volume peut être créé dynamiquement par le serveur d’API Kubernetes. Si un pod est planifié et demande un stockage actuellement indisponible, Kubernetes peut créer le stockage sur un disque ou un fichier de stockage Azure sous-jacent et l’attacher au pod. Le provisionnement dynamique utilise une classe de stockage pour identifier le type de ressource à créer.

Important

Les volumes persistants ne peuvent pas être partagés par les pods Windows et Linux en raison de différences dans la prise en charge du système de fichiers entre les deux systèmes d’exploitation.

Si vous souhaitez une solution entièrement managée pour l’accès au niveau du bloc aux données, envisagez d’utiliser Stockage de conteneurs Azure au lieu de pilotes CSI. Stockage de conteneurs Azure s’intègre à Kubernetes, ce qui permet l’approvisionnement dynamique et automatique de volumes persistants. Stockage de conteneurs Azure prend en charge les disques Azure, les disques éphémères et Azure Elastic SAN (préversion) en tant que stockage de secours, offrant ainsi flexibilité et scalabilité pour les applications avec état s'exécutant sur des clusters Kubernetes.

Classes de stockage

Pour spécifier les différents niveaux de stockage, tels que Premium ou Standard, vous pouvez créer une classe de stockage.

Une classe de stockage définit également une stratégie de récupération. Le stockage de la revendication permet de contrôler le comportement de la ressource sous-jacente du Stockage Azure à la suppression du volume persistant. La ressource sous-jacente peut être supprimée ou conservée en vue de son utilisation pour un pod futur.

Pour les clusters utilisant Stockage de conteneurs Azure, vous verrez une classe de stockage supplémentaire appelée acstor-<storage-pool-name>. Une classe de stockage interne est également créée.

Pour les clusters utilisant les pilotes Container Storage Interface (CSI), les classes de stockage supplémentaires suivantes sont créées :

Classe de stockage Description
managed-csi Utilise un stockage localement redondant (LRS) Azure Standard SSD pour créer un disque managé. La stratégie de récupération veille à ce que le disque Azure sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé. La classe de stockage configure également les volumes persistants pour les rendre extensibles. Vous pouvez modifier la revendication du volume persistant pour spécifier la nouvelle taille. À compter de Kubernetes version 1.29, dans les clusters Azure Kubernetes Service (AKS) déployés sur plusieurs zones de disponibilité, cette classe de stockage utilise le stockage redondant interzone (ZRS) Azure Standard SSD pour créer des disques managés.
managed-csi-premium Utilise un stockage localement redondant (LRS) Premium Azure pour créer un disque managé. La stratégie de récupération veille à nouveau à ce que le disque Azure sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé. De même, cette classe de stockage permet l’extension des volumes persistants. À compter de Kubernetes version 1.29, dans les clusters Azure Kubernetes Service (AKS) déployés sur plusieurs zones de disponibilité, cette classe de stockage utilise le stockage redondant interzone (ZRS) Azure Premium pour créer des disques managés.
azurefile-csi Utilise le stockage Standard Azure pour créer un partage de fichiers Azure. La stratégie de récupération veille à ce que le partage de fichiers Azure sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé.
azurefile-csi-premium Utilise le stockage Premium Azure pour créer un partage de fichiers Azure. La stratégie de récupération veille à ce que le partage de fichiers Azure sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé.
azureblob-nfs-premium Utilise le stockage Azure Premium pour créer un conteneur de stockage Blob Azure et se connecter à l’aide du protocole NFS v3. La stratégie de récupération veille à ce que le conteneur Stockage Blob Azure sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé.
azureblob-fuse-premium Utilise le stockage Azure Premium pour créer un conteneur de stockage Blob Azure et se connecter à l’aide de BlobFuse. La stratégie de récupération veille à ce que le conteneur Stockage Blob Azure sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé.

À moins que vous ne spécifiiez une classe de stockage pour un volume persistant, la classe de stockage par défaut est utilisée. Lorsque vous demandez des volumes persistants, veillez à ce que le stockage approprié dont vous avez besoin soit utilisé.

Important

À compter de Kubernetes version 1.21, AKS utilise les pilotes CSI par défaut et la migration CSI est activée. Même si les volumes persistants existants dans l’arborescence continuent de fonctionner, à compter de la version 1.26, AKS ne prendra plus en charge les volumes créés à l’aide du pilote dans l’arborescence et du stockage provisionné pour les fichiers et le disque.

La classe default sera la même que managed-csi.

À compter de Kubernetes version 1.29, quand vous déployez des clusters Azure Kubernetes Service (AKS) sur plusieurs zones de disponibilité, AKS utilise désormais le stockage redondant interzone (ZRS) pour créer des disques managés dans des classes de stockage intégrées. ZRS garantit la réplication synchrone de vos disques managés Azure sur plusieurs zones de disponibilité Azure dans la région de votre choix. Cette stratégie de redondance renforce la résilience de vos applications et protège vos données contre les défaillances du centre de données.

Toutefois, il est important de noter que le stockage redondant interzone (ZRS) est plus coûteux que le stockage localement redondant (LRS). Si l’optimisation des coûts est une priorité, vous pouvez créer une classe de stockage avec le paramètre skuname défini sur LRS. Vous pouvez ensuite utiliser la nouvelle classe de stockage dans votre revendication de volume persistant (PVC).

Vous pouvez créer une classe de stockage pour des besoins supplémentaires à l’aide de kubectl. L’exemple suivant utilise les disques managés Premium et spécifie que le disque Azure sous-jacent doit être conservé à la suppression du pod :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Notes

AKS rapproche les classes de stockage par défaut et remplace toutes les modifications que vous apportez à ces classes de stockage.

Pour plus d’informations sur les classes de stockage, consultez StorageClass dans Kubernetes.

Revendications de volume persistant

Une revendication de volume persistant (PVC) nécessite une classe de stockage, une taille et un mode d’accès particuliers. Le serveur d’API Kubernetes peut approvisionner dynamiquement la ressource sous-jacente du Stockage Azure si aucune ressource existante ne satisfait la revendication basée sur la classe de stockage définie.

La définition du pod inclut le montage du volume une fois que ce dernier a été connecté au pod.

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

Le volume persistant est lié à une revendication de volume persistant une fois qu’une ressource de stockage disponible a été attribuée au pod demandant un stockage. Les volumes persistants sont mappés aux revendications dans un mappage 1:1.

L’exemple de manifeste YAML suivant montre une revendication de volume persistant utilisant la classe de stockage managée-premium et demande un disque Azure avec une taille de 5Gi :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Lorsque vous créez une définition de pod, vous spécifiez également :

  • La revendication de volume persistant pour demander le stockage souhaité.
  • L’élément montage du volume permettant à vos applications de lire et d’écrire des données.

L’exemple de manifeste YAML suivant illustre l’utilisation de la revendication de volume persistant précédente pour monter un volume sur /mnt/azure :

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Pour monter un volume dans un conteneur Windows, spécifiez la lettre de lecteur et le chemin d’accès. Par exemple :

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

Étapes suivantes

Pour connaître les meilleures pratiques associées, consultez Meilleures pratiques pour le stockage et les sauvegardes dans AKS et Considérations sur le stockage AKS.

Pour plus d’informations sur Stockage de conteneurs Azure, consultez les articles suivants :

Pour plus d’informations sur l’utilisation des pilotes CSI, consultez les articles suivants :

Pour plus d’informations sur les concepts fondamentaux de Kubernetes et d’AKS, consultez les articles suivants :