Options de stockage pour un cluster Kubernetes

Cet article compare les fonctionnalités de stockage d’Amazon Elastic Kubernetes Service (EKS) et d’Azure Kubernetes Service (AKS). Il décrit également les options de stockage pour les données de charge de travail sur AKS.

Remarque

Cet article fait partie d’une série d’articles qui aident les professionnels qui connaissent Amazon EKS à comprendre Azure Kubernetes Service (AKS).

Options de stockage d’Amazon EKS

Amazon EKS fournit différents types de volumes de stockage pour les applications qui nécessitent un stockage de données. Vous pouvez utiliser ces volumes pour un stockage temporaire et durable.

Volumes éphémères

Pour les applications qui nécessitent des volumes locaux temporaires, mais qui n’ont pas besoin de conserver les données après les redémarrages, utilisez des volumes éphémères. Kubernetes prend en charge différents types de volumes éphémères, tels que emptyDir, ConfigMap, downwardAPI, secret et hostPath. Pour garantir l’efficacité et les performances des coûts, choisissez le volume hôte le plus approprié. Dans Amazon EKS, vous pouvez utiliser gp3 comme volume racine hôte, ce qui coûte moins de volumes gp2.

Vous pouvez également utiliser des magasins d’instances Amazon EC2, qui fournissent un stockage temporaire au niveau du bloc pour les instances EC2. Ces volumes sont physiquement attachés aux hôtes et existent uniquement pendant la durée de vie de l’instance. Pour utiliser des volumes de magasin local dans Kubernetes, vous devez partitionner, configurer et mettre en forme les disques à l’aide des données utilisateur Amazon EC2.

Volumes persistants

Vous utilisez généralement Kubernetes pour exécuter des applications sans état, mais vous avez parfois besoin d’un stockage de données persistant. Vous pouvez utiliser des volumes persistants Kubernetes pour stocker des données indépendamment des pods afin que les données puissent persister au-delà de la durée de vie d’un pod donné. Amazon EKS prend en charge différents types d’options de stockage pour les volumes persistants, notamment Amazon EBS, Amazon Elastic File System (EFS), Amazon FSxpour Lustre et Amazon FSx pour NetApp ONTAP.

Utilisez des volumes Amazon EBS pour le stockage au niveau du bloc et pour les bases de données et les applications gourmandes en débit. Les utilisateurs d’Amazon EKS peuvent utiliser la dernière génération de stockage de blocs gp3 pour un équilibre entre les prix et les performances. Pour les applications plus performantes, vous pouvez utiliser des io2 Block Express volumes.

Amazon EFS est un système de fichiers serverless et élastique que vous pouvez partager sur plusieurs conteneurs et nœuds. Il augmente et réduit automatiquement à mesure que les fichiers sont ajoutés ou supprimés, ce qui élimine la nécessité de planifier la capacité. Le pilote CSI (Container Storage Interface) Amazon EFS intègre Amazon EFS à Kubernetes.

Amazon FSx pour Lustre fournit un stockage de fichiers parallèles hautes performances. Utilisez ce type de stockage pour les scénarios nécessitant des opérations à débit élevé et à faible latence. Vous pouvez lier ce stockage de fichiers à un référentiel de données Amazon S3 pour stocker des jeux de données volumineux. Amazon FSx pour NetApp ONTAP est une solution de stockage partagé entièrement managée basée sur le système de fichiers ONTAP de NetApp.

Pour optimiser les configurations de stockage et gérer les sauvegardes et les captures instantanées, utilisez des outils tels que AWS Compute Optimizer et Velero.

Options de stockage AKS

Les applications qui s’exécutent dans AKS peuvent avoir besoin de stocker et de récupérer des données. Certaines charges de travail d’application peuvent utiliser un stockage local et rapide sur des nœuds vides et inutiles. Toutefois, d’autres charges de travail d’application 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 :

• Partagez 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.

Les sections suivantes présentent les options de stockage et les concepts de base qui fournissent un stockage à vos applications dans AKS.

Types de volume

Les volumes Kubernetes représentent plus qu’un disque traditionnel pour stocker et récupérer des informations. Vous pouvez également utiliser des volumes Kubernetes pour injecter des données dans un pod pour qu'elles soient utilisées par ses conteneurs.

Les types de volumes courants dans Kubernetes incluent emptyDirs, secrets et ConfigMaps.

EmptyDirs

Pour un pod qui définit un volume emptyDir, le volume est créé lorsque le pod est affecté à un nœud. Comme le nom l’indique, le volume emptyDir est initialement vide. Tous les conteneurs du pod peuvent lire et écrire les mêmes fichiers dans le volume emptyDir, bien que ce volume puisse être monté sur les mêmes chemins d’accès ou différents dans chaque conteneur. Lorsqu’un pod est supprimé d’un nœud pour une raison quelconque, les données du emptyDir sont supprimées définitivement.

