🥇Rook — az Ön által kezelt adatraktározás Kuberneteshez

Január 29-én a CNCF (Cloud Native Computing Foundation) technikai bizottsága, amely a Kubernetes, Prometheus és más, a konténeres és cloud native világban elérhető Open Source termékekért felelős, bejelentette megváltoztatott egy projektet Rook saját köreibe. Remek alkalom arra, hogy közelebbről megismerkedjünk ezzel a "rendszerek orkestrálásáért felelős szoftverrel, amely elosztott tárolási megoldásokban használható a Kubernetesben."

Mi az a Rook?

Rook — ez egy Go nyelven írt szoftver (terjesztésre kerül az Apache License 2.0 nyílt licenc alatt), amelynek célja, hogy automatizált funkciókkal ruházza fel az adat-tárolókat, lehetővé téve számukra, hogy önállóan kezelhessék magukat, automatikusan skálázhatók legyenek és helyreálljanak hiba esetén.Ehhez a Rook automatizálja (az Kubernetes környezetében használt adat-tárolók számára): a telepítést, bootstrappinget, konfigurációt, provisioningot, skálázást, frissítéseket, migrációkat, hibahelyreállítást, monitorozást és az erőforrások kezelését.

A projekt alfa szakaszban van, és a Ceph elosztott tárolórendszer orkestrálására specializálódott Kubernetes klaszterekben. A készítők azt is bejelentették, hogy más tárolási rendszerek támogatását is tervezik, de ezt nem a következő kiadásokban valósítják meg.

Komponensek és műszaki felépítés

A Rook működése a Kubernetes-en belül egy külön operátor köré épül (a Kubernetes operátorokról részletes információt korábban írtunk a cikkben), ami automatizálja a tárolás konfigurálását és a monitorozást valósítja meg.

Tehát, A Rook operátor egy olyan konténerként jelenik meg, amely tartalmazza az összes szükséges elemet a tároló telepítéséhez és karbantartásához. Az operátor feladatai közé tartozik:

a Ceph tárolásához szükséges DaemonSet létrehozása (ceph-osd) egyszerű RADOS klaszterrel;
podok létrehozása a Ceph monitorozására (a ceph-monállapotellenőrzéssel, a klaszter állapotának ellenőrzésére; a legtöbb esetben három példány kerül telepítésre a többségi szavazáshoz, és ha bármelyik meghibásodik, egy új példány kerül létrehozásra);
A CRD-k (Custom Resource Definitions) kezelése a saját klasztéré, tároló medencék, objektumtárak (a HTTP kérések kiszolgálására alkalmas erőforrások és szolgáltatások készlete, amelyek PUT/GET műveleteket végeznek objektumokkal, és kompatibilisek az S3 és Swift API-val), valamint fájlrendszerek;
podok inicializálása minden szükséges szolgáltatás elindításához;
Rook ügynökök létrehozása.

A Rook ügynökök külön podok formájában jelennek meg, amelyek minden Kubernetes csomóponton telepítésre kerülnek. Az ügynök feladata a FlexVolume plugin konfigurálása. FlexVolume, amely támogatja a tárolóvolumeneket a Kubernetesben. Az ügynök végrehajtja a tárolás üzemeltetését: csatlakoztatja a hálózati tárolóeszközöket, csatolja a volumeneket, formázza a fájlrendszert stb.

A Rook komponenseinek helye és szerepe a Kubernetes klaszter általános séma szerint

A Rook háromféle tárolót kínál:

blokktároló (Block, StorageClass) – csatlakoztatja a tárolót egyetlen podhoz;
objektumtároló (Object, ObjectStore) – a Kubernetes klaszteren belül és kívül is elérhető (S3 API-n keresztül);
megosztott fájlrendszer (Shared File System, Fájlrendszer) – olyan fájlrendszer, amelyet több pod is read-write módban csatolhat.

A Rook belső eszközei a következők:

Mons – podok a Ceph monitorozásához (a fent említett ceph-mon);
OSDs – podok ceph-osd démonokkal (Object Storage Daemons);
MGR – podok a ceph-mgr (Ceph Manager), amely további monitorozási lehetőségeket és interfészeket biztosít külső rendszereknek (monitorozás/kezelés);
RGW (opcionális) – podok objektumtárolóval;
MDS (opcionális) – podok a megosztott fájlrendszerrel.

