Partage via

Options de stockage pour un cluster Kubernetes

  • Article

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

Remarque

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

Options de stockage d’Amazon EKS

Lors de l’exécution d’applications nécessitant un stockage de données, Amazon EKS offre différents types de 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, les volumes éphémères peuvent être utilisés. Kubernetes prend en charge différents types de volumes éphémères, tels que emptyDir, configMap, downwardAPI, secretet hostPath. Pour garantir l’efficacité et les performances des coûts, il est important de choisir le volume hôte le plus approprié. Dans Amazon EKS, vous pouvez utiliser gp3 comme volume racine hôte, ce qui offre des prix inférieurs aux volumes gp2.

Il existe une autre option pour les volumes éphémères à travers les stores d’instances Amazon EC2, qui offrent un stockage temporaire au niveau 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. L’utilisation de volumes de magasin local dans Kubernetes nécessite le partitionnement, la configuration et la mise en forme des disques à l’aide des données utilisateur Amazon EC2.

Volumes persistants

Bien que Kubernetes soit généralement associé à l’exécution d’applications sans état, il existe des cas où le stockage de données persistant est requis. Les volumes persistants Kubernetes (PVS) peuvent être utilisés pour stocker des données indépendamment des pods, ce qui permet aux données de 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 PV, notamment Amazon EBS, Amazon EFS, Amazon FSx pour Lustreet Amazon FSx pour NetApp ONTAP.

les volumes Amazon EBS conviennent au stockage au niveau du bloc et conviennent parfaitement aux bases de données et aux 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, des volumes express de blocs io2 peuvent être utilisés.

Amazon EFS est un système de fichiers serverless et élastique qui peut être partagé entre plusieurs conteneurs et nœuds. Il augmente et se 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 (Amazon Elastic File System Container Storage Interface) est utilisé pour intégrer Amazon EFS à Kubernetes.

Amazon FSx pour Lustre fournit un stockage de fichiers parallèles hautes performances, idéal pour les scénarios nécessitant un débit élevé et des opérations à faible latence. Il peut être lié à 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.

Les utilisateurs d’Amazon EKS peuvent utiliser des outils tels que AWS Compute Optimizer et Velero pour optimiser les configurations de stockage et gérer les sauvegardes et les captures instantanées.

Options de stockage AKS

Les applications s’exécutant 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’application puissent utiliser un stockage rapide local sur des nœuds inutiles, 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 :

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

Cet article présente 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. Les volumes de Kubernetes peuvent également être utilisés comme moyen d’injecter des données dans un pod pour utilisation par ses conteneurs.

Les types de volumes courants dans Kubernetes incluent EmptyDirs, secretet 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 suggère le nom, 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 de l'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é. Ces informations seraient autrement incluses dans une spécification Pod ou une image conteneur. En utilisant un secret, vous évitez d’incorporer des données confidentielles directement dans votre code d’application. Étant donné que les secrets peuvent être créés indépendamment des pods qui les utilisent, il existe un risque réduit d’exposer le secret (et ses données) pendant les processus de création, d’affichage et de modification des pods. Kubernetes, ainsi que les applications s’exécutant dans votre cluster, peuvent également prendre des précautions supplémentaires avec les Secrets, comme empêcher l’écriture de données sensibles dans un stockage non-volatile. Bien que les secrets soient similaires à ConfigMaps, ils sont spécifiquement conçus pour stocker des données confidentielles.

Vous pouvez utiliser les secrets à des fins suivantes :

Le plan de contrôle Kubernetes utilise également des Secrets, tels que les Secrets de jeton de démarrage, qui sont un mécanisme permettant d’automatiser l’inscription des nœuds.

ConfigMaps

Un ConfigMap est un objet Kubernetes utilisé pour stocker des données non confidentielles 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. Un ConfigMap vous permet de dissocier la configuration spécifique à l’environnement à partir de vos images conteneur , afin que vos applications soient facilement portables.

ConfigMap ne fournit pas de secret ni de chiffrement. Si les données que vous souhaitez stocker sont confidentielles, utilisez un Secret plutôt qu’un ConfigMap, ou utilisez des outils supplémentaires (tiers) 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, imaginez que vous développez une application que vous pouvez exécuter sur votre propre ordinateur (pour le développement) et dans le cloud (pour gérer le trafic réel). Vous écrivez le code à rechercher dans une variable d’environnement nommée DATABASE_HOST. Localement, vous définissez cette variable sur localhost. Dans le cloud, vous l’avez définie pour faire référence à un service Kubernetes qui expose le composant de base de données à votre cluster. Cela vous permet d’extraire une image conteneur s’exécutant dans le cloud et de déboguer exactement le même code localement si nécessaire.

Volumes persistants

Les volumes définis et créés dans le cadre du cycle de vie des pods 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 (PV) est une ressource de stockage créée et gérée par l’API Kubernetes qui peut exister au-delà de la durée de vie d’un pod individuel. Vous pouvez utiliser les services stockage Azure suivants 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 la nécessité d’un accès simultané aux données ou au niveau de performances.

Diagramme des volumes persistants dans un cluster Azure Kubernetes Services (AKS).

Un administrateur de cluster peut de façon statique créer 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 de disque ou de fichier Azure sous-jacent et l’attacher au pod. L’approvisionnement 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 des 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 le stockage de conteneurs Azure au lieu des pilotes CSI. Azure Container Storage s’intègre à Kubernetes, ce qui permet l’approvisionnement dynamique et automatique de volumes persistants. Azure Container Storage prend en charge les disques Azure, les disques éphémères et le SAN élastique Azure (préversion) comme stockage principal, offrant flexibilité et extensibilité pour les applications à état s'exécutant 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 le 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.

Pour les clusters utilisant Stockage Azure de conteneur, 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 de l'interface de stockage en conteneurs (CSI) , les classes de stockage supplémentaires suivantes sont créées :

Classe de stockage Description
managed-csi Utilise le stockage localement redondant (LRS) SSD Standard Azure 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. À 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 SSD Standard (ZRS) pour créer des disques managés.
managed-csi-premium Utilise le stockage localement redondant Azure Premium (LRS) pour créer un disque managé. La stratégie de récupération garantit à nouveau que le disque Azure sous-jacent est supprimé lorsque le volume persistant utilisé est supprimé. De même, cette classe de stockage permet d’étendre les 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 Azure Premium (ZRS) pour créer des disques managés.
azurefile-csi Utilise le stockage Azure 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 Azure 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 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 garantit que le conteneur de stockage Blob Azure sous-jacent est supprimé lorsque le volume persistant 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 d’BlobFuse. La stratégie de récupération garantit que le conteneur de stockage Blob Azure sous-jacent est supprimé lorsque le volume persistant 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 approprié dont vous avez besoin lors de la demande de volumes persistants.

important : à compter de Kubernetes version 1.21, AKS utilise les pilotes CSI par défaut et la migration CSI est activée. Bien que les volumes persistants intégrés à l'arborescence continuent de fonctionner, à partir de la version 1.26, AKS ne prendra plus en charge les volumes créés avec le pilote intégré à l'arborescence et le stockage approvisionné pour les fichiers et les disques.

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

À compter de Kubernetes version 1.29, lorsque 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 votre région choisie. Cette stratégie de redondance améliore 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 requête de volume persistant (PVC).

Vous pouvez créer une classe de stockage pour d’autres besoins à l’aide de kubectl. 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

N’oubliez pas qu’AKS rapproche les classes de stockage par défaut et remplace les modifications apportées à 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) sollicite un stockage avec une classe de stockage particulière, un mode d'accès et une taille spécifiques. 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 a été connecté au pod.

Diagramme des revendications de volume persistant dans un cluster Azure Kubernetes Services (AKS).

Une fois qu’une ressource de stockage disponible a été affectée au pod demandant le stockage, le volume persistant est lié à une revendication de volume persistant. Les volumes persistants sont associés aux demandes dans un mappage 1:1.

L’exemple de manifeste YAML suivant montre une demande de volume persistante qui utilise la managed-premium classe de stockage 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 être utilisée pour monter un volume à /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
...

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.

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 et recommandations relatives à la taille des disques de système d’exploitation éphémères sont disponibles dans la documentation machine virtuelle Azure. Voici quelques considérations générales sur le dimensionnement :

  • Si vous avez choisi d’utiliser la taille de machine virtuelle AKS par défaut Standard_DS2_v2 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 seulement le système d’exploitation éphémère, mais elle n'a qu'une taille de cache de 86 Gio. Cette configuration est 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 a 200 Gio d’espace de cache. Si vous ne spécifiez pas le type de disque du 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 n’a que 75 Go de stockage temporaire. Cette configuration est par défaut des disques de système d’exploitation managés 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 Standard_E4bds_v5 SKU avec un disque OS 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 du système d’exploitation, Par défaut, 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 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, 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 : Disque Azure, Azure Files, Azure NetApp Files ou Objets blob Azure.

Remarque