Secrets

Un secret est un objet qui contient une petite quantité de données sensibles, telles qu’un mot de passe, un jeton ou une clé. Si vous n’utilisez pas de secret, ces informations sont incluses dans une spécification de pod ou une image conteneur. Un secret empêche l’incorporation de données confidentielles directement dans votre code d’application. Vous pouvez créer des secrets indépendamment des pods qui les utilisent. Cette pratique réduit le risque d’exposer le secret et ses données lorsque vous créez, affichez et modifiez des pods. Kubernetes et les applications qui s’exécutent dans votre cluster peuvent prendre des précautions supplémentaires avec des secrets, comme empêcher l’écriture de données sensibles dans un stockage nonvolatile. Les secrets sont similaires à ConfigMaps, mais ils sont spécifiquement conçus pour stocker des données confidentielles.

Vous pouvez utiliser des secrets à des fins suivantes :

• Définir des variables d’environnement pour un conteneur.
• Fournissez des informations d’identification telles que des clés SSH ou des mots de passe aux pods.
• Autoriser le kubelet à extraire des images conteneur à partir de registres privés.

Le plan de contrôle Kubernetes utilise également des secrets, tels que les secrets de jeton de démarrage, qui permettent d’automatiser l’inscription des nœuds.

ConfigMaps

Un ConfigMap est un objet Kubernetes que vous utilisez pour stocker des données nonconfidentiales dans des paires clé-valeur. Les pods peuvent utiliser ConfigMaps en tant que variables d’environnement, arguments de ligne de commande ou en tant que fichiers de configuration dans un volume. Vous pouvez utiliser un ConfigMap pour dissocier les configurations spécifiques à l’environnement à partir de vos images conteneur, ce qui rend vos applications facilement portables.

ConfigMaps ne fournit pas de secret ni de chiffrement. Si vous souhaitez stocker des données confidentielles, utilisez un secret plutôt qu’un ConfigMap ou utilisez d’autres outils partenaires pour conserver vos données privées.

Vous pouvez utiliser un ConfigMap pour définir des données de configuration séparément du code de l’application. Par exemple, vous pouvez développer une application à exécuter sur votre ordinateur pour le développement et s’exécuter dans le cloud pour gérer le trafic réel. Vous pouvez écrire le code à rechercher dans une variable d’environnement nommée DATABASE_HOST. En local, définissez cette variable sur localhost. Dans le cloud, définissez-le pour faire référence à un service Kubernetes qui expose le composant de base de données à votre cluster. Cette approche vous permet d’extraire une image conteneur qui s’exécute dans le cloud et de déboguer le même code localement si nécessaire.

Volumes persistants

Les volumes définis et créés dans le cadre du cycle de vie du pod n’existent que jusqu’à ce que vous supprimiez le pod. 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 que l’API Kubernetes crée et gère. Un volume persistant peut exister au-delà de la durée de vie d’un pod individuel. Vous pouvez utiliser les outils de stockage Azure suivants pour fournir le volume persistant :

• Stockage sur disque Azure
• Azure Files
• Azure NetApp Files
• Stockage Blob Azure
• Conteneur de stockage Azure

Pour choisir entre le stockage sur disque Azure ou Azure Files, déterminez si votre application a besoin d’un accès simultané aux données ou d’un niveau de performances spécifique.

Le diagramme montre deux scénarios : accès à un seul nœud ou pod et accès simultané à plusieurs nœuds ou pods. Le scénario d’accès à un nœud unique ou pod utilise des disques managés Azure (Stockage Standard ou Premium). Le scénario d’accès à plusieurs nœuds ou pods simultanés utilise Azure Files (stockage Standard). Les deux scénarios pointent vers un volume persistant au sein du cluster AKS.

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

Importante

Les pods Windows et Linux ne peuvent pas partager de volumes persistants, car les systèmes d’exploitation prennent en charge différents systèmes de fichiers.

Si vous souhaitez une solution entièrement managée pour l’accès au niveau du bloc aux données, envisagez d’utiliser le stockage de conteneurs Azure au lieu des pilotes CSI. Azure Container Storage s’intègre à Kubernetes pour fournir un approvisionnement dynamique et automatique de volumes persistants. Azure Container Storage prend en charge les disques Azure, les disques éphémères et Azure Elastic SAN (préversion) comme stockage. Ces options offrent une flexibilité et une scalabilité pour les applications avec état qui s’exécutent sur des clusters Kubernetes.

Classes de stockage

Pour spécifier 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. Lorsque vous supprimez un volume persistant, la stratégie de récupération contrôle le comportement de la ressource stockage Azure sous-jacente. La ressource sous-jacente peut être supprimée ou conservée pour une utilisation avec un pod futur.

