shurup Feb 1 2018 at 10:40

Rook — «самообслуживаемое» хранилище данных для Kubernetes

5 min

14K

Флант corporate blogSystem administration*Data storage*DevOps*Kubernetes*

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

Что за Rook?

Rook — это написанное на Go программное обеспечение (распространяется по свободной лицензии Apache License 2.0), предназначенное для наделения хранилищ данных автоматизированными функциями, которые делают их самоуправляемыми, самомасштабируемыми и самовосстановливающимися. Для этого Rook автоматизирует (для хранилищ данных, применяемых в окружении Kubernetes): развёртывание, bootstrapping, конфигурацию, provisioning, масштабирование, обновления, миграции, восстановление после сбоев, мониторинг и управление ресурсами.

Проект находится в альфа-стадии и специализируется на оркестровке распределённой системы хранения данных Ceph в кластерах Kubernetes. Авторы заявляют также о планах по поддержке других систем хранения, но это случится не в ближайших релизах.

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

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

Итак, оператор Rook представляется контейнером, который содержит всё необходимое для развёртывания и последующего обслуживания хранилища. Среди обязанностей оператора:

создание DaemonSet для демонов хранения Ceph (ceph-osd) с простым кластером RADOS;
создание подов для мониторинга Ceph (с ceph-mon, проверяющими состояние кластера; для кворума в большинстве случаев разворачиваются три экземпляра, и при падении любого из них поднимается новый);
управление CRDs (Custom Resource Definitions) для самого кластера, пулов хранения, object stores (наборов ресурсов и сервисов для обслуживания 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 chart, благодаря чему инсталляция может проводиться и так:

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, корректное значение которого необходимо для сохранения кластера после перезагрузок. Для случаев его использования как постоянного места хранения данных Rook на хостах Kubernetes авторы рекомендуют иметь в этом каталоге хотя бы 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 оценивается как 60 %) и 0.8. Среди ожидаемых изменений — перевод поддержки Ceph Block и Ceph Object в статус бета-версии, динамический provisioning томов для CephFS, развитая система логирования, автоматизированные обновления кластера, поддержка снапшотов для томов.

Принятие Rook в число проектов CNCF (пока что на самом раннем этапе — «inception-level», — наравне с linkerd и CoreDNS) является своеобразной гарантией растущего интереса к продукту. Насколько он закрепится в мире облачных приложений, станет лучше ясно после появления стабильных версий, которые, безусловно, принесут Rook новых «испытателей» и пользователей.

P.S.

Читайте также в нашем блоге:

Tags:

Hubs: