Options de stockage pour les applications dans AKS activées par Azure Arc

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

Les applications qui s’exécutent dans des déploiements AKS à l’aide d’Azure Kubernetes Service activé par Azure Arc peuvent avoir besoin de stocker et de récupérer des données. Pour certaines charges de travail d’application, les données peuvent utiliser un stockage local et rapide sur un nœud inutile lorsque les pods sont supprimés (Kubernetes utilise des pods pour exécuter une instance d’application).

D’autres charges de travail peuvent nécessiter un stockage qui persiste sur des volumes de données plus réguliers. Plusieurs pods peuvent avoir besoin de partager les mêmes volumes de données ou de détacher des volumes de données si le pod est replanifié sur un autre nœud. En outre, vous pouvez avoir besoin d’une option de stockage si les pods contiennent des données sensibles ou des informations de configuration d’application.

Cet article présente les concepts fondamentaux qui fournissent un stockage à vos applications dans AKS Arc, notamment :

• Volumes
• Volumes persistants
• Classes de stockage
• Revendications de volumes persistants

Volumes

Les applications doivent souvent être en mesure de stocker et de récupérer des données. Comme Kubernetes traite normalement les pods individuels en tant que ressources temporaires jetables, les applications disposent de différentes méthodes pour utiliser et conserver les données. Un volume représente un moyen de stocker, de récupérer et de conserver des données entre les pods et tout au long du cycle de vie de l’application.

Dans Kubernetes, les volumes peuvent représenter plus qu’une simple tradition sur laquelle les informations sont stockées et récupérées. Les volumes Kubernetes peuvent également servir à insérer des données dans un pod en vue de leur utilisation par les conteneurs. Les types de volumes Kubernetes courants incluent :

• emptyDir : ce volume est 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 sur ce type de volume sont conservées jusqu’à la fin de la durée de vie du pod ; quand le pod est supprimé, le volume est également 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 : ce volume est utilisé pour inclure des données sensibles, telles que des mots de passe, dans des pods. Tout d’abord, vous créez un secret à l’aide de l’API Kubernetes. Quand vous définissez votre pod ou déploiement, vous pouvez exiger un secret spécifique. Les secrets sont fournis uniquement aux nœuds avec un pod planifié qui l’exige, et le secret est stocké dans tmpfs, et non écrit sur le disque. Lorsque le dernier pod sur un nœud qui requiert une clé secrète est supprimé, le secret est supprimé des 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 : ce type de volume est utilisé pour injecter des propriétés de paires clé-valeur dans des pods, telles que des informations de configuration d’application. Au lieu de définir des informations de configuration d’application au sein d’une image conteneur, vous pouvez les définir en tant que ressource Kubernetes pouvant être facilement mise à jour et appliquée à de nouvelles instances de pods au fur et à mesure de leur déploiement. Comme pour utiliser un secret, vous créez d’abord un ConfigMap à l’aide de l’API Kubernetes. Ce ConfigMap peut ensuite être demandé lorsque vous définissez un pod ou un déploiement. Les configMaps sont stockés dans un espace de noms donné et sont accessibles uniquement par des pods dans le même espace de noms.

Volumes persistants

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

Vous pouvez utiliser des volumes de disque AKS sauvegardés par VHDX montés en tant que ReadWriteOnce et accessibles à un seul nœud à la fois. Vous pouvez également utiliser des volumes de fichiers AKS sauvegardés par des partages de fichiers SMB ou NFS. Ils sont montés en tant que ReadWriteMany et sont accessibles à plusieurs nœuds à la fois.

Un administrateur de cluster peut créer statiquement un volume persistant, ou le volume peut être créé dynamiquement par le serveur d’API Kubernetes. Si un pod est planifié et demande un stockage qui n’est pas disponible, Kubernetes peut créer le fichier VHDX sous-jacent et l’attacher au pod. L'approvisionnement dynamique utilise une classe de stockage (StorageClass) pour identifier le type de stockage à créer.

Classes de stockage

Pour définir différents niveaux (et emplacement) de stockage, vous pouvez créer une classe De stockage. StorageClass définit également la classe de récupération. Cette méthode de récupérationPolicy contrôle le comportement de la ressource de stockage sous-jacente lorsque le pod est supprimé et que le volume persistant peut ne plus être requis. La ressource de stockage sous-jacente peut être supprimée ou conservée en vue de son utilisation par un pod futur.

Dans AKS Arc, la classe de stockage par défaut est automatiquement créée et utilise csv pour créer des volumes sauvegardés VHDX. La stratégie de récupération veille à ce que le VHDX 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. Ainsi, il vous suffit de mettre à jour la revendication de volume persistant avec la nouvelle taille.

Si aucune classe de stockage n’est spécifiée pour un volume persistant, la classe de stockage par défaut est utilisée. Lors de la demande de volumes persistants, assurez-vous qu’ils utilisent le stockage approprié. Vous pouvez créer une Classe de stockage pour des besoins supplémentaires.

Revendications de volume persistant

Un PersistentVolumeClaim demande le stockage ReadWriteOnce ou ReadWriteMany d’une classe de stockage et d’une taille particulières. Le serveur d’API Kubernetes peut provisionner dynamiquement la ressource de stockage sous-jacente dans AKS Arc s’il n’existe aucune ressource existante pour 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.

Un PersistentVolume est lié à un PersistentVolumeClaim une fois qu’une ressource de stockage disponible est affectée au pod qui le demande. Les volumes persistants sont liés aux revendications par un mappage 1 à 1.

L’exemple de manifeste YAML suivant montre une revendication de volume persistant qui utilise la classe de stockage par défaut et demande un disque 5Gi :

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: aks-hci-vhdx 
spec: 
  accessModes: 
  - ReadWriteOnce 
  storageClassName: default 
  resources: 
    requests: 
      storage: 5Gi 

Lorsque vous créez une définition de pod, vous spécifiez la revendication de volume persistant pour demander le stockage souhaité. Vous spécifiez également la volumeMount valeur de vos applications pour lire et é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  :

kind: Pod 
apiVersion: v1 
metadata: 
  name: nginx 
spec: 
  containers: 
    - name: myfrontend 
      image: k8s.gcr.io/nginx 
      volumeMounts: 
      - mountPath: "/mnt/aks-hci" 
        name: volume
  nodeSelector:
      kubernetes.io/os: linux
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: aks-hci-vhdx 

L’exemple suivant montre comment monter un volume dans un conteneur Windows et spécifier la lettre de lecteur et le chemin d’accès :

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

Étapes suivantes

• Utilisez les pilotes CSI (Local Disk Container Storage Interface) AKS sur disque local Azure.