Rook — „isehaldav“ andmehälli lahendus Kubernetesile

29. jaanuaril teatas CNCF (Cloud Native Computing Foundation), mis on Kubernetes, Prometheuse ja teiste konteinerite ja cloud native'i avatud lähtekoodiga toodete loomise organisatsioon, kuulutas projekti vastuvõtmisest Rook oma ridadesse. Suurepärane põhjus tutvuda lähemalt selle 'jaotatud andmehoidlate orkestri' võimalustega Kuberneteses.

Mis on Rook?

Rook — see on Go keeles kirjutatud tarkvara (GNU Üldine Avaliku litsentsi alusel. avatud litsentsi Apache License 2.0 alusel), mis on mõeldud andmehoidlate varustamiseks automatiseeritud funktsioonidega, mis muudavad need isejuhtivateks, isemõõtmisvõimeliseks ja eneseparandavateks.Selleks automatiseerib Rook (andmehoidlate jaoks, mida kasutatakse Kuberneteses): juurutamise, bootstrappingu, seadistamise, provisioningu, skaleerimise, uuendused, migratsioonid, tõrke taastamine, jälgimine ja ressursside haldamine.

Projekt on alfaetapis ja spetsialiseerub Cephi jaotatud andmehoidla orkestreerimisele Kubernetes'e klastrites. Autorid teatavad ka plaanidest toetada teisi andmehoidla süsteeme, kuid see ei toimu lähitulevikus.

Koostisosad ja tehniline struktuur