Minden Rook démon (Mons, OSDs, MGR, RGW, MDS) egy egységes binárisba van fordítva (rook), amely a konténerben fut.

A Rook projekt rövid bemutatásához hasznos lehet ez a kicsi (12 diás) előadás Bassam Tabbara (CTO a Quantum Corp-nál).

A Rook üzemeltetése

A Rook operátor teljes mértékben támogatja az 1.6 és újabb Kubernetes verziókat (és részben a régebbi K8s verziót – 1.5.2)— a CPU/SoC hűtése, áthidalva az inaktív ciklusokat munka közben. Valamilyen szinten hasonlít az Intel processzorok PowerClamp meghajtójához, de nem köthető egy meghatározott architektúrához. A rendszert telepítés be. egyszerű forgatókönyvben így néz ki:

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

Ezen kívül a Rook operátor számára készült Helm chart, így a telepítés így is elvégezhető:

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

Van néhány beállítási lehetőség (például ki lehet kapcsolni a támogatást RBAC, ha ez a lehetőség nem használható a klaszterben), amelyeket a helm install paraméteren keresztül adunk meg --set key=value[,key=value] (vagy egy külön YAML fájlban tárolva, amelyet a -f values.yaml).

A Rook operátor telepítése után és az ügynökökkel rendelkező podok indítása után létre kell hozni magát a Rook klasztert, amelynek legegyszerűbb konfigurációja a következőképpen néz ki (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

Megjegyzés: különös figyelmet érdemel a tulajdonság dataDirHostPath, amelynek helyes értéke szükséges a klaszter megőrzéséhez újraindítások után. Amennyiben állandó adattároló helyként használja a Rook-ot a Kubernetes hosztokon, a szerzők ajánlják, hogy legalább 5 GB szabad lemezterület legyen elérhető ebben a mappában.

Először is létre kell hozni a klasztert a konfigurációból, és meg kell győződni arról, hogy a podok létrejöttek a klaszterben (a névtérben 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

Frissítés a Rook klaszter frissítése (az új verzió előtt) — ez egy olyan eljárás, amely ezen a ponton megköveteli az összes komponens fokozatos frissítését meghatározott sorrendben, és csak azután kezdheti el, ha megbizonyosodott arról, hogy a jelenlegi Rook telepítés teljesen „egészséges”. Részletes lépésről lépésre útmutatót a Rook 0.5.0-ról 0.5.1-re való frissítésről találhat projekt dokumentációjában.

Tavaly novemberben a Rook blogjában megjelenésre került összehasonlítás teljesítmény az EBS-sel. Az eredményei figyelemre méltóak, röviden az alábbiak:

Kilátások

A Rook jelenlegi állapota alpha, és a legutolsó jelentős kiadás eddig a 0.6, amelyet 2017 novemberében adtak ki (a legfrissebb javítás — v0.6.2 — 2017. december 14-én jelent meg). Már 2018 első felében várhatóak a fejlettebb verziók kiadása: béta és stabil (hivatalosan használatra kész).

A következő szerint roadmap a projekthez a fejlesztők részletes jövőképpel rendelkeznek a Rook fejlesztésére legalább a következő két kiadásban: 0.7 (készültsége a GitHub nyomkövetőjében értékelése körülbelül 60%) és 0.8. A várt változások között szerepel a Ceph Block és Ceph Object bétaverzióra való átállítása, dinamikus kötetkiosztás CephFS-hez, fejlett naplózási rendszer, automatizált klaszterfrissítések, támogatás a kötetek pillanatképéhez.

A Rook felvétele a CNCF projektek közé (jelenleg a legkorábbi szakaszban - „inception-level”, — a linkerd mellett ) egyfajta garancia a termék iránti növekvő érdeklődésre. Hogy mennyire tudja megerősíteni magát a felhőalkalmazások világában, az világosabbá válik a stabil verziók megjelenésével, amelyek kétségtelenül új „kipróbálókat” és felhasználókat hoznak a Rook számára. és CoreDNS) egyfajta garancia a termék iránti növekvő érdeklődésre. Hogy mennyire fog elköteleződni a felhőalkalmazások világában, az egyértelműbbé válik a stabil verziók megjelenése után, amelyek kétségtelenül új „próbálókat” és felhasználókat hoznak majd a Rookhoz.