Rook — un stocare de date „autogestionată” pentru Kubernetes

Pe 29 ianuarie, comitetul tehnic al organizației CNCF (Cloud Native Computing Foundation), care se ocupă de Kubernetes, Prometheus și alte produse Open Source din lumea containerelor și cloud native, a anunțat a adoptat proiectul Rook în rândurile sale. O oportunitate excelentă de a ne familiariza îndeaproape cu acest „dirijor” al sistemelor de stocare distribuită în Kubernetes.

Ce este Rook?

Rook — este un software scris în Go (se răspândește sub licența liberă Apache License 2.0), destinat să ofere funcții automatizate stocărilor de date, care le fac autogestionate, auto-scalabile și auto-reparabile. Pentru aceasta, Rook automatizează (pentru stocările de date utilizate în medii Kubernetes): implementarea, bootstrapping-ul, configurarea, provisioning-ul, scalarea, actualizările, migrațiile, recuperarea din eșecuri, monitorizarea și gestionarea resurselor.

Proiectul se află în stadiul alfa și se specializează în orchestratizarea sistemului de stocare distribuită Ceph în clustere Kubernetes. Autorii afirmă, de asemenea, că au intenții de a sprijini și alte sisteme de stocare, dar acest lucru se va întâmpla nu în cele mai apropiate versiuni.

Componente și arhitectura tehnică

În baza funcționării Rook în Kubernetes se află un operator special (detalii despre Kubernetes Operators am scris în această articole), care automatizează configurarea stocării și realizează monitorizarea acesteia.

Deci, operatorul Rook se prezintă ca un container care conține tot ce este necesar pentru implementarea și întreținerea ulterioară a stocării. Printre responsabilitățile operatorului se numără:

• crearea unui DaemonSet pentru demonii de stocare Ceph (ceph-osd) cu un simplu cluster RADOS;
• crearea podurilor pentru monitorizarea Ceph (cu ceph-mon, care verifică starea clusterului; pentru a obține un quorum, în cele mai multe cazuri se implementează trei exemplare, iar în cazul căderii oricăruia dintre ele se va ridica un nou pod);
• gestionarea CRD-urilor (Definițiilor de Resurse Personalizate) pentru însăși clusterul, piscinelor de stocare, object stores (seturi de resurse și servicii pentru a răspunde la cererile HTTP, care efectuează PUT/GET pentru obiecte, fiind compatibile cu S3 și Swift API), dar și pentru sistemelor de fișiere;
• inițializarea podurilor pentru a rula toate serviciile necesare;
• crearea agenților Rook.

Agenții Rook sunt reprezentați de poduri separate, care sunt implementate pe fiecare nod Kubernetes. Scopul agentului este configurarea pluginului FlexVolume, asigurând suport pentru volumele de stocare în Kubernetes. Agentul realizează gestionarea stocării: conectează dispozitivele de stocare în rețea, montează volumele, formatează sistemul de fișiere etc.

Locația și rolul componentelor Rook în schema generală a cluster-ului Kubernetes

Rook oferă trei tipuri de stocare:

1. stocare bloc (Block, StorageClass) — montează stocarea la un singur pod;
2. stocare de obiecte (Object, ObjectStore) — disponibil atât în interiorul cât și în afara cluster-ului Kubernetes (prin API S3);
3. sistem de fișiere partajat (Shared File System, Filesystem) — sistem de fișiere care poate fi montat pentru citire și scriere din multiple pod-uri.

Dispozitivul intern Rook include:

• Mons — pod-uri pentru monitorizarea Ceph (cu deja menționatele ceph-mon);
• OSDs — pod-uri cu demoni ceph-osd (Object Storage Daemons);
• MGR — pod-uri cu demonul ceph-mgr (Ceph Manager), care oferă capacități suplimentare de monitorizare și interfețe pentru sisteme externe (monitorizare/management);
• RGW (opțional) — pod-uri cu stocare de obiecte;
• MDS (opțional) — pod-uri cu sistem de fișiere partajat.

Toți demonii Rook (Mons, OSDs, MGR, RGW, MDS) sunt compilați într-un singur binary (rook), rulat într-un container.

