Comprendre les volumes persistants et les PVC dans Kubernetes et OpenEBS

Présentation : qu’est-ce qu’un volume dans Kubernetes ?

Dans Kubernetes, les abstractions de volume sont utilisées pour fournir une API qui fait abstraction de l’implémentation physique du stockage de la façon dont elle est consommée par les ressources de l’application. Les conteneurs exécutés sur Kubernetes ne stockent pas les données qu’ils créent ou traitent. Un volume fournit essentiellement un répertoire de stockage qui peut être utilisé par des conteneurs exécutés dans des POD pour stocker et partager des données.

Kubernetes prend en charge deux principaux types de volumes :

1. Volumes éphémères – Ceux-ci sont utilisés pour les applications qui ont besoin de stockage mais n’ont pas besoin d’accéder aux données après un redémarrage. Les volumes éphémères ne durent que la durée de vie de leurs POD et sont supprimés lorsque le POD s’arrête. Les volumes éphémères sont applicables aux applications à faible latence où une taille de mémoire limitée peut avoir un impact sur les performances. Kubernetes permet différents types de volumes éphémères pour différentes utilisations, notamment :

• VideDir
• Secrets, ConfigMaps et downAPI
• CSI volumes éphémères
• Volumes éphémères génériques

2. Volumes persistants – Il s’agit d’un objet API qui représente une implémentation abstraite du stockage physique à utiliser par les POD, mais ils durent au-delà de la durée de vie d’un POD. Le PV est une partie du stockage physique auquel les POD s’attachent afin qu’ils puissent stocker leurs données qui sont disponibles même après le redémarrage d’un conteneur.

Dans cet article, nous explorons en détail les volumes persistants et le but qu’ils résolvent dans un écosystème Kubernetes.

Plugins de volume

Kubernetes a implémenté la Container Storage Interface (CSI) pour standardiser la création de plugins tiers pour la mise en œuvre du stockage. Kubernetes utilise ces plug-ins pour exposer le stockage physique sur les nœuds aux Kubelets exécutés dans le plan de données d’un cluster. De cette façon, les abstractions Kubernetes peuvent fournir des ressources de stockage aux POD et aux conteneurs. Le système de plug-in activé par le CSI permet également aux fournisseurs d’ajouter des systèmes de stockage à Kubernetes sans avoir à modifier le code et les binaires de base de Kubernetes.

Certains des plugins CSI les plus populaires pour Kubernetes incluent :

• Stockage de blocs élastiques AWS
• Disque Azure
• BeeGFS
• CephFS
• Dell EMC PowerMax
• Disque persistant GCE
• Magasin de fichiers Google Cloud
• GlusterFS
• Stockage Huawei CSI
• CSI HyperV
• Stockage par blocs IBM
• OpenEBS
• Portworx
• CSI de stockage pur

La liste complète des plugins de volume pris en charge dans Kubernetes est disponible ici.

Stockage persistant dans Kubernetes

Une fois qu’un plugin CSI a été configuré et s’exécute dans Kubernetes, les ressources et les utilisateurs peuvent consommer des volumes à l’aide des objets de l’API de stockage Kubernetes : Volumes persistants, réclamations de volumes persistants, et Classes de stockage. Cette section explore ces objets API et leur rôle dans la fourniture d’un stockage persistant pour les conteneurs dans Kubernetes.

Volumes persistants

Un volume persistant est un espace de stockage disponible pour le cluster. Le PV expose les systèmes de stockage d’objets, de fichiers et de blocs en capturant les détails de son protocole de mise en œuvre, que ce soit iSCSI (SCSI sur Internet), NFS, ou tout système de stockage proposé par des fournisseurs et des fournisseurs de cloud spécifiques. Le volume persistant a son cycle de vie indépendant de tout POD le consommant. Cela signifie qu’un PV conserve les données à utiliser par les conteneurs tout au long du cycle de vie de l’application.

Un PV est un objet API Kubernetes avec des configurations similaires à :

apiVersion: v1
kind: PersistentVolume
metadata:
   name: darwin-pv
   labels:
      type: local
spec:
   capacity: 
      storage: 
   accessModes:
      - ReadWriteOnce 
      hostPath:
         path: "/tmp/data01"

Réclamations de volume persistantes

Lorsqu’un utilisateur demande un stockage PV, il utilise une revendication de volume persistant en tant qu’objet Kubernetes qui demande des exigences de stockage spécifiques telles que les modes d’accès et la taille. Un PVC est créé en appliquant un fichier de configuration YAML au cluster avec des spécifications similaires à :

apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
  name: darwin-pvc
spec: 
  accessModes: 
    - ReadWriteOnce
  resources: 
    requests: 
      storage: 200Gi
  storageClassName: darwin-dev-disk

Les POD sont attachés aux PVC en le déclarant comme un volumes spec dans le fichier de configuration des POD :

