Il existe plusieurs façons de configurer le stockage des données pour les applications exécutées sur un cluster Kubernetes. Certains d’entre eux sont déjà obsolètes, d’autres sont apparus assez récemment. Dans cet article, nous examinerons le concept de trois options de connexion des systèmes de stockage, dont la plus récente : la connexion via l'interface de stockage de conteneurs.
Méthode 1 : spécifiez PV dans le manifeste du pod
Un manifeste typique décrivant un pod dans un cluster Kubernetes :
Les parties du manifeste qui décrivent quel volume est connecté et où sont surlignées en couleur.
Dans la section volumeMontages indiquez les points de montage (mountPath) - dans quel répertoire à l'intérieur du conteneur le volume permanent sera monté, ainsi que le nom du volume.
Dans la section x répertorie tous les volumes utilisés dans le pod. Précisez le nom de chaque volume, ainsi que le type (dans notre cas : awsElasticBlockStore) et les paramètres de connexion. Les paramètres répertoriés dans le manifeste dépendent du type de volume.
Le même volume peut être monté simultanément dans plusieurs conteneurs pod. De cette façon, différents processus de candidature peuvent accéder aux mêmes données.
Cette méthode de connexion a été inventée au tout début, alors que Kubernetes n’en était qu’à ses balbutiements, et aujourd’hui, la méthode est dépassée.
Il y a plusieurs problèmes lors de son utilisation :
- tous les volumes doivent être créés manuellement ; Kubernetes ne peut rien créer pour nous ;
- les paramètres d'accès pour chaque volume sont uniques et doivent être spécifiés dans les manifestes de tous les pods qui utilisent le volume ;
- pour modifier le système de stockage (par exemple, passer d'AWS à Google Cloud), vous devez modifier les paramètres et le type de volumes montés dans tous les manifestes.
Tout cela est très gênant, donc en réalité cette méthode est utilisée pour connecter uniquement certains types spéciaux de volumes : configMap, secret, emptyDir, hostPath :
-
configMap et secret sont des volumes de service qui vous permettent de créer un volume avec des fichiers provenant des manifestes Kubernetes dans le conteneur.
-
emptyDir est un volume temporaire, créé uniquement pour la durée de vie du pod. Pratique à utiliser pour tester ou stocker des données temporaires. Lorsqu'un pod est supprimé, le volume emptyDir est également supprimé et toutes les données sont perdues.
-
hostPath - vous permet de monter n'importe quel répertoire sur le disque local du serveur sur lequel l'application s'exécute à l'intérieur du conteneur avec l'application, y compris /etc/kubernetes. Il s'agit d'une fonctionnalité dangereuse, c'est pourquoi les politiques de sécurité interdisent généralement l'utilisation de volumes de ce type. Sinon, l'application d'un attaquant pourra monter le répertoire HTC Kubernetes dans son conteneur et voler tous les certificats du cluster. En règle générale, les volumes hostPath ne peuvent être utilisés que par les applications système qui s'exécutent dans l'espace de noms kube-system.
sont donnés dans la documentation.
Méthode 2. Connexion aux foyers SC/PVC/PV
Une méthode de connexion alternative est le concept de classe Storage, PersistentVolumeClaim, PersistentVolume.
Classe de stockage stocke les paramètres de connexion au système de stockage de données.
Réclamation de volume persistant décrit les exigences relatives aux besoins de l'application.
Volume persistant stocke les paramètres d’accès et l’état du volume.
L'essence de l'idée : dans le manifeste du pod, ils indiquent un volume de type PersistentVolumeClaim et indiquent le nom de cette entité dans le paramètre ClaimName.
Le manifeste PersistentVolumeClaim décrit les exigences relatives au volume de données requis par l'application. Y compris:
- taille du disque ;
- méthode d'accès : ReadWriteOnce ou ReadWriteMany ;
- lien vers la classe de stockage - dans quel système de stockage de données nous souhaitons créer le volume.
Le manifeste de la classe Storage stocke le type et les paramètres de la connexion au système de stockage. Le cubelet en a besoin pour monter le volume sur son nœud.
Les manifestes PersistentVolume indiquent la classe de stockage et les paramètres d'accès pour un volume spécifique (ID de volume, chemin, etc.).
Lors de la création d'un PVC, Kubernetes examine la taille du volume et la classe de stockage requises, et sélectionne un PersistentVolume gratuit.
Si de tels PV ne sont pas disponibles, Kubernetes peut lancer un programme spécial - Provisioner (son nom est indiqué dans la classe Storage). Ce programme se connecte au système de stockage, crée un volume de la taille requise, reçoit un identifiant et crée un manifeste PersistentVolume dans le cluster Kubernetes, qui est associé à PersistentVolumeClaim.
Tout cet ensemble d'abstractions vous permet de supprimer les informations sur le système de stockage avec lequel l'application travaille, du niveau du manifeste de l'application au niveau de l'administration.
Tous les paramètres de connexion au système de stockage de données se trouvent dans la classe Storage, dont les administrateurs de cluster sont responsables. Tout ce que vous devez faire lors du passage d'AWS vers Google Cloud est de changer le nom de la classe de stockage en PVC dans les manifestes d'application. Le volume de persistance pour le stockage des données sera créé automatiquement dans le cluster à l'aide du programme Provisioner.
Méthode 3 : Interface de stockage de conteneurs
Tout le code qui interagit avec divers systèmes de stockage fait partie du cœur de Kubernetes. La publication de corrections de bogues ou de nouvelles fonctionnalités est liée aux nouvelles versions ; le code doit être modifié pour toutes les versions prises en charge de Kubernetes. Tout cela est difficile à maintenir et à ajouter de nouvelles fonctionnalités.
Pour résoudre le problème, les développeurs de Cloud Foundry, Kubernetes, Mesos et Docker ont créé la Container Storage Interface (CSI) - une interface unifiée simple qui décrit l'interaction du système de gestion de conteneurs et d'un pilote spécial (pilote CSI) qui fonctionne avec un spécifique système de stockage. Tout le code destiné à interagir avec les systèmes de stockage a été déplacé du noyau Kubernetes vers un système distinct.
.
En règle générale, le pilote CSI se compose de deux composants : le plug-in Node et le plug-in Controller.
Node Plugin s'exécute sur chaque nœud et est responsable du montage des volumes et de l'exécution des opérations sur ceux-ci. Le plugin Controller interagit avec le système de stockage : crée ou supprime des volumes, attribue des droits d'accès, etc.
Pour l'instant, les anciens pilotes restent dans le noyau Kubernetes, mais leur utilisation n'est plus recommandée et il est conseillé à chacun d'installer le pilote CSI spécifiquement pour le système avec lequel ils travailleront.
L'innovation peut effrayer ceux qui sont déjà habitués à mettre en place un stockage de données via la classe Storage, mais en réalité rien de terrible ne s'est produit. Pour les programmeurs, rien ne change vraiment : ils ont travaillé uniquement avec le nom de classe Storage et continueront de le faire. Pour les administrateurs, l'installation du Helm Chart a été ajoutée et la structure des paramètres a été modifiée. Si auparavant les paramètres étaient saisis directement dans la classe Storage, ils doivent désormais être définis d'abord dans le helm chart, puis dans la classe Storage. Si vous y regardez bien, rien de grave ne s'est produit.
Prenons un exemple pour examiner les avantages que vous pouvez obtenir en passant à la connexion de systèmes de stockage Ceph à l'aide du pilote CSI.
Lorsque vous travaillez avec Ceph, le plugin CSI offre plus d'options pour travailler avec les systèmes de stockage que les pilotes intégrés.
- Création de disque dynamique. Généralement, les disques RBD sont utilisés uniquement en mode RWO, mais CSI pour Ceph permet de les utiliser en mode RWX. Plusieurs pods sur différents nœuds peuvent monter le même disque RDB sur leurs nœuds et travailler avec eux en parallèle. Pour être honnête, tout n'est pas si brillant - ce disque ne peut être connecté qu'en tant que périphérique bloc, ce qui signifie que vous devrez adapter l'application pour qu'elle fonctionne avec lui en mode d'accès multiple.
- Création d'instantanés. Dans un cluster Kubernetes, vous pouvez créer un manifeste avec l'obligation de créer un instantané. Le plugin CSI le verra et prendra un instantané du disque. Sur cette base, vous pouvez effectuer soit une sauvegarde, soit une copie de PersistentVolume.
- Augmentation de la taille du disque sur le stockage et PersistentVolume dans un cluster Kubernetes.
- Quotas. Les pilotes CephFS intégrés à Kubernetes ne prennent pas en charge les quotas, mais les nouveaux plugins CSI avec la dernière version de Ceph Nautilus peuvent activer les quotas sur les partitions CephFS.
- Métriques. Le plugin CSI peut fournir à Prometheus diverses mesures sur les volumes connectés, les communications en cours, etc.
- Conscient de la topologie. Permet de spécifier dans les manifestes comment le cluster est géographiquement distribué et d'éviter de connecter un système de stockage situé à Amsterdam à des pods exécutés à Londres.
Comment connecter Ceph à un cluster Kubernetes via CSI, voir . Vous pouvez également vous abonner à , qui sera lancé le 15 octobre.
Auteur de l'article : Sergey Bondarev, architecte en exercice chez Southbridge, administrateur certifié Kubernetes, l'un des développeurs de kubespray.
Un petit Post Scriptum non pas pour la publicité, mais pour le bénéfice...
Le PS Sergueï Bondarev anime deux cours intensifs : mis à jour 28-30 septembre et avancé 14-16 octobre.
Source: habr.com