☸️ Распределенное хранение данных в Kubernetes

by itisgood

Kubernetes отлично подходит для приложений без учета их состояния.

Разверните свое приложение, масштабируйте его до сотен экземпляров, будьте счастливы.

Но как вы управляете хранилищем?

Как мы можем гарантировать, что каждое из наших сотен приложений получит надежное, быстрое и дешевое хранилище?

Давайте возьмем типичный кластер Kubernetes с несколькими узлами (серверами Linux), которые обеспечивают несколько копий нашего приложения:

Обратите внимание на наши грустные, неиспользованные диски!
Kubernetes, безусловно, приносит много побед, но разве мы больше являемся системными администраторами, если не управляем огромными RAID-массивами?

Persistent Volume Claims

В Kubernetes мы определяем PersistentVolumeClaims, чтобы запросить нашу систему хранения.

Проще говоря, приложение «требует» немного памяти, и система отвечает настраиваемым способом:

App1 – > VolumeClaim

К сожалению, большинство облачных провайдеров стремятся использовать простоту Kubernetes, «отвечая» на ваш запрос хранилища, подключая Cloud Storage (например, Amazon EBS).
У этой стратегии есть ряд недостатков для потребителей:
  • Производительность и стоимость: производительность томов EBS (и других поставщиков облачных вычислений) зависит от его размера – это означает, что меньший диск – это то же самое, что и более медленный диск.
  • Характеристики: поставщики облачных услуг обычно предлагают жесткие диски, SDD и опцию «подготовленного ввода-вывода». Это ограничивает системных администраторов в их системах хранения. Где находится резервная копия? А как насчет NVMe? Как диск подключен к серверу, на котором работает мой код?
  • Переносимость / блокировка: EBS – это EBS, а постоянные диски Google – это постоянные диски Google. Поставщики облачных услуг настойчиво пытаются привязать вас к своим платформам и обычно прячут инструменты файловой системы, которые мы знаем и любим за облачной системой моментальных снимков.
Итак … Что нам тогда нужно, так это система управления хранилищем данных с открытым исходным кодом, которая будет работать в любом кластере Kubernetes и может преобразовывать кучи дисков в пулы хранения, доступные для наших подов!

Введите Rook.io

Что такое Rook?
С веб-сайта Rook:
Облачное хранилище с открытым исходным кодом для Kubernetes» с «Хранилищем готовых файлов, блоков и объектов».
Если говорить о маркетинге, Rook – это версия AWS EBS и S3 с открытым исходным кодом, которую вы можете установить в свои кластеры.
Это также бэкэнд для системы хранения KubeSail, и именно так мы создаем RAID-массивы для поддержки приложений наших пользователей!

Rook и Ceph

Rook – это система, которая находится в вашем кластере и отвечает на запросы на хранение, но сама она не является системой хранения.

Хотя это немного усложняет ситуацию, вы должны чувствовать себя хорошо, потому что, хотя Rook и новичок, система хранения, которую он использует под капотом, закалена и далека от бета-тестирования.

Мы будем использовать Ceph, которому около 15 лет, который используется и разрабатывается такими компаниями, как Canonical, CERN, Cisco, Fujitsu, Intel, Red Hat и SanDisk.

Это очень далеко от Kubernetes-Hipster, несмотря на то, как круто выглядит проект Rook!

Учитывая, что Rook версии 1.0 и Ceph поддерживают некоторые из самых важных в мире наборов данных, я бы сказал, что настало время обрести уверенность и вернуть контроль над нашим хранилищем данных!

Я буду строить RAID-массивы в 2020-х годах, и никто не сможет меня остановить!

Установка

Я не буду концентрироваться на первоначальной установке здесь, так как руководство по Rook простое.

После установки Rook мы создадим несколько компонентов:

  • CephCluster, который отображает узлы и их диски в нашу новую систему хранения.
  • CephBlockPool, который определяет, как хранить данные, включая количество реплик, которые мы хотим.
  • StorageClass, который определяет способ использования хранилища из CephBlockPool.

Давайте начнем с CephCluster:

#?filename=ceph-cluster.yaml&mini=true&noApply=true
---
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  mon:
    count: 3
    allowMultiplePerNode: false
  storage:
    useAllNodes: false
    useAllDevices: true
    location:
    config:
      osdsPerDevice: "1"
    directories:
      - path: /opt/rook
    nodes:
    - name: "my-storage-node-1"
    - name: "my-storage-node-2"
    - name: "my-storage-node-3"
Здесь важно отметить, что CephCluster – это, по сути, карта, на которой показаны ноды и какие диски или каталоги на этих узлах будут использоваться для хранения данных.
Многие учебные пособия будут предлагать useAllNodes:true, что мы настоятельно не рекомендуем.
Вместо этого мы рекомендуем управлять меньшим пулом поднаборов «storage workers» – это позволяет позже использовать различные типы систем (например, очень медленные диски) без случайного / неосознанного добавления его в пул хранения.
Мы будем предполагать, что /opt/rook является точкой монтирования, но Rook может использовать неформатированные диски, а также каталоги.
Еще одно замечание: mon – система мониторинга Rook.
Мы настоятельно рекомендуем запускать по крайней мере три и гарантировать, что allowMultiplePerNode имеет значение false.
Теперь наш кластер выглядит так:
Кстати, вы наверняка захотите взглянуть на поды, работающие в пространстве имен rook-ceph!
Вы найдете свои OSD (Object-Storage-Device) поды, а также поды мониторинга и агента, живущие в этом пространстве имен.
Давайте создадим наш CephBlockPool и StorageClass, который он использует:
#?filename=ceph-blockpool.yaml&mini=true&noApply=true
---
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: my-storage-pool
  namespace: rook-ceph
spec:
  failureDomain: osd
  replicated:
    size: 2
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage
provisioner: rook.io/block
parameters:
  pool: my-storage-pool
Обратите внимание, что replicated size установлен в занчение 2, что означает, что у нас будет 2 копии всех наших данных.

Мы подождем, пока наш CephCluster будет установлен – а вы уже можете взглянуть на созданный вами объект CephCluster:

➜ kubectl -n rook-ceph get cephcluster rook-ceph -o json | jq .status.ceph.health
"HEALTH_OK"
Теперь мы готовы сделать запрос на хранение!
Теперь мы можем запросить хранилище несколькими стандартными способами.

#?filename=ceph-pvc.yaml&mini=true&noApply=true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-data
spec:
  accessModes:
    - ReadWriteOnce
  # Use our new ceph storage:
  storageClassName: my-storage
  resources:
    requests:
      storage: 1000Mi
Теперь Rook увидит наш PersistentVolumeClaim и создаст для нас PersistentVolume! Давайте взглянем:

➜ kubectl get pv --watch
NAME     CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM              STORAGECLASS    AGE
pvc-...  1000Mi    RWO           Delete          Bound   default/test-data  my-storage      13m
Итак, поехали!
Удобная, довольно простая в использовании, нативная система хранения Kubernetes.
Мы можем принести свои собственные диски, мы можем использовать любой облачный провайдер … Свобода!

You may also like

Leave a Comment