Rook'i töö aluseks Kubernetes'is on spetsiaalne operaator (Kubernetes'i operaatoritest oleme rohkem kirjutanud selles artiklis), automatiseerides salvestuskonfiguratsiooni ja teostades selle jälgimist.

Nii et, Rook'i operaator esindab konteinerit, mis sisaldab kõike vajalikku salvestuse juurutamiseks ja edaspidiseks hoolduseks. Operaatori kohustuste hulka kuulub:

• DaemonSet'i loomine Ceph'i salvestusdeemoneid jaoks (ceph-osd) lihtsa RADOS klastri jaoks;
• Ceph'i jälgimise pod'ide loomine (koos ceph-mon, mis kontrollivad klastri seisukorda; enamikul juhtudel juurutatakse kolm eksemplari kvoorumi tagamiseks, ning kui üks neist ebaõnnestub, tõstetakse uus üles);
• CRD'de haldamine (Custom Resource Definitions) klastrile endale salvestuspoolsed, objektide salvestamine, (ressursside ja teenuste kogum, mis teenindavad HTTP-päringuid, tehes PUT/GET tegevusi objektide jaoks, — nad on S3 ja Swift API-ga ühilduvad) failisüsteemid, samuti pod'ide initsialiseerimine, et käivitada kõik vajalikud teenused;;
• Rook'i agentide loomine.
• Rook'i agendid

esindavad eraldi pod'e, mis juurutatakse igas Kubernetes'i sõlmes. Agendi eesmärk on plugina konfiguratsioon FlexVolume FlexVolume, tagab toetuse hoidlate mahtude jaoks Kubernetesis. Agent haldab salvestust: ühendab salvestusseadmed, kinnitab mahtusid, vormindab failisüsteemi jne.

Rooki komponentide asukoht ja roll Kubernetes klastrite üldskeemis

Rook pakub kolme tüüpi salvestusi:

1. plokk (Block, StorageClass) — kinnitab salvestust ühe podiga;
2. objekt (Object, ObjectStore) — on saadaval klastris ja väljaspool Kubernetesit (S3 API kaudu);
3. jagatud FS (Shared File System, Failisüsteem) — failisüsteem, mida saab kirjutamiseks ja lugemiseks kinnitada mitmest podist.

Rooki siseseade sisaldab:

• Mons — Cephi jälgimise podid (varem mainitud ceph-mon);
• OSDsd — podid ceph-osd (objektide salvestamise deemonite) jaoks;
• MGR — podid deemoniga ceph-mgr (Ceph Manager), mis pakub täiendavaid jälgimisvõimalusi ja liideseid välistesse süsteemidesse (jälgimine/haldamine);
• RGW (valikuline) — podid objektide salvestamiseks;
• MDS (valikuline) — podid jagatud FS-iga.

Kõik Rooki deemonid (Mons, OSDsd, MGR, RGW, MDS) on kompileeritud ühte binaari (rook), mis käivitatakse konteineris.

Rooki projekti lühikese ülevaate jaoks võib olla kasulik ka see väike (12 slaidi) esitlus Bassam Tabbara (Quantum Corp CTO) esitlus.

Rooki haldamine

Rook operaator toetab täielikult Kubernetes versioone 1.6 ja kõrgemad (ja osaliselt vanemat K8s versiooni — 1.5.2). Tema paigaldamine ühes lihtsamal stsenaariumil näeb välja nii:

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

Lisaks on Rook operaatori jaoks ette valmistatud Helm diagramm, mistõttu saab paigaldust teostada ka järgmiselt:

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

On olemas väike hulk seadistamisvalikuid (näiteks saab välja lülitada toe RBAC, kui seda funktsiooni teie klastris ei kasutata), mis edastatakse helm install kaudu parameetri --set key=value[,key=value] (või hoida eraldi YAML-failis ja edastada — kaudu -f values.yaml).

Pärast Rook operaatori paigaldamist ja teemade käivitamist jääb järele luua Rook klaster, mille lihtne konfiguratsioon näeb välja järgmiselt (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

Märkus: erilisele tähelepanu tuleks pöörata attribuudile dataDirHostPath, mille, mis on vajalik klastrite säilitamiseks pärast taaskäivitusi. Kui kasutatakse kui püsivat andmete salvestamise kohta, soovitavad Rook-i autorid, et sellel kataloogil oleks vähemalt 5 GB vaba kettaruumi.

Jääb vaid luua klaster konfiguratsioonist ja veenduda, et podid on klastrisse loodud (nimetatud ruumis rook):

kubectl create -f rook-cluster.yaml
kubectl -n rook get pod
NIME                               VALMIS   OLEK     TAASKÄIVITUSED AGE
rook-api-1511082791-7qs0m         1/1      Jookseb   0          5m
rook-ceph-mgr0-1279756402-wc4vt   1/1      Jookseb   0          5m
rook-ceph-mon0-jflt5              1/1      Jookseb   0          6m
rook-ceph-mon1-wkc8p              1/1      Jookseb   0          6m
rook-ceph-mon2-p31dj              1/1      Jookseb   0          6m
rook-ceph-osd-0h6nb               1/1      Jookseb   0          5m

Uuendus Rook klastrite (enne uut versiooni) uuendamise protseduur on selline, et see nõuab kõigi komponentide järkjärgulist uuendamist kindlas järjekorras, alustades seda saab teha üksnes pärast seda, kui olete veendunud Rooki praeguses täielikult "terves" olekus. Üksikasjaliku samm-sammulise juhise leidmiseks, mis käsitleb Rook'i versiooni 0.5.0 uuendamist versioonile 0.5.1, vaadake projekti dokumentatsioonist.

Eelmise aasta novembris Rooki blogis oli avaldatud võrdlus praegune EBS-iga. Selle tulemused on tähelepanuväärsed ja kui lühidalt kokku võtta, siis need on järgmised:

Perspektiivid

Rooki praegune staatus on alpha, ning viimane suur väljaanne kuni tänaseni on versioon 0.6, mis ilmus novembris 2017 (ajakohane parandamine — v0.6.2 — ilmus 14. detsembril). Juba 2018. aasta esimeses pooles oodatakse küpsemaid versioone: beetaversioone ja stabiilset (ametlikult tootmises kasutamiseks valmis).

Vastavalt teekaardil projekti jaoks on arendajatel selge nägemus Rooki arendamisest vähemalt kahel järgmisel väljaandel: 0.7 (selle valmidus GitHubi jälgijas hindatakse 60% ulatuses) ja 0.8. Oodatud muudatuste seas — Ceph Blocki ja Ceph Objecti toe üleviimine beetaversiooniks, CephFS jaoks dünaamiline mahtude pakkumine, arenenud logimise süsteem, automatiseeritud klastri uuendused, mahtude jaoks kuvatõmmiste tugi.

Rooki vastuvõtmine CNCF projektide hulka (praegu kõige varasemas etapis — 'inception-level', — koos linkerd ja CoreDNS) on tõeliselt usaldusväärne märk kasvavast huvist toote vastu. Kuidas see end pilvetoetustes kinnitab, selgub paremini stabiilsete versioonide ilmumisel, mis toovad Rookile kindlasti uusi „katsetajaid” ja kasutajaid.

P.S.

Lugege ka meie blogist:

• «Loome püsivat salvestust Kuberneteses Cephi põhjal»;
• «Operaatorid Kubernetes'e jaoks: kuidas käivitada stateful-rakendusi»;
• «CoreDNS – DNS-server pilvetoetuste ja Kubernetes'e teenuste avastamiseks.»;
• «Container Networking Interface (CNI) – võrgu liides ja standard Linuxi konteinerite jaoks.»;
• «Kubernetes'i infrastruktuur kui teenus».

Allikas: habr.com