Rook — un stockage de données « auto-service » pour Kubernetes

Le 29 janvier, le comité technique de l'organisation CNCF (Cloud Native Computing Foundation), qui soutient Kubernetes, Prometheus et d'autres produits open source dans le monde des conteneurs et du cloud native, a annoncé a approuvé le projet Rook dans ses rangs. Une excellente occasion de se familiariser davantage avec ce « chef d'orchestre des systèmes de stockage distribué dans Kubernetes ».

Qu'est-ce que Rook ?

Rook — c'est un logiciel écrit en Go (est distribué sous licence libre Apache License 2.0) conçu pour conférer aux systèmes de stockage des fonctionnalités automatisées qui les rendent autonomes, capables de s'adapter et auto-réparateurs.Pour cela, Rook automatise (pour les systèmes de stockage utilisés dans un environnement Kubernetes) : le déploiement, le bootstrapping, la configuration, le provisioning, la mise à l'échelle, les mises à jour, les migrations, la récupération après sinistre, la surveillance et la gestion des ressources.

Le projet est en phase alpha et se spécialise dans l'orchestration d'un système de stockage distribué Ceph dans des clusters Kubernetes. Les auteurs déclarent également leur intention de soutenir d'autres systèmes de stockage, mais cela ne se produira pas dans les prochaines versions.

Composants et dispositif technique

Au cœur du fonctionnement de Rook dans Kubernetes se trouve un opérateur spécial (nous avons parlé des Kubernetes Operators dans cet article), automatisant la configuration du stockage et implémentant sa surveillance.

Alors, L'opérateur Rook se présente sous la forme d'un conteneur qui contient tout le nécessaire pour le déploiement et la maintenance ultérieure du stockage. Parmi les responsabilités de l'opérateur :