Selon la référence SKU de machine virtuelle que vous utilisez, le pilote CSI de disque Azure peut avoir une limite de volume par nœud. Pour certaines machines virtuelles hautes performances (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 déterminer le meilleur ajustement de votre charge de travail entre Azure Files et Azure NetApp Files, passez en revue les informations fournies dans l’article comparaison Azure Files et Azure NetApp Files.

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. À 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 permettent le provisionnement de volumes statiques et dynamiques. La stratégie de récupération vérifie que le disque est supprimé avec le volume persistant. Vous pouvez étendre le disque en modifiant la revendication du volume persistant.

Ces classes de stockage utilisent le service Azure Managed Disks avec un stockage localement redondant (LRS). LRS signifie que les données ont trois copies synchrones dans un seul lieu physique au sein d’une région primaire Azure. LRS est l’option de réplication la moins chère, mais elle n’offre 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 de stockage redondant interzone (ZRS). Le stockage redondant interzone (ZRS) réplique de manière synchrone votre disque managé Azure sur trois zones de disponibilité Azure dans la région que vous sélectionnez. Chaque zone de disponibilité est un emplacement physique distinct avec une alimentation indépendante, un refroidissement et un réseau. Les disques ZRS fournissent au moins 99,9999999999999999% (12 9) de durabilité sur une année donnée. Un disque managé ZRS peut être attaché par des machines virtuelles dans une autre zone de disponibilité . Les disques ZRS ne sont actuellement pas disponibles dans toutes les régions Azure. Pour plus d’informations sur les disques ZRS, consultez Zone Redundant Storage (ZRS) option for Azure Disks for high availability. En outre, pour atténuer le risque de perte de données, vous pouvez effectuer des sauvegardes ou des captures instantanées régulières des données de stockage disque à l’aide d'azure Kubernetes Service Backup ou de solutions tierces telles que Velero ou Sauvegarde Azure qui peuvent utiliser des technologies d’instantané intégrées.

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

Conseil

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

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

Disques Azure Premium SSD v2

Les disques Azure SSD Premium v2 offrent des charges de travail d’entreprise intenses en E/S, une latence de disque d’une taille inférieure à la milliseconde, ainsi qu’un débit et des IOPS élevés. Les performances (capacité, débit et IOPS) des disques SSD Premium v2 peuvent être configurées indépendamment à tout moment, ce qui permet à un plus grand nombre de scénarios d'être rentables tout en répondant aux besoins de performances. Pour plus d’informations sur la configuration d’un nouveau cluster AKS ou d’un cluster existant pour utiliser des disques Azure Premium SSD v2, veuillez consulter la section Utiliser les disques Azure Premium SSD v2 sur Azure Kubernetes Service.

Disque Ultra

Les disques de stockage Ultra correspondent à un niveau de disque managé Azure offrant un débit très important, un nombre élevé d’IOPS et un stockage sur disque à faible latence cohérent pour les machines virtuelles Azure. Les disques de stockage Ultra sont destinés aux charges de travail lourdes sur le plan des données et des transactions. Tout comme d’autres références SKU de Stockage sur disque et Amazon EBS, les disques de stockage Ultra sont montés pod après pod, et ne fournissent pas d’accès simultané.

Utilisez l’indicateur --enable-ultra-ssd pour activer les disques de stockage Ultra sur votre cluster AKS.

Si vous choisissez les disques de stockage Ultra, tenez compte de leurs limitations, et veillez à sélectionner une taille de machine virtuelle compatible. Les disques de stockage Ultra sont disponibles avec la réplication LRS (stockage localement redondant).

Apportez vos propres clés (BYOK)

Azure chiffre toutes les données dans un disque managé au repos. 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 à utiliser pour le chiffrement au repos des disques de système d’exploitation et des disques de données pour vos clusters AKS. Pour plus d’informations, consultez la section Apportez vos propres clés (BYOK) avec des disques gérés Azure dans Azure Kubernetes Service (AKS).

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 (Network File System) version 4.1 soutenu par Stockage Azure. Ce processus permet de disposer d’un stockage de type NAS, à l’image d’Amazon EFS. Comme pour la fonctionnalité Stockage sur disque, il existe deux options :

  • Stockage Standard Azure Files, qui repose sur des lecteurs de disque dur (HDD) classiques.
  • Stockage Premium Azure Files, qui repose sur des disques SSD hautes performances avec partage de fichiers. 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 :

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

Azure NetApp Files

Azure NetApp Files est un service de stockage de fichiers d’entreprise de haute performance, exécuté sur Azure, et supportant 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. Dans ce scénario, la création de volumes est externe à AKS. Les volumes sont créés à l’aide d’Azure CLI ou à partir du portail Azure, puis exposés à Kubernetes en créant un PersistentVolume. Les volumes Azure NetApp Files créés de manière statique ont de nombreuses limitations (par exemple, l’incapacité à être développée, la nécessité d’être surprovisionnés, etc.). Les volumes créés de manière statique ne sont pas recommandés pour la plupart des cas d’usage.
  • Créez des volumes Azure NetApp Files de façon dynamique, en procédant à l’orchestration via Kubernetes. Cette méthode est la méthode préférée pour créer plusieurs volumes directement via Kubernetes et est obtenue à l’aide de 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 Azure Kubernetes Service.

Stockage Blob Azure

Le pilote CSI (Azure Blob Storage Container Storage Interface) est un pilote conforme à la spécification CSI , utilisé par Azure Kubernetes Service (AKS) pour gérer le cycle de vie du stockage Blob Azure. 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.

En adoptant et en utilisant CSI, AKS peut désormais écrire, déployer et itérer des plug-ins pour exposer de nouveaux systèmes de stockage existants ou améliorer les systèmes de stockage existants dans Kubernetes. L’utilisation de pilotes CSI dans AKS évite d’avoir à toucher le code Kubernetes principal et d’attendre ses cycles de publication.

Lorsque vous montez Azure Blob Storage comme un système de fichiers dans un conteneur ou un pod, cela vous permet d'utiliser le stockage d'objets blob avec de nombreuses applications qui traitent de grandes quantités de données non structurées. Par exemple:

  • Données du fichier journal
  • Images, documents et diffusion en continu vidéo ou audio
  • Données de récupération d’urgence

Les données sur le stockage d’objets sont accessibles par les applications à l’aide du protocole BlobFuse ou NFS (Network File System) 3.0. Avant l’introduction du pilote CSI stockage Blob Azure, la seule option consiste à installer manuellement un pilote non pris en charge pour accéder au stockage Blob à partir de votre application s’exécutant sur AKS. Lorsqu'il est activé sur AKS, le pilote CSI de stockage Azure Blob offre deux classes de stockage intégrées : azureblob-fuse-premium et azureblob-nfs-premium.

Pour créer un cluster AKS avec prise en charge des pilotes CSI, consultez Pilotes CSI sur AKS. Pour en savoir plus sur les différences d’accès entre chacun des types de stockage Azure à l’aide du protocole NFS, consultez Comparer l’accès à Azure Files, Stockage Blob et Azure NetApp Files avec NFS.

Azure HPC Cache

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

Serveur NFS

La meilleure option pour un accès NFS partagé consiste à utiliser Azure Files ou Azure NetApp Files. Vous pouvez également créer un serveur NFS sur une machine virtuelle Azure qui exporte des volumes.

Sachez que cette option prend uniquement en charge le provisionnement statique. Vous devez provisionner les partages NFS manuellement sur le serveur, mais vous ne pouvez pas le faire automatiquement à partir d’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 êtes responsable de la gestion du serveur NFS, notamment des mises à jour de l’OS, de la haute disponibilité, des sauvegardes, de la reprise d’activité après sinistre et de la scalabilité.

Apportez vos propres clés (BYOK) avec des disques Azure

Stockage Azure chiffre toutes les données d’un compte de stockage 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 à utiliser pour le chiffrement au repos du système d’exploitation et des disques de données de vos clusters AKS. Pour plus d’informations, consultez l’article suivant :

Stockage de conteneur Azure

Azure Container Storage est un service cloud de gestion, de déploiement et d’orchestration de volumes conçu de manière native pour les conteneurs. Il s’intègre à Kubernetes, ce qui vous permet de provisionner de manière dynamique et automatique des volumes persistants en vue de stocker les données d’applications avec état s’exécutant sur des clusters Kubernetes.

Azure Container Storage utilise les offres Stockage Azure existantes pour le stockage de données effectif et propose une solution d’orchestration et de gestion de volumes spécialement conçue pour les conteneurs. Les options de stockage de support prises en charge incluent :

  • Disques Azure : Contrôle granulaire des SKUs et des configurations de stockage. Ils conviennent aux bases de données de niveau 1 et à usage général.
  • Disques éphémères : Utilisent les ressources de stockage local sur les nœuds AKS (NVMe ou SSD temporaire). Mieux adaptés aux applications sans exigence de durabilité des données ou avec support de réplication de données intégré. AKS découvre le stockage éphémère disponible sur les nœuds AKS et les acquiert pour le déploiement de volumes.
  • Azure Elastic SAN : Ressource entièrement gérée, approvisionnée à la demande. Convient aux bases de données à usage général, aux services de streaming et de messagerie, aux environnements CD/CI et à d’autres charges de travail de niveau 1/niveau 2. Si plusieurs clusters peuvent accéder simultanément à un même SAN, les volumes persistants ne peuvent être attachés qu’à un seul consommateur à la fois.

Jusqu'à présent, la fourniture d'un stockage cloud pour les conteneurs nécessitait l'utilisation de pilotes individuels d'interface de stockage de conteneurs (CSI) pour utiliser des services de stockage destinés aux charges de travail centrées sur l'infrastructure en tant que service (IaaS) et les faire fonctionner pour les conteneurs Cela avait pour effet de créer une surcharge opérationnelle et d’augmenter les risques de rencontrer des problèmes de disponibilité, scalabilité, performances, utilisation et coûts au niveau des applications.

Azure Container Storage est dérivé d’OpenEBS, solution open source offrant des capacités de stockage de conteneurs pour Kubernetes. En proposant une solution d’orchestration de volumes managée via des contrôleurs de stockage basés sur des microservices dans un environnement Kubernetes, Azure Container Storage permet un véritable stockage natif de conteneurs.

Le stockage de conteneurs Azure convient dans les 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. Cela inclut un disque éphémère qui fournit une latence extrêmement faible pour les charges de travail telles que Cassandra, ainsi qu’un SAN élastique Azure qui fournit des cibles iSCSI natives et approvisionnées partagées.

  • Simplifier la gestion des volumes avec Kubernetes : En proposant l’orchestration de volumes via le plan de contrôle Kubernetes, Azure Container Storage facilite le déploiement et la gestion de volumes dans Kubernetes, sans avoir besoin de faire la navette entre différents plans de contrôle.

  • Réduire le coût total de possession (TCO) : Améliorez l’efficacité économique en augmentant l’échelle des volumes persistants pris en charge par pod ou par nœud. Réduisez les ressources de stockage nécessaires au provisionnement en partageant dynamiquement les ressources de stockage. Notez que la prise en charge du scale-up pour le pool de stockage lui-même n’est pas assurée.

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

  • Scale-out rapide des pods avec état : Azure Container Storage monte les volumes persistants via des protocoles de stockage réseau par blocs (NVMe-oF ou iSCSI), ce qui permet d’attacher et de détacher rapidement les volumes persistants. Vous pouvez commencer petit et déployer seulement les ressources nécessaires tout en veillant à ce que vos applications ne soient pas sous-alimentées ou perturbées, que ce soit pendant l’initialisation ou en production. La résilience des applications est améliorée grâce à la regénération (« respawn ») de pods sur le cluster, ce qui exige un déplacement rapide des volumes persistants. À 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.

  • Niveau de performance amélioré pour les charges de travail avec état : Azure Container Storage autorise un plus haut niveau de performance en lecture et offre des performances en écriture comparables à celles des disques en utilisant NVMe-oF via RDMA. Cela permet aux clients de répondre de façon économique aux exigences de performances de diverses charges de travail de conteneurs (niveau 1, intensives en E/S, usage général, sensibles au débit, développement/test, etc.). Écourtez la durée d’attachement/détachement des volumes persistants et réduisez le temps de basculement des pods.

  • Orchestration 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 de commandes kubectl sans changer d’ensemble d’outils pour les différentes opérations de plan de contrôle.

Solutions tierces

Tout comme Amazon EKS, AKS est une implémentation de Kubernetes, ce qui vous permet d’intégrer des solutions de stockage Kubernetes tierces. Voici quelques exemples de solutions de stockage tierces pour Kubernetes :

  • Rook transforme les systèmes de stockage distribués en services de stockage auto-gérés en automatisant les tâches de l’administrateur de stockage. 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 scalable avec des interfaces d’objet, de bloc et de fichier provenant 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. Ainsi, vous pouvez disposer d’une interface cohérente et portable pour vos données et vos 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 propose un stockage de précision à l’aide de conteneurs, une reprise d’activité après sinistre, 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 des performances, gérer de grandes quantités de données et simplifier l’administration.
  • Ondat fournit une couche de stockage cohérente sur toutes les plateformes. 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 1.21 et les versions ultérieures, les classes de stockage AKS et Amazon EKS utilisent uniquement des pilotes CSI (Container Storage Interface) par défaut.

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

Service ReadWriteOnce ReadOnlyMany ReadWriteMany
Disques Azure X
Azure Files X X X
Azure NetApp Files X X X
Serveur NFS X X X
Azure HPC Cache X X X

Provisionnement dynamique ou 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 éviter d’avoir des disques inutilisés quand 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 d'Azure Storage, utilisez les réservations Azure. Veillez à vérifier les services qui prennent en charge les réservations Azure. Consultez également Gestion des coûts pour un cluster Kubernetes.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

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

Étapes suivantes