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

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 :

• Volumes
• Volumes persistants
• Classes de stockage
• Revendications de volume persistant

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

Par défaut, Azure réplique automatiquement le disque de système d’exploitation d’une machine virtuelle dans le Stockage Azure pour éviter toute perte de données quand la machine virtuelle est déplacée 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 :

• Disques Ultra
• SSD Premium
• SSD Standard
• HDD Standard

Conseil

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

Un disque Azure étant monté en tant que ReadWriteOnce, il n’est disponible que pour un seul 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 partagé par un compte de stockage Azure sur des pods. 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 les 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 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, qui 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 de données Stockage Azure suivants pour fournir la ressource PersistentVolume :

• Azure Disk
• Azure Files
• Azure Container Storage (préversion).

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

Un administrateur de cluster peut créer statiquement une ressource PersistentVolume, ou le volume est créé dynamiquement par le serveur d’API Kubernetes. Si un pod est planifié et demande un stockage qui n’est pas disponible, Kubernetes peut créer le stockage sur un disque ou fichier Azure sous-jacent et l’attacher au pod. Le provisionnement dynamique utilise une classe de stockage (StorageClass) pour identifier le type de stockage Azure à 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.

Classes de stockage

Pour définir différents niveaux de stockage, tels que Premium et Standard, vous pouvez créer une classe de stockage (StorageClass).

La classe de stockage définit également la stratégie de récupération (reclaimPolicy). Lorsque vous supprimez un volume persistant, la stratégie reclaimPolicy contrôle le comportement de la ressource sous-jacente de stockage Azure. La ressource de stockage sous-jacente peut être supprimée ou conservée en vue de son utilisation pour un pod futur.

Pour les clusters qui utilisent les pilotes Container Storage Interface (CSI), les StorageClasses supplémentaires suivantes sont créées :

Classe de stockage	Description
managed-csi	Utilise un stockage localement redondant (LRS) Azure StandardSSD 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 qu’ils soient extensibles. Il vous suffit de modifier la revendication de volume persistant avec la nouvelle taille.
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.
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 un StorageClass pour un volume persistant, le StorageClass par défaut est utilisé. 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 uniquement 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.

Vous pouvez créer un StorageClass 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é lorsque le pod est supprimé :

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 PersistentVolumeClaim demande le stockage d’une StorageClass, d’un mode d’accès et d’une taille particuliers. Le serveur d’API Kubernetes peut approvisionner dynamiquement la ressource de stockage sous-jacente dans Azure si aucune ressource existante ne satisfait la revendication basée sur le StorageClass défini.

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

PersistentVolume est lié à PersistentVolumeClaim une fois qu’une ressource de stockage disponible a été attribuée au pod demandant un stockage. Les volumes persistants sont mappés 1:1 à des revendications.

L’exemple de manifeste YAML suivant montre une revendication de volume persistant qui utilise la classe de stockage managed-premium et demande un disque ayant 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 volumeMount 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 savoir comment utiliser les pilotes CSI, consultez les articles de procédure suivants :

• Pilotes Container Storage Interface (CSI) pour Azure Disk, Azure Files et le stockage Azure Blob sur Azure Kubernetes Service
• Utiliser le pilote CSI Azure Disk dans Azure Kubernetes Service
• Utiliser le pilote CSI Azure Files dans Azure Kubernetes Service
• Utiliser le pilote CSI de stockage Blob Azure dans Azure Kubernetes Service
• Configurer Azure NetApp Files avec Azure Kubernetes Service

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

• Clusters et charges de travail Kubernetes/AKS
• Identité Kubernetes/AKS
• Sécurité Kubernetes/AKS
• Réseaux virtuels Kubernetes/AKS
• Mise à l’échelle Kubernetes/AKS