
Noong Enero 29, ang technical committee ng CNCF (Cloud Native Computing Foundation), ang organisasyon sa likod ng Kubernetes, Prometheus at iba pang Open Source na mga produkto mula sa mundo ng mga container at cloud native, tungkol sa pagtanggap ng proyekto titimbog sa kanilang hanay. Isang napakagandang pagkakataon para makilala itong “distributed storage orchestrator sa Kubernetes.”
Anong klaseng Rook?
ay software na nakasulat sa Go ( sa ilalim ng libreng Apache License 2.0), na idinisenyo upang magbigay ng mga warehouse ng data ng mga awtomatikong function na gumagawa ng mga ito self-manage, self-scaling at self-healing. Para magawa ito, nag-o-automate ang Rook (para sa mga data store na ginagamit sa isang Kubernetes environment): deployment, bootstrapping, configuration, provisioning, scaling, updates, migration, disaster recovery, monitoring at resource management.
Ang proyekto ay nasa alpha stage at dalubhasa sa pag-orkestra ng Ceph distributed storage system sa mga cluster ng Kubernetes. Inihayag din ng mga may-akda ang mga plano upang suportahan ang iba pang mga sistema ng imbakan, ngunit hindi ito mangyayari sa mga susunod na paglabas.
Mga bahagi at teknikal na aparato
Ang gawain ni Rook sa loob ng Kubernetes ay batay sa isang espesyal na operator (sumulat kami ng higit pa tungkol sa Kubernetes Operators sa ), na nag-automate sa configuration ng storage at nagpapatupad ng pagsubaybay nito.
Kaya, Rook operator lumilitaw na isang lalagyan na naglalaman ng lahat ng kailangan para sa pag-deploy at kasunod na pagpapanatili ng repositoryo. Kasama sa mga responsibilidad ng operator ang:
- paglikha ng DaemonSet para sa mga daemon ng imbakan ng Ceph () na may simpleng kumpol ng RADOS;
- paglikha ng mga pod para sa pagsubaybay sa Ceph (kasama , pagsuri sa katayuan ng kumpol; para sa korum, sa karamihan ng mga kaso tatlong kopya ang ipinakalat, at kung ang alinman sa mga ito ay bumagsak, ang isang bago ay tumataas);
- pamamahala ng mga CRD () para sa kanyang sarili , , (mga hanay ng mga mapagkukunan at serbisyo para sa paghahatid ng mga kahilingan sa HTTP na nagsasagawa ng PUT/GET sa mga bagay - tugma ang mga ito sa S3 at Swift API)At ;
- pagsisimula ng mga pod upang ilunsad ang lahat ng kinakailangang serbisyo;
- paglikha ng mga ahente ng Rook.
Mga Ahente ng Rook ay kinakatawan ng mga hiwalay na pod na naka-deploy sa bawat node ng Kubernetes. Ang layunin ng ahente ay pagsasaayos ng plugin , na nagbibigay ng suporta para sa dami ng storage sa Kubernetes. Ipinapatupad ng ahente ang pagpapatakbo ng storage: nag-uugnay sa mga network storage device, nag-mount ng mga volume, nag-format ng file system, atbp.

Lugar at tungkulin ng mga bahagi ng Rook sa pangkalahatang scheme ng cluster ng Kubernetes
Nag-aalok ang Rook ng tatlong uri ng imbakan:
- (Harangan ang,
StorageClass) — inilalagay ang imbakan sa isang apuyan; - (Bagay,
ObjectStore) - available sa loob at labas ng Kubernetes cluster (sa pamamagitan ng S3 API); - (Nakabahaging File System,
Filesystem) ay isang file system na maaaring i-mount para sa pagbabasa at pagsusulat mula sa maraming pods.
Ang mga panloob ng Rook ay kinabibilangan ng:
- Mons — pods para sa pagsubaybay sa Ceph (na may nabanggit na ceph-mon);
- Mga OSD - mga pod na may ceph-osd daemons (Object Storage Daemons);
- M.G.R. - mga pod na may demonyo (Ceph Manager), na nagbibigay ng karagdagang mga kakayahan sa pagsubaybay at mga interface para sa mga panlabas na sistema (pagsubaybay/kontrol);
- RGW (opsyonal) - mga pod na may imbakan ng bagay;
- MDS (opsyonal) - mga pod na may nakabahaging file system.