• la création d'un DaemonSet pour les démons de stockage Ceph (ceph-osd) avec un simple cluster RADOS ;
• la création de pods pour la surveillance Ceph (avec ceph-mon, vérifiant l'état du cluster ; pour le quorum, dans la plupart des cas, trois instances sont déployées, et lorsqu'une d'entre elles tombe, une nouvelle est lancée);
• la gestion des CRDs (Custom Resource Definitions) pour le cluster, des pools de stockage, object stores (ensembles de ressources et de services pour traiter les demandes HTTP, exécutant des PUT/GET pour des objets, compatibles avec les API S3 et Swift), ainsi que systèmes de fichiers;
• l'initialisation des pods pour démarrer tous les services nécessaires ;
• la création d'agents Rook.

Les agents Rook sont représentés par des pods distincts qui sont déployés sur chaque nœud Kubernetes. Le but de l'agent est de configurer le plugin FlexVolume, permettant de prendre en charge des volumes de stockage dans Kubernetes. L'agent réalise l'exploitation du stockage : connecte des dispositifs de stockage en réseau, monte des volumes, formate le système de fichiers, etc.

Place et rôle des composants Rook dans le schéma global du cluster Kubernetes

Rook propose trois types de stockage :

1. stockage en bloc (Block, StorageClass) — monte le stockage à un seul pod ;
2. stockage par objet (Object, ObjectStore) — accessible à l'intérieur et à l'extérieur du cluster Kubernetes (via l'API S3) ;
3. système de fichiers partagé (Shared File System, Système de fichiers) — système de fichiers pouvant être monté en lecture et écriture depuis plusieurs pods.

Le dispositif interne de Rook comprend :

• Mons — pods pour la surveillance de Ceph (avec les ceph-mon mentionnés précédemment) ;
• OSDs — pods avec des démons ceph-osd (Démons de stockage par objet) ;
• MGR — pods avec le démon ceph-mgr (Ceph Manager), fournissant des capacités de surveillance supplémentaires et des interfaces pour des systèmes externes (surveillance/gestion) ;
• RGW (en option) — pods avec stockage d'objet ;
• MDS (en option) — pods avec système de fichiers partagé.

Tous les démons Rook (Mons, OSDs, MGR, RGW, MDS) sont compilés dans un seul binaire (rook), exécuté dans un conteneur.

Pour une présentation succincte du projet Rook, cette petite (12 diapositives) présentation de Bassam Tabbara (CTO de Quantum Corp) peut également être utile.

Exploitation de Rook

L'opérateur Rook prend en charge Kubernetes version 1.6 et supérieure (et, partiellement, une version antérieure de K8s — 1.5.2). Son installation dans scénario le plus simple semble être le suivant :

cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yaml

De plus, un Helm charta été préparé pour l'opérateur Rook, ce qui permet de réaliser l'installation de cette manière :

helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook

Il y a un petit nombre d'options de configuration (par exemple, il est possible de désactiver le support RBAC, si cette fonctionnalité n'est pas utilisée dans votre cluster), qui sont passées au helm install via le paramètre --set key=value[,key=value] (ou de les conserver dans un fichier YAML séparé, et de les transmettre via -f values.yaml).

Après l'installation de l'opérateur Rook et le démarrage des pods avec ses agents, il reste à créer le cluster Rook lui-même, dont la configuration la plus simple ressemble à ceci (rook-cluster.yaml):

apiVersion: v1
kind: Namespace
metadata:
  name: rook
---
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
  name: rook
  namespace: rook
spec:
  dataDirHostPath: /var/lib/rook
  storage:
    useAllNodes: true
    useAllDevices: false
    storeConfig:
      storeType: bluestore
      databaseSizeMB: 1024
      journalSizeMB: 1024

Remarque: une attention particulière doit être portée à l'attribut dataDirHostPath, dont un espace disque d'au moins 5 Go doit être disponible dans ce répertoire pour une utilisation comme espace de stockage persistant pour Rook sur des hôtes Kubernetes.

Il ne reste plus qu'à créer un cluster à partir de la configuration et à s'assurer que les pods ont été créés dans le cluster (dans l'espace de noms rook):

kubectl create -f rook-cluster.yaml
kubectl -n rook get pod
NAME                              READY     STATUS    RESTARTS   AGE
rook-api-1511082791-7qs0m         1/1       Running   0          5m
rook-ceph-mgr0-1279756402-wc4vt   1/1       Running   0          5m
rook-ceph-mon0-jflt5              1/1       Running   0          6m
rook-ceph-mon1-wkc8p              1/1       Running   0          6m
rook-ceph-mon2-p31dj              1/1       Running   0          6m
rook-ceph-osd-0h6nb               1/1       Running   0          5m

Upgrade la mise à jour du cluster Rook (avant la nouvelle version) est une procédure qui nécessite à ce stade une mise à jour progressive de tous ses composants dans un ordre spécifique, et elle ne peut être commencée qu'une fois que vous vous êtes assuré que l'installation actuelle de Rook est entièrement « saine ». Un guide détaillé étape par étape sur la mise à jour de Rook de la version 0.5.0 à 0.5.1 peut être trouvé dans documentation du projet.

En novembre de l'année dernière, sur le blog de Rook a été publié comparaison performance avec EBS. Ses résultats méritent d'être pris en compte, et en résumé, ils sont les suivants :

Perspectives

Le statut actuel de Rook est alpha, et le dernier grand lancement à ce jour est la version 0.6, publiée en novembre 2017 (la version de correction actuelle est v0.6.2 — sortie le 14 décembre). Dans la première moitié de 2018, des versions plus matures sont attendues : bêta et stable (officiellement prêtes pour une utilisation en production).

Selon roadmap du projet, les développeurs ont une vision détaillée du développement de Rook pour au moins les deux prochaines versions : 0.7 (sa préparation dans le tracker GitHub est évalué à 60 %) et 0.8. Parmi les changements attendus figurent le passage du support de Ceph Block et Ceph Object au statut bêta, le provisionnement dynamique des volumes pour CephFS, un système de journalisation avancé, des mises à jour automatisées de cluster, et le support des snapshots pour les volumes.

L'adoption de Rook parmi les projets de la CNCF (pour l'instant au tout début — au niveau `inception`, — au même titre que linkerd et CoreDNS) est une sorte de garantie d'un intérêt croissant pour le produit. Dans quelle mesure il s'implantera dans le monde des applications cloud, cela deviendra plus clair après la sortie de versions stables, qui apporteront sans aucun doute de nouveaux « testeurs » et utilisateurs à Rook.

P.S.

Lisez aussi dans notre blog :

• «Créons un stockage permanent avec provisioning dans Kubernetes basé sur Ceph»;
• «Opérateurs pour Kubernetes : comment exécuter des applications stateful»;
• «CoreDNS — serveur DNS pour le monde cloud natif et Service Discovery pour Kubernetes»;
• «L'Interface de Réseau de Conteneurs (CNI) — interface réseau et norme pour les conteneurs Linux»;
• «Infrastructure avec Kubernetes en tant que service accessible».

Source : habr.com