Les clusters qui utilisent Azure Container Storage ont une classe de stockage supplémentaire appelée acstor-<storage-pool-name>. Une classe de stockage interne est également créée.

Pour les clusters qui utilisent des pilotes CSI, les classes de stockage supplémentaires suivantes sont créées :

Classe de stockage	Descriptif
managed-csi	Utilise un ssd Standard Azure avec stockage localement redondant (LRS) pour créer un disque managé. La stratégie de récupération garantit que le disque Azure sous-jacent est supprimé lorsque le volume persistant utilisé est supprimé. La classe de stockage configure également les volumes persistants pour qu’ils soient extensibles. Vous pouvez modifier la revendication de volume persistant pour spécifier la nouvelle taille. Pour Kubernetes version 1.29 et ultérieure, cette classe de stockage utilise le SSD Standard avec un stockage redondant interzone (ZRS) pour créer des disques managés pour les clusters AKS déployés dans plusieurs zones de disponibilité.
managed-csi-premium	Utilise le SSD Premium Azure avec LRS pour créer un disque managé. La stratégie de récupération garantit que le disque Azure sous-jacent est supprimé lorsque le volume persistant utilisé est supprimé. Cette classe de stockage permet aux volumes persistants d’être développés. Pour Kubernetes version 1.29 et ultérieure, cette classe de stockage utilise un SSD Premium avec ZRS pour créer des disques managés pour les clusters AKS déployés dans plusieurs zones de disponibilité.
azurefile-csi	Utilise le stockage SSD Standard pour créer un partage de fichiers Azure. La stratégie de récupération garantit que le partage de fichiers Azure sous-jacent est supprimé lorsque le volume persistant utilisé est supprimé.
azurefile-csi-premium	Utilise le stockage SSD Premium pour créer un partage de fichiers Azure. La stratégie de récupération garantit que le partage de fichiers Azure sous-jacent est supprimé lorsque le volume persistant utilisé est supprimé.
azureblob-nfs-premium	Utilise le stockage SSD Premium pour créer un conteneur de stockage Blob et se connecter via le protocole NFS (Network File System) v3. La stratégie de récupération veille à ce que le conteneur Stockage Blob sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé.
azureblob-fuse-premium	Utilise le stockage SSD Premium pour créer un conteneur Stockage Blob et se connecter via BlobFuse. La stratégie de récupération veille à ce que le conteneur Stockage Blob sous-jacent soit supprimé quand le volume persistant qui l’a utilisé est supprimé.

Sauf si vous spécifiez une classe de stockage pour un volume persistant, la classe de stockage par défaut est utilisée. Vérifiez que les volumes utilisent le stockage dont vous avez besoin lorsque vous demandez des volumes persistants.

Importante

Pour Kubernetes version 1.21 et ultérieure, AKS utilise les pilotes CSI par défaut, et la migration CSI est activée. Les volumes persistants dans l’arborescence existants continuent de fonctionner, mais pour la version 1.26 et ultérieure, AKS ne prend plus en charge les volumes créés à l’aide du pilote et du stockage dans l’arborescence approvisionnés pour les fichiers et les disques.

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

Pour Kubernetes version 1.29 et ultérieure, lorsque vous déployez des clusters AKS sur plusieurs zones de disponibilité, AKS utilise 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 votre région choisie. Cette stratégie de redondance améliore la résilience de vos applications et contribue à protéger vos données contre les défaillances du centre de données.

Toutefois, ZRS coûte plus cher que LRS. Si l’optimisation des coûts est une priorité, vous pouvez créer une classe de stockage dont le skuname paramètre est défini sur LRS. Vous pouvez ensuite utiliser la nouvelle classe de stockage dans votre revendication de volume persistant.

Vous pouvez créer une classe de stockage pour d’autres besoins à l’aide kubectlde . L’exemple suivant utilise des disques managés Premium et spécifie que le disque Azure sous-jacent doit être conservé lorsque vous supprimez le 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

AKS rapproche les classes de stockage par défaut et remplace les modifications apportées à ces classes de stockage.

Pour plus d’informations, consultez StorageClass dans Kubernetes.

Revendications de volume persistant

Une revendication de volume persistant demande le stockage d’une classe de stockage particulière, du mode d’accès et de la taille. Le serveur d’API Kubernetes peut provisionner dynamiquement la ressource stockage Azure sous-jacente si aucune ressource existante ne peut remplir la revendication en fonction de la classe de stockage définie.

La définition du pod inclut le montage du volume une fois que ce dernier se connecte au pod.