volumes: 
    - 
      name: app-data
      persistentVolumeClaim: 
        claimName: darwin-pvc

Une fois qu’un POD est lié à un PVC, le PVC l’attache aux PV appropriés en fonction de la taille de disque et des modes d’accès spécifiés dans le fichier de configuration.

Provisionnement statique ou dynamique

Les PV peuvent être provisionnés de manière statique ou dynamique. Dans approvisionnement PV statique, l’objet de stockage est d’abord créé et configuré sur l’hôte, puis est mis à disposition du cluster. Dans ce cas, les POD sont attachés à un PV qui pointe vers une partie spécifique de cet objet de stockage.

Si le PV est provisionné dynamiquement, une classe de stockage L’objet est utilisé pour définir différentes caractéristiques d’implémentation de stockage pointant vers un système de stockage physique. L’objet de classe de stockage demande une partie de l’objet de stockage puis crée un volume correspondant aux spécifications de son fichier de configuration. Les classes de stockage permettent l’allocation automatique et dynamique des PV aux objets Kubernetes.

Le fichier de configuration d’un objet de classe de stockage ressemblerait à :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: darwin-dev-disk
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

Le cycle de vie des PV et des PVC

Les PVC représentent des demandes pour une ressource PV. L’interaction entre les deux objets suit le schéma suivant :

1. Approvisionnement – C’est là que le système de stockage physique est disponible pour être consommé par les utilisateurs d’un cluster. Le provisionnement peut être statique ou dynamique.
2. Obligatoire – Le processus d’appariement d’un PVC avec un PV approprié, puis de les lier ensemble.
3. À l’aide de – Le processus par lequel les POD consomment un volume.
4. Récupérer – Lorsqu’un utilisateur a fini de consommer un volume, les objets de liaison sont supprimés, permettant la récupération de la ressource de stockage. Certaines politiques de récupération prises en charge incluent :

Certains PV peuvent être réservés pour des PV spécifiques à l’aide d’une procédure de pré-liaison. Cela signifie que le PVC sera toujours lié à un PV, que ses POD exécutent ou non une application.

PV et PVC dans les systèmes de stockage monolithiques

Dans les systèmes de stockage traditionnels, Kubernetes s’interface avec un logiciel de stockage monolithique qui virtualise et agrège un certain nombre de périphériques de stockage. Ces périphériques peuvent être soit un stockage SAN, des serveurs bare metal ou des solutions de stockage par blocs basées sur le cloud. Le logiciel s’interface avec les plug-ins CSI qui gèrent l’accès au stockage à l’aide de PV, PVC et classes de stockage.

Stockage attaché au conteneur (CAS) et volumes persistants

CAS permet aux organisations de tirer parti de la flexibilité et de l’évolutivité des plateformes cloud natives pour étendre les fonctionnalités des abstractions de volume. Dans CAS, la solution de stockage est déployée sous forme de microservices dans des conteneurs pouvant être gérés par un orchestrateur tel que Kubernetes. Le plan de données du cluster CAS comprend des réplicas POD exécutant les conteneurs qui provisionnent les volumes et permettent l’accès au stockage. Le plan de contrôle d’un cluster CAS comprend les stratégies, les contrôleurs de stockage et les configurations du plan de données.

Volumes PV locaux OpenEBS

OpenEBS permet le provisionnement de PV dynamiques pour les volumes locaux dans Kubernetes. Un volume local est un élément de stockage en cluster qui n’est disponible qu’à partir d’un seul nœud, tel qu’un ordinateur personnel (PC) ou une machine virtuelle (VM). Les volumes locaux sont utilisés dans des applications qui peuvent tolérer l’indisponibilité lorsqu’un nœud n’est pas sain et utilisent des répertoires, des partitions et des disques locaux pour exposer les ressources de stockage à un cluster. Cela rend le plug-in idéal pour les besoins locaux qui nécessitent une gestion et une surveillance dynamiques et pour les applications hautes performances qui doivent auto-gérer la réplication et la sécurité des données. Voici quelques cas d’utilisation pour les volumes locaux :

• Bases de données répliquées
• Charges de travail Edge s’exécutant sur des clusters à nœud unique
• Charges de travail avec état avec leur propre configuration HA

Sommaire

Les volumes persistants exposent les implémentations de stockage physique aux clusters Kubernetes afin que les POD puissent stocker et partager des données. Avec les PV, les données générées et stockées par des conteneurs immuables peuvent être conservées pour une utilisation tout au long du cycle de vie d’une application.

Cet article a exploré les concepts nécessaires pour comprendre le stockage persistant pour Kubernetes, en se concentrant principalement sur les PV et les PVC. Container Attached Storage (CAS) étend les fonctionnalités des volumes en s’appuyant sur les microservices et l’orchestration des conteneurs. CAS permet la création d’une infrastructure de stockage flexible, granulaire et hautement disponible qui est native du cloud.