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

  • Article

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 de Azure Kubernetes Service activés 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 rattacher des volumes de données si le pod est replanifié sur un autre nœud. En outre, vous aurez peut-être besoin d’une option de stockage si les pods contiennent des données sensibles ou des informations de configuration d’application.

Image de stockage architectural montrant un master de cluster et un nœud.

Cet article présente les concepts de base qui fournissent du 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 permet de stocker, de récupérer et de conserver les données des différents pods tout au long du cycle de vie des applications.

Dans Kubernetes, les volumes peuvent représenter plus qu’un simple élément traditionnel sur lequel 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 en a besoin, et le secret est stocké dans tmpfs, et non écrit sur le disque. Lorsque le dernier pod d’un nœud qui nécessite un secret est supprimé, celui-ci 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 les pods du 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 soutenus par VHDX qui sont montés en tant que ReadWriteOnce et qui sont accessibles à un seul nœud à la fois. Vous pouvez également utiliser des volumes de fichiers AKS soutenus 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 StorageClass. StorageClass définit également la classe de récupération. Cette propriété reclaimPolicy contrôle le comportement de la ressource de stockage sous-jacente lorsque le pod est supprimé et que le volume persistant n’est peut-être plus nécessaire. 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 créée automatiquement et utilise CSV pour créer des volumes 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 StorageClass par défaut est utilisée. Lorsque vous demandez des volumes persistants, assurez-vous qu’ils utilisent le stockage approprié. Vous pouvez créer un StorageClass pour des besoins supplémentaires.

Revendications de volume persistant

Un persistentVolumeClaim demande le stockage ReadWriteOnce ou ReadWriteMany d’une taille et d’une classe de stockage 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 répondre à la revendication en fonction de la storageClasse 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 la 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 le StorageClass 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

Quand vous créez une définition de pod, la revendication de volume persistant est spécifiée pour demander le stockage souhaité. Vous spécifiez également le volumeMount pour que vos applications lisent et écrivent des données. L’exemple de manifeste YAML suivant illustre l’utilisation de la revendication de volume persistant précédente pour monter un volume sur /mnt/aks-hci :

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 :

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

Étapes suivantes