Lahat ng Rook daemon (Mons, OSDs, MGR, RGW, MDS) ay pinagsama-sama sa isang binary (rook) tumatakbo sa isang lalagyan.
Para sa isang maikling pagpapakilala sa proyekto ng Rook, ang maikling (12 slide) na ito ay maaari ding maging kapaki-pakinabang. mula sa Bassam Tabbara (CTO sa Quantum Corp).
Pagpapatakbo ng Rook
Ang Rook operator ay ganap na sumusuporta sa Kubernetes na bersyon 1.6 at mas mataas (at, bahagyang, ang mas lumang K8s release - 1.5.2). Ang kanyang pag-install в ganito ang hitsura nito:
cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yamlBilang karagdagan, ang operator ng Rook ay inihanda , salamat sa kung saan ang pag-install ay maaaring isagawa tulad nito:
helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook Maliit na dami na magagamit (halimbawa, maaari mong huwag paganahin ang suporta , kung hindi ginagamit ang feature na ito sa iyong cluster), na ipinapasa sa helm install sa pamamagitan ng parameter --set key=value[,key=value] (o mag-imbak sa isang hiwalay na YAML file at ipadala sa pamamagitan ng -f values.yaml).
Pagkatapos i-install ang Rook operator at ilunsad ang mga pod kasama ang mga ahente nito, ang natitira na lang ay likhain ang Rook cluster mismo, ang pinakasimpleng configuration na ganito ang hitsura (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: 1024Nota: espesyal na pansin ang dapat bayaran sa katangian dataDirHostPath, ang tamang halaga nito ay kinakailangan upang i-save ang cluster pagkatapos ng pag-reboot. Para sa mga kaso kung saan ginagamit ito bilang isang permanenteng lokasyon ng storage para sa Rook data sa mga host ng Kubernetes, inirerekomenda ng mga may-akda ang pagkakaroon ng hindi bababa sa 5 GB ng libreng puwang sa disk sa direktoryong ito.
Ang natitira na lang ay ang aktwal na gumawa ng cluster mula sa configuration at siguraduhin na ang mga pod ay ginawa sa cluster (sa namespace 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 5mMag-upgrade Ang Rook cluster (hanggang sa isang bagong bersyon) ay isang pamamaraan na sa yugtong ito ay nangangailangan ng sunud-sunod na pag-update ng lahat ng mga bahagi nito sa isang tiyak na pagkakasunod-sunod, at maaari mo lamang itong simulan pagkatapos mong matiyak na ang kasalukuyang pag-install ng Rook ay nasa ganap na "malusog" estado. Ang mga detalyadong sunud-sunod na tagubilin gamit ang halimbawa ng pag-update ng bersyon ng Rook 0.5.0 hanggang 0.5.1 ay matatagpuan sa .
Noong nakaraang Nobyembre sa Rook blog paghahambing pagiging produktibo may EBS. Ang mga resulta nito ay karapat-dapat ng pansin, at sa madaling sabi, ang mga ito ay ang mga sumusunod:


Prospect
Ang kasalukuyang katayuan ng Rook ay alpha, at ang pinakahuling major release hanggang ngayon ay , na inilabas noong Nobyembre 2017 (kasalukuyang pagwawasto - — lumabas noong Disyembre 14). Nasa unang kalahati na ng 2018, inaasahan ang mga release ng mas mature na bersyon: beta at stable (opisyal na handang gamitin sa produksyon).
Ayon sa proyekto, ang mga developer ay may detalyadong pananaw para sa pagbuo ng Rook sa hindi bababa sa susunod na dalawang release: 0.7 (ang kahandaan nito ay nasa GitHub tracker bilang 60%) at 0.8. Kabilang sa mga inaasahang pagbabago ay ang paglipat ng suporta para sa Ceph Block at Ceph Object sa beta version status, dynamic na provisioning ng mga volume para sa CephFS, isang advanced na logging system, mga awtomatikong pag-update ng cluster, suporta para sa mga snapshot para sa mga volume.
Pagkuha ng Rook sa Numero (sa ngayon sa pinakaunang yugto - "antas ng pagsisimula" - sa isang par sa и ) ay isang uri ng garantiya ng lumalaking interes sa produkto. Kung paano ito magkakaroon ng foothold sa mundo ng mga cloud application ay magiging mas malinaw kapag nailabas na ang mga stable na bersyon, na tiyak na magdadala ng mga bagong tester at user sa Rook.
PS
Basahin din sa aming blog:
- «";
- «";
- «";
- «";
- «'.
Pinagmulan: www.habr.com