Le côté gauche comporte deux sections : un accès à un seul nœud ou pod et un accès à plusieurs nœuds ou pods simultanés. L’accès à un nœud unique ou pod utilise des disques managés Azure (stockage Standard ou Premium). Une flèche pointe depuis un accès à un seul nœud ou pod vers un volume persistant dans le cluster AKS situé à droite. L’accès à plusieurs nœuds ou pods simultanés utilise Azure Files (stockage Standard). Une flèche indique l'accès simultané de plusieurs nœuds ou pods au même volume persistant dans le cluster AKS situé à droite. Dans le cluster AKS, un volume persistant se connecte à une revendication de volume persistant, qui lie à une classe de stockage. La revendication de volume persistant pointe vers les nœuds et les pods.

Une fois qu’une ressource de stockage disponible est affectée au pod qui demande le stockage, le volume persistant est lié à une revendication de volume persistant. Chaque volume persistant est associé à une revendication de volume persistant pour garantir un stockage dédié.

L’exemple de manifeste YAML suivant montre une revendication de volume persistant qui utilise la classe de stockage managed-premium et demande un disque Azure 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 :

• Requête de volume persistant pour demander le stockage souhaité.
• Le montage de volume permettant à vos applications de lire et d’écrire des données.

L’exemple de manifeste YAML suivant montre comment la revendication de volume persistant précédente peut 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 disque et le chemin d’accès :

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

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

Par défaut, Azure réplique automatiquement le disque du système d’exploitation pour une machine virtuelle vers stockage Azure afin d’éviter toute perte de données lorsque la machine virtuelle est déplacée vers un autre hôte. Toutefois, les conteneurs ne sont pas conçus pour conserver l’état local. Ce comportement offre donc une valeur et des inconvénients limités. Ces inconvénients incluent l’approvisionnement de nœuds plus lent et une latence de lecture et d’é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. Cette configuration fournit une latence de lecture et d’écriture plus faible et une mise à niveau de nœud plus rapide et des mises à niveau de cluster.

Si vous ne demandez pas de disques managés Azure pour le disque du système d'exploitation, AKS utilise par défaut des disques de système d'exploitation éphémères si possible dans une configuration de pool de nœuds spécifique.

Pour connaître les exigences de taille et les recommandations, consultez disques de système d’exploitation éphémères pour les machines virtuelles Azure. Tenez compte des considérations de dimensionnement suivantes :

• Si vous utilisez la taille de machine virtuelle par défaut AKS Standard_DS2_v2 référence SKU avec la taille de disque de système d’exploitation par défaut de 100 Gio, la taille de machine virtuelle par défaut prend en charge les disques de système d’exploitation éphémères, mais n’a qu’une taille de cache de 86 Gio. Cette configuration utilise par défaut des disques managés si vous ne la spécifiez pas. 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 référence SKU Standard_DS2_v2 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 à 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 les disques de système d’exploitation éphémères et a une taille de cache de 200 Gio. Si vous ne spécifiez pas le type de disque du système d’exploitation, le pool de nœuds reçoit par défaut des disques de système d’exploitation éphémères.

La dernière génération de la série de machines virtuelles n’a pas de cache dédié et dispose uniquement d’un stockage temporaire.

• Si vous sélectionnez la taille de machine virtuelle Standard_E2bds_v5 avec la taille de disque de système d’exploitation par défaut de 100 Gio, la machine virtuelle prend en charge les disques de système d’exploitation éphémères, mais dispose uniquement de 75 Go de stockage temporaire. Cette configuration est par défaut sur les disques de système d’exploitation managés si vous ne le spécifiez pas. 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 est par défaut sur 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 les disques de système d’exploitation éphémères et a 150 Gio de stockage temporaire. Si vous ne spécifiez pas le type de disque du système d’exploitation, Azure provisionne un disque de système d’exploitation éphémère dans le 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 à l’aide de vos propres clés sur un cluster AKS. Pour plus d’informations, consultez Utiliser vos propres clés avec des disques gérés 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 pour l’utilisation et la persistance des données. Un volume représente un moyen de stocker, récupérer et conserver des données à travers les pods et tout au long du cycle de vie de l’application.

Les volumes traditionnels sont créés en tant que ressources Kubernetes sauvegardées par stockage Azure. Vous pouvez créer manuellement des volumes de données à affecter directement aux pods ou laisser Kubernetes les créer automatiquement. Les volumes de données peuvent utiliser stockage disque Azure, Azure Files, Azure NetApp Files ou Stockage Blob.

Remarque

Selon votre référence SKU de machine virtuelle, le pilote CSI de disque Azure peut avoir une limite de volume pour chaque nœud. Pour certaines machines virtuelles hautes performances, telles que 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. Pour obtenir la liste des références SKU de machine virtuelle et leurs limites de capacité correspondantes, consultez tailles de machine virtuelle à usage général.

Pour choisir entre Azure Files et Azure NetApp Files, consultez la comparaison d’Azure Files et d’Azure NetApp Files.

Stockage sur disque Azure

