Comme d'autres composants et charges de travail qui s'exécutent dans des espaces de noms de Superviseur, les clusters Tanzu Kubernetes Grid nécessitent un stockage persistant.

Stratégies de stockage pour le cluster Tanzu Kubernetes Grid

Pour fournir des ressources de stockage persistantes aux clusters Tanzu Kubernetes Grid, un administrateur vSphere configure des stratégies de stockage qui décrivent différentes exigences de stockage. L'administrateur ajoute ensuite les stratégies de stockage à l'espace de noms dans lequel le cluster Tanzu Kubernetes Grid est déployé. Les stratégies de stockage visibles pour l'espace de noms déterminent les banques de données auxquelles l'espace de noms peut accéder et qu'il peut utiliser pour le stockage persistant. Elles déterminent la manière dont les nœuds de cluster et les charges de travail sont placés dans l'environnement de stockage vSphere.

En fonction des stratégies de stockage attribuées à l'espace de noms, vSphere IaaS control plane crée des classes de stockage Kubernetes correspondantes qui s'affichent automatiquement dans l'espace de noms. Elles sont également propagées vers le cluster Tanzu Kubernetes Grid sur cet espace de noms.

Dans le cluster Tanzu Kubernetes Grid, les classes de stockage s'affichent en deux éditions, l'une avec Immediate et l'autre avec le mode de liaison WaitForFirstConsumer. L'édition choisie par l'équipe DevOps dépend de ses exigences.

Pour plus d'informations sur les classes de stockage dans les clusters Tanzu Kubernetes Grid, reportez-vous à Utilisation de classes de stockage pour des volumes persistants.

Comment les clusters Tanzu Kubernetes Grid s'intègrent-ils au stockage vSphere ?

Pour s'intégrer au Superviseur et au stockage vSphere, les clusters Tanzu Kubernetes Grid utilisent Paravirtual CSI (pvCSI).

pvCSI est la version du pilote vSphere CNS-CSI modifiée pour les clusters Tanzu Kubernetes Grid. pvCSI réside dans le cluster Tanzu Kubernetes Grid et est responsable de toutes les demandes liées au stockage provenant du cluster Tanzu Kubernetes Grid. Les demandes sont transmises au CNS-CSI, qui les propage ensuite dans vCenter Server. Par conséquent, pvCSI ne dispose pas d'une communication directe avec le composant CNS, mais s'appuie plutôt sur CNS-CSI pour toutes les opérations de provisionnement de stockage. Contrairement à CNS-CSI, pvCSI ne nécessite pas d'informations d'identification d'infrastructure. Il est configuré avec un compte de service dans l'espace de noms.

pvCSI est un composant des clusters TKG, CNS-CSI est un composant du Superviseur et CNS est un composant de vCenter Server.

Pour en savoir plus sur les composants Superviseur utilisés pour l'intégration au stockage vSphere, reportez-vous à la section Stockage persistant pour les charges de travail.

Création d'un volume persistant

Les éléments suivants illustrent le mode d'interaction des différents composants lorsqu'un ingénieur DevOps effectue une opération liée au stockage au sein du cluster Tanzu Kubernetes Grid. Par exemple, lorsqu'il crée une réclamation de volume persistant (PVC).

L'ingénieur DevOps crée un PVC à l'aide de la ligne de commande sur le cluster Tanzu Kubernetes Grid. Cette action génère un PVC correspondant sur le Superviseur et déclenche CNS-CSI. CNS-CSI appelle l'API de création de volumes de CNS.

Trois composants interagissent pour créer un volume persistant.

Après la création réussie d'un volume, l'opération se propage de nouveau au Superviseur vers le cluster Tanzu Kubernetes Grid. Suite à cette propagation, les utilisateurs peuvent voir le volume persistant et la réclamation de volume persistant dans l'état lié du Superviseur. Ils voient également le volume persistant et la réclamation de volume persistant dans l'état lié du cluster Tanzu Kubernetes Grid.

Fonctionnalité prise en charge par pvCSI

Le composant pvCSI qui s'exécute dans le cluster Tanzu Kubernetes Grid prend en charge un certain nombre de fonctionnalités de stockage vSphere et Kubernetes.

Fonctionnalités prises en charge pvCSI avec un cluster Tanzu Kubernetes Grid
Prise en charge du stockage cloud natif dans vSphere Client Oui
Amélioration de la santé des objets dans vSphere Client Oui (vSAN uniquement)
Volume persistant de bloc dynamique (mode d'accès ReadWriteOnce) Oui
Volume persistant de fichier dynamique (mode d'accès ReadWriteMany) Oui (avec services de fichiers vSAN)
Banque de données vSphere VMFS/NFS/vSAN/vVols
Volume persistant statique Oui
Chiffrement Non
Extension du volume hors ligne Oui
Expansion du volume en ligne Oui
Topologie du volume et zones Oui
Instances multiples du plan de contrôle Kubernetes Oui
WaitForFirstConsumer Oui
VolumeHealth Oui
Storage vMotion avec des volumes persistants Non