Pentru o prezentare sumară a proiectului Rook, această mică (12 slide-uri) prezentare de la Bassam Tabbara (CTO la Quantum Corp).

Operarea Rook

Operatorul Rook suportă pe deplin Kubernetes versiunea 1.6 și mai recent (și, parțial, versiunea mai veche K8s — 1.5.2). Instalarea sa într-un scenariu simplu în cd cluster/examples/kubernetes kubectl create -f rook-operator.yaml kubectl create -f rook-cluster.yaml arată astfel:

În plus, pentru operatorul Rook a fost pregătit

, ceea ce permite instalarea și astfel: diagrama Helmhelm repo add rook-alpha https://charts.rook.io/alpha helm install rook-alpha/rook

Există un număr mic de

opțiuni de configurare (de exemplu, se poate dezactiva suportul , dacă această opțiune nu este utilizată în cluster-ul dumneavoastră), care sunt transmise în RBACprin parametrul helm install --set key=value[,key=value] (sau se pot stoca într-un fișier YAML separat, iar transferul se face prin -f values.yaml După instalarea operatorului Rook și pornirea pod-urilor cu agenții săi, rămâne de creat cluster-ul Rook, configurația sa simplă arătând astfel ().

rook-cluster.yamlapiVersion: 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):

: merită să se acorde o atenție specială atributului

Notă: este deosebit de important să acordăm atenție atributului dataDirHostPath, a cărui valoare corectă este necesară pentru menținerea clusterului după reporniri. În cazurile în care este utilizat ca loc permanent de stocare a datelor, autorii Rook recomandă să aveți cel puțin 5 GB de spațiu liber pe disc în acest director de pe gazdele Kubernetes.

Rămâne să creăm efectiv clusterul din configurație și să ne asigurăm că podurile au fost create în cluster (în spațiul de nume 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

Upgrade clusterului Rook (la o nouă versiune) este o procedură care necesită, în această etapă, actualizarea pe rând a tuturor componentelor sale într-o anumită ordine, iar inițierea acesteia se poate face doar după ce v-ați asigurat că instalația curentă a Rook este complet «sănătoasă». O instrucțiune detaliată pas cu pas, utilizând exemplul actualizării Rook de la versiunea 0.5.0 la 0.5.1, poate fi găsită în documentația proiectului.

În noiembrie anul trecut, pe blogul Rook a fost publicat comparația performanță cu EBS. Rezultatele sunt demne de atenție, iar pe scurt, acestea sunt:

Perspective

Stadiul actual al Rook este alpha, iar cea mai recentă versiune majoră lansată până în prezent este versiunea 0.6, lansată în noiembrie 2017 (corectura actuală — v0.6.2 — a fost lansată pe 14 decembrie). În prima jumătate a anului 2018 se așteaptă lansări de versiuni mai mature: beta și stabilă (oficial pregătită pentru utilizare în producție).

Conform roadmap proiectului, dezvoltatorii au o viziune detaliată pentru dezvoltarea Rook în următoarele două lansări: 0.7 (pregătirea sa în trackerul GitHub este evaluat ca 60 %) și 0.8. Printre schimbările așteptate se numără tranziția suportului pentru Ceph Block și Ceph Object în statut beta, provisioning dinamic al volumelor pentru CephFS, un sistem de logare avansat, actualizări automatizate ale clusterului, suport pentru instantanee ale volumelor.

Acceptarea Rook în rândul proiectelor CNCF (încă în prima fază — „inception-level”, alături de linkerd și CoreDNS) este o garanție a interesului tot mai mare pentru produs. Cât de bine se va adapta în lumea aplicațiilor cloud, va fi mai clar după lansarea versiunilor stabile, care cu siguranță vor aduce Rook noi «testeri» și utilizatori.

P.S.

Citiți și în blogul nostru:

• «Creăm un depozit persistent cu provisioning în Kubernetes bazat pe Ceph»;
• «Operatori pentru Kubernetes: cum să lancezi aplicații stateful»;
• «CoreDNS — server DNS pentru lumea cloud native și Service Discovery pentru Kubernetes»;
• «Container Networking Interface (CNI) — interfață de rețea și standard pentru containerele Linux»;
• «Infrastructura cu Kubernetes ca serviciu disponibil».

Sursa: habr.com