Par défaut, un cluster AKS est fourni avec des classes de stockage managed-csi et managed-csi-premium précréées, qui utilisent la fonctionnalité Stockage sur disque Azure. À l’image d’Amazon EBS, ces classes créent un disque managé ou un périphérique en mode bloc attaché au nœud pour permettre l’accès aux pods.

Les classes de disque autorisent le provisionnement de volumes statiques et dynamiques . La stratégie de récupération garantit que le disque est supprimé avec le volume persistant. Pour développer le disque, modifiez la réclamation de volume persistant.

Ces classes de stockage utilisent des disques managés Azure avec LRS. Les données dans LRS ont trois copies synchrones dans un emplacement physique unique dans une région primaire Azure. LRS est l’option de réplication la moins coûteuse, mais ne fournit pas de protection contre une défaillance du centre de données. Vous pouvez définir des classes de stockage personnalisées qui utilisent des disques managés ZRS.

ZRS réplique de manière synchrone votre disque managé Azure sur trois zones de disponibilité Azure dans votre région. Chaque zone de disponibilité est un emplacement physique distinct qui a une alimentation indépendante, un refroidissement et un réseau. Les disques ZRS fournissent au moins 99,999999999999999 % de durabilité sur une année donnée. Un disque managé ZRS peut être attaché par une machine virtuelle dans une autre zone de disponibilité. Les disques ZRS ne sont pas disponibles dans toutes les régions Azure. Pour plus d’informations, consultez les options ZRS pour les disques Azure afin d’améliorer la disponibilité.

Pour atténuer le risque de perte de données, utilisez la sauvegarde AKS pour effectuer des sauvegardes ou des captures instantanées régulières des données de stockage de disque. Vous pouvez également utiliser des solutions partenaires, telles que Velero ou Sauvegarde Azure, qui ont une technologie d’instantané intégrée.

Vous pouvez utiliser le stockage de disque Azure pour créer une ressource Kubernetes DataDisk . Vous pouvez utiliser les types de disques suivants :

• SSD Premium (recommandé pour la plupart des charges de travail)
• SSD Premium v2
• Stockage sur disque Ultra Azure
• SSD Standard
• Azure Standard HDD

Conseil

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

Un disque Azure est monté en tant que ReadWriteOnce. Il est donc disponible uniquement pour un seul nœud. Pour les volumes de stockage que les pods sur plusieurs nœuds peuvent accéder simultanément, utilisez Azure Files.

Disques SSD Premium v2

Les disques SSD Premium v2 sont conçus pour les charges de travail d’entreprise intenses en entrée/sortie(E/S). Ils fournissent une latence de disque de sous-milliseconde cohérente, des opérations d’entrée/sortie élevées par seconde (IOPS) et un débit élevé. Vous pouvez configurer indépendamment les performances (capacité, IOPS et débit) des disques SSD Premium v2 à tout moment. Vous améliorez donc facilement l’efficacité des coûts tout en répondant aux besoins en matière de performances. Pour plus d’informations sur la configuration d’un cluster AKS nouveau ou existant pour utiliser des disques SSD Premium v2 Azure Premium, consultez Utiliser des disques SSD Premium v2 sur AKS.

Stockage sur disque ultra

Le stockage sur disque Ultra est un niveau de disque managé Azure qui fournit un débit élevé, des IOPS élevés et un stockage de disque à faible latence cohérent pour les machines virtuelles Azure. Utilisez le stockage sur disque Ultra pour les charges de travail gourmandes en données et les transactions. Comme d’autres SKU de stockage sur disque et Amazon EBS, le stockage sur disque Ultra ne monte qu'un seul pod à la fois et ne fournit pas d’accès simultané.

Pour activer le stockage sur disque Ultra sur votre cluster AKS, utilisez l’indicateur --enable-ultra-ssd.

Tenez compte des limitations du stockage sur disque Ultra et sélectionnez une taille de machine virtuelle compatible. Le stockage sur disque Ultra dispose d’une réplication LRS.

Apportez vos propres clés (BYOK)

Azure chiffre toutes les données d’un disque managé au repos, y compris le système d’exploitation et les disques de données d’un cluster AKS. Par défaut, les données sont chiffrées avec des clés managées par Microsoft Pour plus de contrôle sur les clés de chiffrement, vous pouvez fournir des clés gérées par le client pour fournir le chiffrement au repos pour le système d’exploitation et les disques de données dans les clusters AKS. Pour plus d’informations, consultez BYOK avec des disques managés Azure dans AKS et le chiffrement côté serveur du stockage de disques Azure.

Azure Files

Le stockage sur disque ne peut pas fournir un accès simultané à un volume, mais vous pouvez utiliser Azure Files pour monter un partage SMB (Server Message Block) version 3.1.1 ou un partage NFS version 4.1 sauvegardé par stockage Azure. Ce processus fournit un stockage attaché au réseau similaire à Amazon EFS. Azure Files propose deux options de stockage :

