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.

Enfin, vous pouvez être amené à collecter et 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

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 ces volumes de données en vue de les attribuer directement à des pods, ou vous pouvez laisser Kubernetes les créer automatiquement. Les volumes de données peuvent utiliser : des Disques Azure, Azure Files, Azure NetApp Files ou des Objets blob Azure.

Notes

Le pilote CSI de disques Azure a une limite de 32 volumes par nœud. Les autres services de stockage Azure n’ont pas de limite équivalente.

Disques Azure

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

Les disques Azure étant montés en tant que ReadWriteOnce, ils ne sont disponibles 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][azure-files-volume] pour monter un partage SMB (Server Message Block) version 3.1.1 ou un partage NFS (Network File System) version 4.1 supporté par un compte 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 qu’aux 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 volumes ConfigMap sont stockés dans un espace de noms donné et ne sont accessibles qu’aux 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é.

Les disques ou les fichiers Azure sont utilisés pour fournir le PersistentVolume. 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 volume persistant peut être créé statiquement par un administrateur de cluster, ou 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.

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). reclaimPolicy permet de contrôler le comportement de la ressource de stockage Azure sous-jacente lorsque le pod est supprimé et que le volume persistant n’est plus nécessaire. 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 :

Autorisation	Motif
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 Azure Premium 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 sera utilisé. Lorsque vous demandez des volumes persistants, veillez à ce que le stockage approprié dont vous avez besoin soit utilisé.

Important

À partir de Kubernetes version 1.21, AKS utilise les pilotes CSI uniquement et par défaut. La classe default sera la même que managed-csi

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

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 relatives au stockage et aux sauvegardes dans Azure Kubernetes Service (AKS).

Pour savoir comment utiliser les pilotes CSI, consultez les articles de procédure suivants :

• Activer les pilotes Container Storage Interface (CSI) pour les disques Azure, Azure Files et le Stockage Blob Azure sur Azure Kubernetes Service
• Utiliser le pilote CSI Azure Disks dans Azure Kubernetes Service
• Utiliser le pilote CSI Azure Files dans Azure Kubernetes Service
• Utiliser le pilote CSI du stockage Blob Azure (préversion) dans Azure Kubernetes Service
• Intégrer Azure NetApp Files à 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