Rook — «samoobsługowe» magazyn danych dla Kubernetes

29 stycznia komitet techniczny organizacji CNCF (Cloud Native Computing Foundation), odpowiedzialnej za Kubernetes, Prometheus i inne produkty Open Source z świata kontenerów i cloud native, ogłosił podjął decyzję o przyjęciu projektu Rook do swoich szeregów. Doskonała okazja, aby lepiej poznać tego "orchestratora systemów rozproszonego przechowywania danych w Kubernetes."

Czym jest Rook?

Rook – to oprogramowanie napisane w Go (rozpowszechniany na wolnej licencji Apache License 2.0), zaprojektowane w celu zapewnienia magazynom danych zautomatyzowanych funkcji, które czynią je samoorganizującymi się, samonapędlającymi się i samonaprawiającymi się. Aby to osiągnąć, Rook automatyzuje (dla magazynów danych używanych w środowisku Kubernetes): wdrażanie, uruchamianie, konfigurację, provisioning, skalowanie, aktualizacje, migracje, odzyskiwanie po awariach, monitorowanie i zarządzanie zasobami.

Projekt znajduje się w fazie alfa i specjalizuje się w orkiestracji rozproszonego systemu przechowywania danych Ceph w klastrach Kubernetes. Autorzy zapowiedzieli również plany wsparcia innych systemów przechowywania, ale nie stanie się to w najbliższych wydaniach.

Komponenty i techniczne urządzenie

Podstawą działania Rook wewnątrz Kubernetes jest specjalny operator (więcej o Operatorach Kubernetes pisaliśmy w w tym artykule), automatyzujący konfigurację przechowywania i realizujący jego monitorowanie.

Otóż operator Rook wnioskuje konteiner, który zawiera wszystko, co potrzebne do wdrażania i późniejszego serwisowania magazynu. Do obowiązków operatora należy:

• tworzenie DaemonSet dla demonów przechowywania Ceph (ceph-osd) z prostym klastrem RADOS;
• tworzenie podów do monitorowania Ceph (z ceph-mon, sprawdzających stan klastra; dla quorum w większości przypadków uruchamiane są trzy egzemplarze, a w przypadku awarii któregokolwiek z nich uruchamiany jest nowy);
• zarządzanie CRD (Custom Resource Definitions) dla samego klastra, puli magazynów, obiektów pamięci (zestawów zasobów i usług do obsługi zapytań HTTP, wykonujących PUT/GET dla obiektów — są zgodne z API S3 i Swift), a także systemów plików;
• inicjalizacja podów do uruchomienia wszystkich potrzebnych usług;
• tworzenie agentów Rook.

Agenci Rook są reprezentowani przez oddzielne pody, które są wdrażane na każdym węźle Kubernetes. Celem agenta jest konfiguracja wtyczki FlexVolume, zapewniającego wsparcie dla wolumenów pamięci w Kubernetes. Agent realizuje obsługę pamięci: podłącza sieciowe urządzenia pamięci, montuje wolumeny, formatuje systemy plików itd.

Miejsce i rola komponentów Rook w ogólnym schemacie klastra Kubernetes

Rook oferuje trzy rodzaje pamięci:

1. blokową (Block, StorageClass) — montuje pamięć do pojedynczego poda;
2. obiektową (Object, ObjectStore) — dostępna wewnątrz i na zewnątrz klastra Kubernetes (przez API S3);
3. współdzieloną FS (Shared File System, Filesystem) — system plików, który można montować do odczytu i zapisu z wielu podów.

Wewnętrzne urządzenie Rook obejmuje:

• Mons — pody do monitorowania Ceph (z już wspomnianym ceph-mon);
• OSDs — pody z demonami ceph-osd (Object Storage Daemons);
• MGR — pody z demonem ceph-mgr (Ceph Manager), oferującym dodatkowe możliwości monitorowania i interfejsy dla zewnętrznych systemów (monitorowania/zarządzania);
• RGW (opcjonalnie) — pody z pamięcią obiektową;
• MDS (opcjonalnie) — pody z współdzieloną FS.

Wszystkie demony Rook (Mons, OSDs, MGR, RGW, MDS) są skompilowane w jeden binarny plik (rook), uruchamiany w kontenerze.