• Le stockage Azure Files Standard sauvegarde le partage de fichiers avec des disques durs standard (HDD).

• Le stockage Azure Files Premium sauvegarde le partage de fichiers avec des disques SSD hautes performances. La taille minimale du partage de fichiers pour le stockage Premium est de 100 Go.

Azure Files propose les options de réplication de compte de stockage suivantes pour protéger vos données en cas de défaillance :

• Standard_LRS : LRS standard
• Standard_GRS: stockage géoredondant (GRS) standard
• Standard_ZRS : ZRS standard
• Standard_RAGRS : GRS en accès lecture (RA-GRS) standard
• Standard_RAGZRS : stockage géoredondant interzone en accès lecture (RA-GZRS) standard
• Premium_LRS : Premium LRS
• Premium_ZRS : Premium ZRS

Pour optimiser les coûts d’Azure Files, achetez des réservations de capacité Azure Files.

Azure NetApp Files (service de stockage de fichiers dans le cloud)

Azure NetApp Files est un service de stockage de fichiers de classe entreprise et haute performance, déployé sur Azure, qui prend en charge les volumes utilisant NFS (NFSv3 ou NFSv4.1), SMB, et double protocole (NFSv3 et SMB ou NFSv4.1 et SMB). Les utilisateurs Kubernetes ont deux options d’utilisation des volumes Azure NetApp Files pour les charges de travail Kubernetes :

• Créez des volumes Azure NetApp Files de manière statique. Créez des volumes en dehors d’AKS via Azure CLI ou le portail Azure. Après la création, ces volumes sont exposés à Kubernetes en créant un PersistentVolume. Les volumes Azure NetApp Files créés statiquement ont de nombreuses limitations. Par exemple, ils ne peuvent pas être développés et doivent être surprovisionnés. Nous vous déconseillons de créer statiquement des volumes pour la plupart des cas d’usage.

• Créez dynamiquement des volumes Azure NetApp Files via Kubernetes. Il s’agit de la méthode recommandée pour créer plusieurs volumes directement via Kubernetes à l’aide d’Astra Trident. Astra Trident est un orchestrateur de stockage dynamique compatible CSI qui permet de provisionner des volumes en mode natif via Kubernetes.

Pour plus d’informations, consultez Configurer Azure NetApp Files pour AKS.

Stockage Blob

Le pilote de stockage Blob CSI est un pilote conforme à la spécification CSI qu'AKS utilise pour gérer le cycle de vie du stockage Blob. Le CSI est une norme pour exposer des systèmes de stockage de fichiers et de blocs arbitraires aux charges de travail conteneurisées sur Kubernetes.

Adoptez et utilisez le CSI pour qu’AKS puisse écrire, déployer et itérer des plug-ins. Les plug-ins exposent de nouveaux systèmes de stockage ou améliorent les systèmes de stockage existants dans Kubernetes. Les pilotes CSI dans AKS évitent de devoir modifier le code Kubernetes principal et d’attendre ses cycles de publication.

Lorsque vous montez le Stockage Blob en tant que système de fichiers dans un conteneur ou un pod, vous pouvez l’utiliser avec des applications qui gèrent de grandes quantités de données non structurées, telles que :

• Données du fichier journal.
• Images, documents et diffusion en continu vidéo ou audio.
• Données de reprise après sinistre.

Les applications peuvent accéder aux données sur le stockage d’objets via BlobFuse ou le protocole NFS 3.0. Avant l’introduction du pilote CSI stockage Blob, la seule option consiste à installer manuellement un pilote non pris en charge pour accéder au stockage Blob à partir de votre application qui s’exécute sur AKS. Un pilote CSI de stockage Blob activé sur AKS a deux classes de stockage intégrées : azureblob-fuse-premium et azureblob-nfs-premium.

Pour créer un cluster AKS qui prend en charge les pilotes CSI, consultez les pilotes CSI sur AKS. Pour plus d’informations, consultez Comparer l’accès à Azure Files, Stockage Blob et Azure NetApp Files avec NFS.

Azure HPC Cache

HPC Cache accélère l’accès à vos données pour les tâches informatiques hautes performances et fournit l’extensibilité des solutions cloud. Si vous choisissez cette solution de stockage, veillez à déployer votre cluster AKS dans une région qui prend en charge HPC Cache.

Serveur NFS

Pour l’accès NFS partagé, vous devez utiliser Azure Files ou Azure NetApp Files. Vous pouvez également créer un serveur NFS sur une machine virtuelle Azure qui exporte des volumes.

Cette option prend uniquement en charge l’approvisionnement statique. Vous devez provisionner manuellement les partages NFS sur le serveur. Il n'est pas possible de provisionner automatiquement des partages NFS sur AKS.

