Rook - önkiszolgáló adattár a Kubernetes számára

Rook - önkiszolgáló adattár a Kubernetes számára

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.

Rook - önkiszolgáló adattár a Kubernetes számára
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:

  1. Blokk (Blokk, StorageClass) — egyetlen kandallóra szereli a tárolót;
  2. tárgy (tárgy, ObjectStore) - elérhető a Kubernetes-fürtön belül és kívül (S3 API-n keresztül);
  3. 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);
  • OSD-k - podok ceph-osd démonokkal (Object Storage Daemons);
  • 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);
  • RGW (választható) - hüvelyek tárgytárolóval;
  • MDS (választható) - hüvelyek megosztott fájlrendszerrel.

Rook - önkiszolgáló adattár a Kubernetes számára

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:

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

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):

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 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:

Rook - önkiszolgáló adattár a Kubernetes számára
Rook - önkiszolgáló adattár a Kubernetes számára

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.

PS

Olvassa el blogunkon is:

Forrás: will.com

Hozzászólás