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

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

Какъв топ?

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

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

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

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

По този начин, Топ оператор изглежда като контейнер, който съдържа всичко необходимо за внедряване и последваща поддръжка на хранилището. Отговорностите на оператора включват:

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

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

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

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

блок (Блок, StorageClass) — монтира хранилището към едно огнище;
обект (Обект, ObjectStore) - достъпно вътре и извън клъстера Kubernetes (чрез S3 API);
споделена файлова система (Споделена файлова система, Filesystem) е файлова система, която може да се монтира за четене и запис от множество подове.

Вътрешните части на топа включват:

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

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

За кратко въведение в проекта Rook, това кратко (12 слайда) също може да бъде полезно. представяне от Басам Таббара (технически директор в Quantum Corp).

Управление на топа

Операторът 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 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 и стартирате pods с неговите агенти, всичко, което остава, е да създадете самия клъстер 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, чиято правилна стойност е необходима за запазване на клъстера след рестартиране. За случаите, когато се използва като постоянно място за съхранение на Rook данни на Kubernetes хостове, авторите препоръчват да имате поне 5 GB свободно дисково пространство в тази директория.

Всичко, което остава, е всъщност да създадете клъстера от конфигурацията и да се уверите, че подовете са създадени в клъстера (в пространството на имената 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 cluster (до нова версия) е процедура, която на този етап изисква последователно актуализиране на всичките му компоненти в определена последователност и можете да я стартирате само след като сте се уверили, че текущата инсталация на Rook е в напълно „здравословно“ състояние. състояние. Подробни инструкции стъпка по стъпка, като използвате примера за актуализиране на Rook версия 0.5.0 до 0.5.1, можете да намерите в проектна документация.

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

Перспективи

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

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

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