Cette solution est basée sur une offre IaaS (infrastructure as a service) au lieu d’une offre PaaS (platform as a service). Vous gérez le serveur NFS, notamment les mises à jour du système d’exploitation, la haute disponibilité, les sauvegardes, la récupération d’urgence et l’extensibilité.

Stockage de conteneur Azure

Azure Container Storage est un service de gestion, de déploiement et d’orchestration basé sur le cloud qui est conçu en mode natif pour les conteneurs. Il s’intègre à Kubernetes afin que vous puissiez approvisionner dynamiquement et automatiquement des volumes persistants pour stocker des données pour les applications avec état qui s’exécutent sur des clusters Kubernetes.

Azure Container Storage utilise des offres de stockage Azure existantes pour le stockage de données réel et fournit une solution d’orchestration et de gestion de volume conçue pour les conteneurs. Azure Container Storage prend en charge la solution de stockage suivante :

• Disques Azure : Fournissez un contrôle granulaire des références SKU et des configurations de stockage. Les disques Azure conviennent aux bases de données de niveau 1 et à usage général.

• Disques éphémères : Utilisez des ressources de stockage locales sur des nœuds AKS (NVMe ou SSD temporaire). Les disques éphémères conviennent aux applications qui n’ont pas de exigences de durabilité des données ou qui prennent en charge la réplication de données intégrée. AKS découvre le stockage éphémère disponible sur les nœuds AKS et les acquiert pour le déploiement de volumes.

• Elastic SAN : ressources entièrement gérées, approvisionnées à la demande. Le san élastique convient aux bases de données, aux services de diffusion en continu et de messagerie, à l’intégration continue et aux environnements de livraison continue, ainsi qu’à d’autres charges de travail de niveau 1 ou de niveau 2. Plusieurs clusters peuvent accéder simultanément à un seul réseau de zone de stockage (SAN). Toutefois, les volumes persistants ne peuvent être attachés qu’à un seul consommateur à la fois.

Précédemment, pour fournir un stockage cloud pour les conteneurs, vous avez besoin de pilotes CSI individuels pour adapter les services de stockage destinés aux charges de travail centrées sur IaaS. Cette méthode a créé une surcharge opérationnelle et a augmenté le risque de problèmes liés à la disponibilité des applications, à l’extensibilité, aux performances, à la facilité d’utilisation et au coût.

Azure Container Storage est dérivé d’OpenEBS, solution open source offrant des capacités de stockage de conteneurs pour Kubernetes. Azure Container Storage fournit une solution d’orchestration de volume managée via des contrôleurs de stockage basés sur des microservice dans un environnement Kubernetes. Cette fonctionnalité active le stockage natif du conteneur.

Azure Container Storage convient aux scénarios suivants :

• Accélérer les initiatives machine virtuelle vers conteneur : Azure Container Storage dévoile la gamme complète d’offres de stockage par blocs Azure qui n’était auparavant accessible qu’aux machines virtuelles et la met à la disposition des conteneurs. Ce stockage inclut un stockage sur disque éphémère, qui offre une latence extrêmement faible pour les charges de travail comme Cassandra. Il inclut également Elastic SAN, qui fournit des cibles iSCSI natives et des cibles provisionnées et partagées.

• Simplifiez la gestion des volumes avec Kubernetes : Azure Container Storage fournit une orchestration de volume via le plan de contrôle Kubernetes. Cette fonctionnalité simplifie le déploiement et la gestion des volumes dans Kubernetes, sans avoir à basculer entre différents plans de contrôle.

• Réduisez le coût total de possession : Pour améliorer l’efficacité des coûts, augmentez l’échelle des volumes persistants pris en charge pour chaque pod ou nœud. Pour réduire les ressources de stockage nécessaires à l’approvisionnement, partagez dynamiquement les ressources de stockage. La prise en charge de l'extension du pool de stockage n’est pas incluse.

Le stockage de conteneurs Azure offre les avantages clés suivants :

• Scale-out rapide des pods avec état : Azure Container Storage monte des volumes persistants via des protocoles de stockage réseau par blocs, tels que NVMe-oF ou iSCSI. Cette fonctionnalité garantit un attachement et un détachement rapides des volumes persistants. Vous pouvez commencer petit et déployer des ressources au besoin pour vous assurer que vos applications ne sont pas privées de ressources ou interrompues pendant l'initialisation ou en production. Lorsqu’un pod réapparaît sur le cluster, le volume persistant associé doit être rapidement rattaché au nouveau pod pour maintenir la résilience des applications. À l’aide de protocoles de réseau à distance, Azure Container Storage est étroitement couplé au cycle de vie des pods pour prendre en charge des applications à état hautement résilientes et à grande échelle sur AKS.

