🥇Rook — „самообслужващо“ хранилище за данни за Kubernetes

На 29 януари техническият комитет на организацията CNCF (Cloud Native Computing Foundation), отговорна за Kubernetes, Prometheus и други Open Source продукти от света на контейнерите и cloud native, обяви одобри проекта Rook в своите редици. Отлична възможност да се запознаете по-добре с този „оркестрационен инструмент за разпределено съхранение на данни в Kubernetes“.

Какво е Rook?

Rook — това е софтуер, написан на Go (разпространява със свободна лицензия Apache License 2.0), предназначен да предоставя автоматизирани функции на системите за съхранение на данни, които ги правят самоуправляеми, самомащабируеми и самовъзстановяващи се.За целта Rook автоматизира (за системите за съхранение на данни, използвани в okолната среда на Kubernetes): внедряване, bootstrapping, конфигурация, provisioning, мащабиране, актуализации, миграции, възстановяване след сривове, наблюдение и управление на ресурсите.

Проектът е в alpha фаза и специализирана в оркестрацията на разпределена система за съхранение на данни Ceph в Kubernetes клъстери. Авторите също така заявяват намерения да поддържат и други системи за съхранение, но това няма да се случи в близките версии.

Компоненти и техническа структура

В основата на работата на Rook в Kubernetes е специален оператор (повече за Kubernetes оператори сме писали в тази статия), който автоматизира конфигурацията на хранилището и реализира его наблюдение.

И така, Операторът Rook представлява контейнер, който съдържа всичко необходимо за внедряване и последваща поддръжка на хранителното хранилище. Сред задълженията на оператора:

създаване на DaemonSet за демони за съхранение Ceph (ceph-osd) с прост кластер RADOS;
създаване на подове за наблюдение на Ceph (с ceph-mon, които проверяват състоянието на кластера; за кворума в повечето случаи се внедряват три екземпляра, и при падането на който и да е от тях, се стартира нов);
управление на CRD-та (Custom Resource Definitions) за самия кластер, пула за съхранение, обектни хранилища (набори от ресурси и услуги за обслужване на HTTP заявки, които изпълняват PUT/GET за обекти, — те са съвместими с S3 и Swift API), както и файлови системи;
инициация на подовете за стартиране на всички необходими услуги;
създаване на агенти Rook.

Агентите Rook са представени от отделни подове, които се внедряват на всеки възел на Kubernetes. Целта на агента е конфигуриране на плъгина FlexVolume, осигуряващ поддръжка на хранилища в Kubernetes. Агента реализира експлоатацията на хранилището: свързва мрежови устройства за съхранение, монтира томове, форматира файловата система и т.н.

Място и роля на компонентите Rook в общата схема на кластер Kubernetes

Rook предлага три вида хранилища:

блоково (Block, StorageClass) — монтира хранилището към единствен под;
обектно (Object, ObjectStore) — достъпно вътре и извън кластера Kubernetes (по S3 API);
споделена ФС (Shared File System, Filesystem) — файловата система, която може да се монтира за четене и писане от множество подове.

Вътрешното устройство на Rook включва:

Mons — подове за мониторинг на Ceph (с вече споменатите ceph-mon);
OSDs — подове с демони ceph-osd (Object Storage Daemons);
MGR — подове с демона ceph-mgr (Ceph Manager), предоставящ допълнителни възможности за мониторинг и интерфейси за външни системи (мониторинг/управление);
RGW (по желание) — подове с обектно хранилище;
MDS (по желание) — подове с споделена ФС.

Всички демони Rook (Mons, OSDs, MGR, RGW, MDS) са компилирани в един бинарен файл (rook), стартиращ в контейнер.

За кратко представяне на проекта Rook може да се ползва и тази малка (12 слайда) презентация от Bassam Tabbara (CTO в Quantum Corp).

Експлоатация на Rook

Операторът Rook напълно поддържа Kubernetes версии 1.6 и по-високи (и частично, по-стара версия K8s — 1.5.2). Неговата инсталация в в най-простия сценарий изглежда така:

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

Освен това, за оператора Rook е подготвена Helm карта, благодарение на която инсталацията може да се извърши и така:

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

Има малко количество опции за настройка (например, може да деактивирате поддръжката RBAC, ако тази функция не се използва в вашия кластер), които се предават в helm install чрез параметър --set key=value[,key=value] (или да се съхранят в отделен YAML файл и да се предадат — чрез -f values.yaml).

След инсталирането на оператора Rook и стартирането на подовете с неговите агенти, остава да се създаде самият кластер Rook, най-простата конфигурация на който изглежда по следния начин (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

Забележка: специално внимание трябва да се обърне на атрибута dataDirHostPath, чиято правилна стойност е необходима за поддържането на клъстера след рестартирания. В случаите, в които той се използва като постоянно място за съхранение на данни, авторите препоръчват в тази директория да има поне 5 ГБ свободно дисково пространство.

Остава да се създаде клъстер от конфигурацията и да се уверим, че подовете са създадени в клъстера (в пространството на имената 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

Актуализация на клъстера Rook (до нова версия) е процедура, която в момента изисква поетапно обновление на всички компоненти в определена последователност, и може да бъде започната само след като сте се уверили в напълно „здравословно“ състояние на текущата инсталация на Rook. Подробна стъпка по стъпка инструкция за актуализиране на Rook версия 0.5.0 до 0.5.1 може да бъде намерена в документацията на проекта.

През ноември миналата година в блога на Rook беше публикувано сравнение производителност с EBS. Резултатите от него заслужават внимание, а ако трябва да обобщим, те са следните:

Перспективи

Текущият статус на Rook е alpha, а последният голям релиз до момента е версия 0.6, издадена през ноември 2017 година (актуализацията е v0.6.2 — излязла на 14 декември). Още през първата половина на 2018 година се очакват релизи на по-зрели версии: бета и стабилна (официално готова за употреба в production).

Според roadmap на проекта, разработчиците имат подробна представа за развитието на Rook поне в две предстоящи релиза: 0.7 (готовността му в GitHub tracker се оценява като 60 %) и 0.8. Сред очакваните промени — прехвърляне на поддръжката на Ceph Block и Ceph Object в статус бета версия, динамично предоставяне на томове за CephFS, разширена система за логиране, автоматизирани актуализации на клъстера, поддръжка на снимки за томове.

Приемането на Rook в числото на проектите на CNCF (все още на много ранен етап — "inception-level", — наред с linkerd и CoreDNS) е своеобразна гаранция за растящия интерес към продукта. Колко стабилно ще се утвърди в света на облачните приложения, ще стане ясно след появата на стабилни версии, които без съмнение ще донесат нови „тестери“ и потребители на Rook.

P.S.

Прочетете също в нашия блог:

Източник: habr.com