Rook - un magasin de données en libre-service pour Kubernetes

Le 29 janvier, le comité technique de la CNCF (Cloud Native Computing Foundation), l'organisme derrière Kubernetes, Prometheus et autres produits Open Source du monde des conteneurs et du cloud natif, объявил sur l'acceptation du projet Tour dans leurs rangs. Une excellente occasion de faire connaissance avec cet « orchestrateur de stockage distribué dans Kubernetes ».

Quel genre de Tour ?

Tour est un logiciel écrit en Go (distribué par sous la licence gratuite Apache 2.0), conçue pour fournir aux entrepôts de données des fonctions automatisées qui les rendent autogestion, auto-évolution et auto-guérison. Pour ce faire, Rook automatise (pour les magasins de données utilisés dans un environnement Kubernetes) : le déploiement, le démarrage, la configuration, le provisionnement, la mise à l'échelle, les mises à jour, les migrations, la reprise après sinistre, la surveillance et la gestion des ressources.

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

Composants et dispositif technique

Le travail de Rook au sein de Kubernetes est basé sur un opérateur spécial (nous avons écrit davantage sur les opérateurs Kubernetes dans cet article), qui automatise la configuration du stockage et met en œuvre sa surveillance.

ainsi, Opérateur de tour semble être un conteneur contenant tout le nécessaire pour le déploiement et la maintenance ultérieure du référentiel. Les responsabilités de l'opérateur comprennent :

• création d'un DaemonSet pour les démons de stockage Ceph (ceph-osd) avec un simple cluster RADOS ;
• création de pods pour la surveillance Ceph (avec ceph-mon, en vérifiant l'état du cluster ; pour le quorum, dans la plupart des cas trois exemplaires sont déployés, et si l'un d'entre eux tombe, un nouveau se lève);
• gestion des CRD (Définitions de ressources personnalisées) pour lui-même grappe, pools de stockage, magasins d'objets (ensembles de ressources et de services pour servir les requêtes HTTP qui effectuent PUT/GET sur des objets - ils sont compatibles avec S3 et Swift API)et systèmes de fichiers;
• initialiser les pods pour lancer tous les services nécessaires ;
• création d'agents Rook.

Agents de Tour sont représentés par des pods distincts déployés sur chaque nœud Kubernetes. Le but de l'agent est la configuration du plugin FlexVolume, qui prend en charge les volumes de stockage dans Kubernetes. L'agent met en œuvre le fonctionnement du stockage : connecte les périphériques de stockage réseau, monte les 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. bloc (Block, StorageClass) — monte le stockage sur un seul foyer ;
2. objet (Objet, ObjectStore) - disponible à l'intérieur et à l'extérieur du cluster Kubernetes (via l'API S3) ;
3. système de fichiers partagé (Système de fichiers partagé, Filesystem) est un système de fichiers qui peut être monté pour la lecture et l'écriture à partir de plusieurs pods.

Les composants internes du Rook comprennent :

• Mons — des pods pour la surveillance Ceph (avec le ceph-mon déjà mentionné) ;
• OSD - des pods avec des démons ceph-osd (Object Storage Daemons) ;
• MGR - des pods avec un démon ceph-mgr (Ceph Manager), qui fournit des capacités de surveillance et des interfaces supplémentaires pour les systèmes externes (surveillance/contrôle) ;
• RGW (optionnel) - des pods avec stockage d'objets ;
• MDS (optionnel) - des pods avec système de fichiers partagé.

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

Pour une brève introduction au projet Rook, ce court (12 diapositives) peut également être utile. présentation de Bassam Tabbara (CTO chez Quantum Corp).

Faire fonctionner la tour

L'opérateur Rook prend entièrement en charge Kubernetes version 1.6 et supérieure (et, en partie, l'ancienne version du K8 - 1.5.2). Son installation в scénario le plus simple Il ressemble à ceci:

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

De plus, l'opérateur Rook est prêt Carte de barre, grâce auquel l'installation peut être réalisée comme ceci :

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

Petite quantité disponible options de configuration (par exemple, vous pouvez désactiver le support RBAC (Contrôle d'accès basé sur le rôle), si cette fonctionnalité n'est pas utilisée dans votre cluster), qui sont transmises à helm install via paramètre --set key=value[,key=value] (ou stocker dans un fichier YAML séparé et transmettre via -f values.yaml).

Après avoir installé l'opérateur Rook et lancé les pods avec ses agents, il ne reste plus qu'à 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

Noter: une attention particulière doit être portée à l'attribut dataDirHostPath, dont la valeur correcte est nécessaire pour sauvegarder le cluster après les redémarrages. Dans les cas où il est utilisé comme emplacement de stockage permanent pour les données Rook sur les hôtes Kubernetes, les auteurs recommandent de disposer d'au moins 5 Go d'espace disque libre dans ce répertoire.

Il ne reste plus qu'à créer réellement le cluster à partir de la configuration et à s'assurer que les pods ont bien é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

Mise à jour Le cluster Rook (jusqu'à une nouvelle version) est une procédure qui, à ce stade, nécessite une mise à jour séquentielle de tous ses composants dans un certain ordre, et vous ne pouvez le démarrer qu'après vous être assuré que l'installation actuelle de Rook est dans un état complètement « sain ». État. Des instructions détaillées étape par étape utilisant l'exemple de mise à jour de Rook version 0.5.0 vers 0.5.1 peuvent être trouvées dans documentation du projet.

En novembre dernier sur le blog Rook a été publié comparaison productivité avec EBS. Ses résultats méritent attention et, en bref, ils sont les suivants :

Perspectives

Le statut actuel de Rook est alpha, et la dernière version majeure en date est Version 0.6, publié en novembre 2017 (correction actuelle - v0.6.2 - sorti le 14 décembre). Déjà au premier semestre 2018, des sorties de versions plus matures sont attendues : bêta et stable (officiellement prêtes à être utilisées en production).

selon feuille de route projet, les développeurs ont une vision détaillée du développement de Rook dans au moins les deux prochaines versions : 0.7 (sa préparation est dans le tracker GitHub estimé à 60%) et 0.8. Parmi les changements attendus figurent le transfert de la prise en charge de Ceph Block et Ceph Object vers le statut de version bêta, le provisionnement dynamique des volumes pour CephFS, un système de journalisation avancé, les mises à jour automatisées des clusters, la prise en charge des instantanés pour les volumes.

Faire entrer Rook dans le nombre Projets CNCF (jusqu'à présent, au tout début - "niveau de création" - à égalité avec linker и CoreDNS) est une sorte de garantie d'un intérêt croissant pour le produit. La manière dont il prendra pied dans le monde des applications cloud deviendra plus claire une fois que des versions stables seront publiées, ce qui attirera certainement de nouveaux testeurs et utilisateurs vers Rook.

PS

A lire aussi sur notre blog :

• «Création d'un stockage persistant avec provisionnement dans Kubernetes basé sur Ceph";
• «Opérateurs pour Kubernetes : comment exécuter des applications avec état";
• «CoreDNS - Serveur DNS pour le monde cloud natif et Service Discovery pour Kubernetes";
• «Container Networking Interface (CNI) - interface réseau et standard pour les conteneurs Linux";
• «Infrastructure avec Kubernetes comme service abordable».

Source: habr.com