• Améliorez les performances des charges de travail avec état : Azure Container Storage offre des performances de lecture supérieures et fournit des performances d'écriture proches de celles du disque en utilisant NVMe-oF sur RDMA. Cette fonctionnalité vous permet de répondre à des exigences de performances rentables pour différentes charges de travail de conteneur, notamment les charges de travail nécessitant beaucoup d’E/S de niveau 1, à usage général, sensibles au débit et aux charges de travail de développement/test. Écourtez la durée d’attachement et de détachement des volumes persistants et réduisez le temps de basculement des pods.

• Orchestrez des volumes natifs Kubernetes : Créez des pools de stockage et des volumes persistants, capturez des instantanés et gérez l’ensemble du cycle de vie des volumes à l’aide kubectl de commandes sans basculer entre des ensembles d’outils pour différentes opérations de plan de contrôle.

Solutions de partenaires

Comme Amazon EKS, AKS est une implémentation Kubernetes et vous pouvez intégrer des solutions de stockage Kubernetes partenaires. Voici quelques exemples de solutions de stockage partenaires pour Kubernetes :

• Rook transforme les systèmes de stockage distribués en services de stockage auto-gérants en automatisant les tâches d’administrateur stockage Azure. Rook offre ses services via un opérateur Kubernetes pour chaque fournisseur de stockage.

• GlusterFS est un système de fichiers réseau scalable, gratuit et open source, qui utilise du matériel standard prêt à l’emploi pour la création de solutions de stockage distribué de grande envergure, destinées aux tâches intensives sur le plan des données et de la bande passante.

• Ceph fournit un service de stockage unifié fiable et évolutif qui a des interfaces d’objet, de bloc et de fichier à partir d’un seul cluster créé à partir de composants matériels de base.

• Le stockage d’objets multicloud MinIO permet aux entreprises de créer une infrastructure de données compatible AWS S3 sur n’importe quel cloud. Il fournit une interface cohérente et portable pour vos données et applications.

• Portworx est une solution de stockage et de gestion des données de bout en bout pour les projets Kubernetes et les initiatives basées sur des conteneurs. Portworx fournit un stockage granulaire de conteneur, une récupération d’urgence, une sécurité des données et des migrations multiclouds.

• Quobyte fournit un stockage de fichiers et d’objets hautes performances que vous pouvez déployer sur n’importe quel serveur ou cloud pour mettre à l’échelle les performances, gérer de grandes quantités de données et simplifier l’administration.

• Ondat fournit une couche de stockage cohérente sur n’importe quelle plateforme. Vous pouvez exécuter une base de données ou une charge de travail persistante dans un environnement Kubernetes sans avoir à gérer la couche de stockage.

Considérations relatives au stockage Kubernetes

Tenez compte des facteurs suivants quand vous choisissez une solution de stockage pour Amazon EKS ou AKS.

Modes d’accès aux classes de stockage

Dans Kubernetes version 1.21 et ultérieure, par défaut, les classes de stockage AKS et Amazon EKS utilisent uniquement les pilotes CSI .

Différents services prennent en charge les classes de stockage ayant différents modes d’accès.

Service	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
Stockage sur disque Azure	X
Azure Files	X	X	X
Azure NetApp Files (service de stockage de fichiers dans le cloud)	X	X	X
Serveur NFS	X	X	X
HPC Cache	X	X	X

Approvisionnement dynamique et statique

Provisionnez dynamiquement les volumes pour réduire la surcharge de gestion liée à la création statique de volumes persistants. Définissez une stratégie de récupération appropriée pour éliminer les disques inutilisés lorsque vous supprimez des pods.

Sauvegarde

Choisissez un outil pour sauvegarder les données persistantes. L’outil doit correspondre à votre type de stockage, par exemple les captures instantanées, Sauvegarde Azure, Velero ou Kasten.

Optimisation des coûts

Pour optimiser les coûts de stockage Azure, utilisez des réservations Azure si le service les prend en charge. Pour plus d’informations, consultez Cost Management pour un cluster Kubernetes.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• Paolo Salvatori | Ingénieur système principal
• Laura Nicolas | Architecte de solution cloud senior

Autres contributeurs :

• Chad Kittel | Ingénieur logiciel principal - Modèles et pratiques Azure
• Ed Price | Responsable de programme senior
• Theano Petersen | Rédacteur technique

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Formation : Services stockage Azure
• Formation : Stocker des données dans Azure
• Formation : Présentation de Kubernetes
• Formation : Présentation d’Azure NetApp Files

Ressources associées

• AKS pour les professionnels Amazon EKS
• Gestion de l’identité et de l’accès Kubernetes
• Surveillance et journalisation Kubernetes
• Sécuriser l’accès réseau à Kubernetes
• Gestion des coûts pour Kubernetes
• Gestion des nœuds et des pools de nœuds Kubernetes
• Gouvernance des clusters