Rook - isang self-service data store para sa Kubernetes

Rook - isang self-service data store para sa Kubernetes

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, inihayag tungkol sa pagtanggap ng proyekto titimbog sa kanilang hanay. Isang napakagandang pagkakataon para makilala itong “distributed storage orchestrator sa Kubernetes.”

Anong klaseng Rook?

titimbog ay software na nakasulat sa Go (ipinamahagi ni 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 artikulong ito), 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 (ceph-osd) na may simpleng kumpol ng RADOS;
  • paglikha ng mga pod para sa pagsubaybay sa Ceph (kasama ceph-mon, 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 (Mga Kahulugan ng Custom na Resource) para sa kanyang sarili кластера, mga pool ng imbakan, mga tindahan ng bagay (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 mga file system;
  • 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 FlexVolume, 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.

Rook - isang self-service data store para sa Kubernetes
Lugar at tungkulin ng mga bahagi ng Rook sa pangkalahatang scheme ng cluster ng Kubernetes

Nag-aalok ang Rook ng tatlong uri ng imbakan:

  1. harangan (Harangan ang, StorageClass) — inilalagay ang imbakan sa isang apuyan;
  2. bagay (Bagay, ObjectStore) - available sa loob at labas ng Kubernetes cluster (sa pamamagitan ng S3 API);
  3. nakabahaging sistema ng file (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-mgr (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.

Rook - isang self-service data store para sa Kubernetes

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. pagtatanghal 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 в pinakasimpleng senaryo ganito ang hitsura nito:

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

Bilang karagdagan, ang operator ng Rook ay inihanda Helm chart, 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 mga pagpipilian sa pag-setup (halimbawa, maaari mong huwag paganahin ang suporta RBAC, 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: 1024

Nota: 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          5m

Mag-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 dokumentasyon ng proyekto.

Noong nakaraang Nobyembre sa Rook blog ay nai-publish 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:

Rook - isang self-service data store para sa Kubernetes
Rook - isang self-service data store para sa Kubernetes

Prospect

Ang kasalukuyang katayuan ng Rook ay alpha, at ang pinakahuling major release hanggang ngayon ay bersyon 0.6, na inilabas noong Nobyembre 2017 (kasalukuyang pagwawasto - v0.6.2 — 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 roadmap 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 tinantya 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 Mga proyekto ng CNCF (sa ngayon sa pinakaunang yugto - "antas ng pagsisimula" - sa isang par sa linkerd и CoreDNS) 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

Bumili ng maaasahang pagho-host para sa mga site na may proteksyon ng DDoS, mga server ng VPS VDS 🔥 Bumili ng maaasahang website hosting na may proteksyon ng DDoS, VPS VDS servers | ProHoster