Dla krótkiego przedstawienia projektu Rook może przydać się także ta niewielka (12 slajdów) prezentacja od Bassama Tabbary (CTO w Quantum Corp).

Eksploatacja Rook

Operator Rook w pełni wspiera Kubernetes w wersji 1.6 i nowszych (i częściowo, starsze wydanie K8s — 1.5.2). Jego instalacja do w najprostszym scenariuszu wygląda tak:

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

Ponadto, dla operatora Rook przygotowano Helm chart, dzięki czemu instalacja może być przeprowadzona także w ten sposób:

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

Istnieje niewiele opcji konfiguracji (na przykład, można wyłączyć wsparcie , jeśli ta możliwość nie jest używana w Twoim klastrze), które są przekazywane w RBACprzez parametr helm install --set key=value[,key=value] (lub przechować w osobnym pliku YAML i przekazywać — przez -f values.yaml Po zainstalowaniu operatora Rook i uruchomieniu podów z jego agentami, należy stworzyć sam klaster Rook, którego najprostsza konfiguracja wygląda następująco ().

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

: szczególną uwagę należy zwrócić na atrybut

UwagadataDirHostPath dataDirHostPath, którego prawidłowa wartość jest niezbędna do zachowania klastra po ponownych uruchomieniach. W przypadkach, gdy jest używany jako stałe miejsce przechowywania danych, autorzy Rook na hostach Kubernetes zalecają posiadanie co najmniej 5 GB wolnego miejsca na dysku w tym katalogu.

Następnie należy stworzyć klaster z konfiguracji i upewnić się, że pody zostały utworzone w klastrze (w przestrzeni nazw 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

Ulepszenie aktualizacja klastra Rook (do nowej wersji) — to procedura, która na tym etapie wymaga sekwencyjnego aktualizowania wszystkich jego komponentów w określonej kolejności, a można ją rozpocząć dopiero po upewnieniu się, że obecna instalacja Rook jest w pełni „zdrowa”. Szczegółową instrukcję krok po kroku na przykładzie aktualizacji Rook z wersji 0.5.0 do 0.5.1 można znaleźć w dokumentacji projektu.

W listopadzie ubiegłego roku na blogu Rook opublikowano porównanie wydajności z EBS. Jego wyniki zasługują na uwagę, a w skrócie wyglądają następująco:

Perspektywy

Aktualny status Rook — alpha, a ostatnim dużym wydaniem na dzień dzisiejszy jest wersja 0.6, wydana w listopadzie 2017 roku (aktualna poprawka — v0.6.2 — została wydana 14 grudnia). Już w pierwszej połowie 2018 roku spodziewane są wydania bardziej dojrzałych wersji: beta i stabilna (oficjalnie gotowa do użycia w produkcji).

Zgodnie z roadmap projektu, deweloperzy mają szczegółową wizję rozwoju Rook co najmniej w dwóch najbliższych wersjach: 0.7 (jego gotowość w trackerze GitHub jest oceniany to 60 %) i 0.8. Wśród oczekiwanych zmian są: przejście wsparcia dla Ceph Block i Ceph Object do statusu wersji beta, dynamiczne provisioning tomów dla CephFS, rozwinięty system logowania, zautomatyzowane aktualizacje klastra, wsparcie dla zrzutów (snapshotów) dla tomów.

Przyjęcie Rook do grona projektów CNCF (na razie na najwcześniejszym etapie — „inception-level”, — obok linkerd i CoreDNS) jest swoistą gwarancją rosnącego zainteresowania produktem. Jak dobrze się zadomowi w świecie aplikacji chmurowych, stanie się jasne dopiero po wydaniu wersji stabilnych, które bez wątpienia przyciągną nowych „testerów” i użytkowników Rook.

P.S.

Przeczytaj także na naszym blogu:

• «Tworzymy stałe przechowywanie z provisioningiem w Kubernetes na bazie Ceph»;
• «Zalety i wady HugePages»;
• «CoreDNS — serwer DNS dla świata cloud native i Service Discovery dla Kubernetes»;
• «Container Networking Interface (CNI) — interfejs sieciowy oraz standard dla kontenerów Linux»;
• «Infrastruktura Kubernetes jako usługa dostępna».

Źródło: habr.com