Január 29-én a CNCF (Cloud Native Computing Foundation), a Kubernetes, a Prometheus és más, a konténerek és a felhő natív világából származó nyílt forráskódú termékek mögött álló szervezet technikai bizottsága, bejelentett a projekt elfogadásáról hamiskártyás soraikba. Kiváló lehetőség, hogy megismerjük ezt a „kubernetesi elosztott tárolási hangszerelőt”.
Milyen bástya?
hamiskártyás Go-ban íródott szoftver (forgalmazza az ingyenes Apache License 2.0), amelynek célja, hogy az adattárházakat olyan automatizált funkciókkal látja el, amelyek önmenedzselő, önskálázó és öngyógyító. Ehhez a Rook automatizálja (a Kubernetes-környezetben használt adattárak esetében): üzembe helyezés, rendszerindítás, konfiguráció, üzembe helyezés, méretezés, frissítések, áttelepítések, vész-helyreállítás, figyelés és erőforrás-kezelés.
A projekt alfa szakaszban van, és a Ceph elosztott tárolórendszer Kubernetes-fürtökben történő összehangolására specializálódott. A szerzők más tárolórendszerek támogatását is bejelentik, de ez nem fog megtörténni a következő kiadásokban.
Alkatrészek és műszaki eszköz
Rook munkája a Kubernetesen belül egy speciális operátoron alapul (A Kubernetes Operatorokról bővebben itt írtunk ezt a cikket), amely automatizálja a tárolási konfigurációt és megvalósítja annak felügyeletét.
Így Bástya kezelő úgy tűnik, hogy egy tároló, amely mindent tartalmaz, ami a tároló telepítéséhez és későbbi karbantartásához szükséges. Az üzemeltető feladatai közé tartozik:
DaemonSet létrehozása a Ceph tárolódémonokhoz (ceph-osd) egyszerű RADOS klaszterrel;
hüvelyek létrehozása a Ceph monitorozáshoz (val vel ceph-mon, a fürt állapotának ellenőrzése; a határozatképességhez az esetek többségében három példányt telepítenek, és ha bármelyik elesik, egy új emelkedik);
CRD-k kezelése (Egyéni erőforrás-definíciók) magának fürt, tárolómedencék, tárgytárolók(erőforrás- és szolgáltatáskészletek HTTP-kérések kiszolgálásához, amelyek PUT/GET-et hajtanak végre az objektumokon – kompatibilisek az S3-mal és a Swift API-val)És fájlrendszerek;
pod-ok inicializálása az összes szükséges szolgáltatás elindításához;
Rook ügynökök létrehozása.
Rook ügynökei különálló podok képviselik, amelyek mindegyik Kubernetes csomóponton vannak telepítve. Az ügynök célja a plugin konfigurációja FlexVolume, amely támogatja a Kubernetes tárolóköteteit. Az ügynök megvalósítja a tároló működését: hálózati tárolóeszközöket csatlakoztat, köteteket csatlakoztat, formázza a fájlrendszert stb.
A Rook-összetevők helye és szerepe a Kubernetes-fürt általános rendszerében
A Rook háromféle tárolást kínál:
Blokk (Blokk, StorageClass) — egyetlen kandallóra szereli a tárolót;
tárgy (tárgy, ObjectStore) - elérhető a Kubernetes-fürtön belül és kívül (S3 API-n keresztül);
megosztott fájlrendszer (Megosztott fájlrendszer, Filesystem) egy olyan fájlrendszer, amely több podról való olvasáshoz és íráshoz is csatlakoztatható.
A Rook belső elemei a következők:
Mons — hüvelyek Ceph monitorozására (a már említett ceph-monnal);
M.G.R. - hüvelyek egy démonnal ceph-mgr (Ceph Manager), amely további felügyeleti képességeket és interfészeket biztosít a külső rendszerek számára (monitoring/control);
Az összes Rook démon (Mons, OSD, MGR, RGW, MDS) egyetlen binárisba van fordítva (rook) konténerben fut.
A Rook projekt rövid bemutatásához ez a rövid (12 dia) is hasznos lehet. előadás Bassam Tabbara-tól (a Quantum Corp műszaki igazgatója).
A bástya működtetése
A Rook operátor teljes mértékben támogatja a Kubernetes 1.6-os és újabb verzióit (és részben a régebbi K8s kiadás - 1.5.2). Övé telepítés в legegyszerűbb forgatókönyv így néz ki:
cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yaml
Ezenkívül a Bástya kezelője felkészült Helm diagram, aminek köszönhetően a telepítés a következőképpen hajtható végre:
Kis mennyiségben kapható beállítási lehetőségek (például letilthatja a támogatást RBAC, ha ez a funkció nem használatos a fürtben), amelyek átadásra kerülnek helm install paraméteren keresztül --set key=value[,key=value] (vagy tárolja egy külön YAML fájlban, és továbbítsa ezen keresztül -f values.yaml).
Miután telepítette a Rook operátort és elindította a podokat az ügynökeivel, már csak magának a Rook klaszternek a létrehozása van hátra, amelynek legegyszerűbb konfigurációja így néz ki (rook-cluster.yaml):
Megjegyzés: különös figyelmet kell fordítani az attribútumra dataDirHostPath, amelynek helyes értéke szükséges a fürt újraindítások utáni mentéséhez. Azokban az esetekben, amikor állandó tárolási helyként használják a Rook-adatokhoz a Kubernetes-állomásokon, a szerzők azt javasolják, hogy ebben a könyvtárban legyen legalább 5 GB szabad lemezterület.
Már csak a konfigurációból kell létrehozni a fürtöt, és meg kell győződni arról, hogy a podokat a fürtben (a névtérben) hozták létre 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 cluster (egy új verzióig) egy olyan eljárás, amely ebben a szakaszban minden összetevőjének egy bizonyos sorrendben történő szekvenciális frissítését igényli, és csak akkor indíthatja el, ha meggyőződött arról, hogy az aktuális Rook telepítés teljesen „egészséges” állapotban van. állapot. A Rook 0.5.0-s verziójának 0.5.1-es verziójának frissítésének példáján részletes, lépésről lépésre szóló utasítások itt találhatók. projektdokumentáció.
Tavaly novemberben a Rook blogon nyilvánosságra hozták összehasonlítás termelékenység az EBS-sel. Eredményei figyelmet érdemelnek, és röviden a következők:
Kilátások
A Rook jelenlegi állapota alfa, a legújabb nagy kiadás pedig az 0.6 verzió, 2017 novemberében jelent meg (jelenlegi javítás - v0.6.2 — december 14-én jelent meg). Már 2018 első felében várhatók a kiforrottabb verziók megjelenése: béta és stabil (hivatalosan készen áll a termelési használatra).
Szerint ütemterv projekt, a fejlesztőknek részletes elképzelésük van a Rook fejlesztéséről legalább a következő két kiadásban: 0.7 (készült a GitHub trackerben becsült mint 60%) és 0.8. A várható változások között szerepel a Ceph Block és a Ceph Object támogatásának béta verzióba való áthelyezése, a kötetek dinamikus kiépítése a CephFS-hez, egy fejlett naplózási rendszer, az automatizált fürtfrissítések, a kötetek pillanatképeinek támogatása.
Rook átvétele a számba CNCF projektek (eddig nagyon korai szakaszban - „kezdeti szinten” - egyenrangú linkerd и CoreDNS) egyfajta garanciát jelent a termék iránti növekvő érdeklődésre. Hogy miként fogja megvetni a lábát a felhőalkalmazások világában, az a stabil verziók megjelenése után válik világossá, ami minden bizonnyal új tesztelőket és felhasználókat hoz majd a Rook-hoz.