Container Storage Interface (CSI) — это унифицированный интерфейс взаимодействия Kubernetes и систем хранения данных. Вкратце о нём мы уже рассказывали, а сегодня подробнее рассмотрим связку CSI и Ceph: покажем, как подключить хранилище Ceph к кластеру Kubernetes.
В статье приведены реальные, хотя и немного упрощённые для удобства восприятия примеры. Установку и настройку кластеров Ceph и Kubernetes не рассматриваем.

Вам интересно, как это работает?

Итак, у вас под рукой есть кластер Kubernetes, развернутый, к примеру, kubespray. Рядом работает кластер Ceph — его можно также поставить, например, вот этим набором плейбуков. Надеюсь, не нужно упоминать, что для продакшена между ними должна быть сеть с пропускной способностью не менее 10 Гбит/с.

Если всё это у вас есть, поехали!

Сначала зайдем на одну из нод кластера Ceph и проверяем, что всё в порядке:

ceph health
ceph -s

Далее тут же создадим пул для RBD дисков:

ceph osd pool create kube 32
ceph osd pool application enable kube rbd

Переходим в кластер Kubernetes. Там первым делом установим Ceph CSI драйвер для RBD. Ставить будем, как и положено, через Helm.
Добавляем репозиторий с чартом, получаем набор переменных чарта ceph-csi-rbd:

helm repo add ceph-csi https://ceph.github.io/csi-charts
helm inspect values ceph-csi/ceph-csi-rbd > cephrbd.yml

Теперь нужно заполнить файл cephrbd.yml. Для этого узнаем ID кластера и IP-адреса мониторов в Ceph:

ceph fsid  # так мы узнаем clusterID
ceph mon dump  # а так увидим IP-адреса мониторов

Полученные значения заносим в файл cephrbd.yml. Попутно включаем создание политик PSP (Pod Security Policies). Опции в разделах nodeplugin и provisioner уже есть в файле, их можно исправить так, как показано ниже:

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "v2:172.18.8.5:3300/0,v1:172.18.8.5:6789/0"
      - "v2:172.18.8.6:3300/0,v1:172.18.8.6:6789/0"
      - "v2:172.18.8.7:3300/0,v1:172.18.8.7:6789/0"

nodeplugin:
  podSecurityPolicy:
    enabled: true

provisioner:
  podSecurityPolicy:
    enabled: true

Далее всё что нам остаётся — установить чарт в кластер Kubernetes.

helm upgrade -i ceph-csi-rbd ceph-csi/ceph-csi-rbd -f cephrbd.yml -n ceph-csi-rbd --create-namespace

Отлично, RBD драйвер работает!
Создадим в Kubernetes новый StorageClass. Для этого снова потребуется немного поработать с Ceph.

Создаём нового пользователя в Ceph и выдаём ему права на запись в пул kube:

ceph auth get-or-create client.rbdkube mon 'profile rbd' osd 'profile rbd pool=kube'

А теперь посмотрим ключ доступа всё там же:

ceph auth get-key client.rbdkube

Команда выдаст нечто подобное:

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

Занесём это значение в Secret в кластере Kubernetes — туда, где нужен userKey:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Значения ключей соответствуют имени пользователя и его ключу, как указано в
  # кластере Ceph. ID юзера должен иметь доступ к пулу,
  # указанному в storage class
  userID: rbdkube
  userKey: <user-key>

И создаём наш секрет:

kubectl apply -f secret.yaml

Далее нам нужен примерно такой манифест StorageClass:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: <cluster-id>
   pool: kube

   imageFeatures: layering

   # Эти секреты должны содержать данные для авторизации
   # в ваш пул.
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-secret
   csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-rbd

   csi.storage.k8s.io/fstype: ext4

reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - discard

Нужно заполнить clusterID, который мы уже узнали командой ceph fsid, и применить этот манифест в кластере Kubernetes:

kubectl apply -f storageclass.yaml

Чтобы проверить работу кластеров в связке, создадим вот такой PVC (Persistent Volume Claim):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc

Сразу посмотрим, как Kubernetes создал в Ceph запрошенный том:

kubectl get pvc
kubectl get pv

Вроде бы всё отлично! А как это выглядит на стороне Ceph?
Получаем список томов в пуле и просматриваем информацию о нашем томе:

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # тут, конечно же, будет другой ID тома, который выдала предыдущая команда

Теперь давайте посмотрим, как работает изменение размера тома RBD.
Изменяем размер тома в манифесте pvc.yaml до 2Gi и применяем его:

kubectl apply -f pvc.yaml

Подождём, пока изменения вступят в силу, и ещё раз посмотрим на размер тома.

rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653

kubectl get pv
kubectl get pvc

Видим, что размер у PVC не изменился. Чтобы узнать причину, можно запросить у Kubernetes описание PVC в формате YAML:

kubectl get pvc rbd-pvc -o yaml

А вот и проблема:

message: Waiting for user to (re-)start a pod to finish file system resize of volume on node. type: FileSystemResizePending

То есть диск увеличился, а файловая система на нём — нет.
Чтобы увеличить файловую систему, надо смонтировать том. У нас же созданный PVC/PV сейчас никак не используется.

Можем создать тестовый Pod, например вот так:

---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx:1.17.6
      volumeMounts:
        - name: mypvc
          mountPath: /data
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false

И теперь посмотрим на PVC:

kubectl get pvc

Размер изменился, всё в порядке.

В первой части мы работали с блочным устройством RBD (оно так и расшифровывается – Rados Block Device), но так нельзя делать, если требуется одновременная работа с этим диском разных микросервисов. Для работы с файлами, а не с образом диска, намного лучше подходит CephFS.
На примере кластеров Ceph и Kubernetes настроим CSI и остальные необходимые сущности для работы с CephFS.

Получим значения из нужного нам нового Helm-чарта:

helm inspect values ceph-csi/ceph-csi-cephfs > cephfs.yml

Снова нужно заполнить файл cephfs.yml. Как и ранее, помогут команды Ceph:

ceph fsid
ceph mon dump

Заполняем файл со значениями примерно так:

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "172.18.8.5:6789"
      - "172.18.8.6:6789"
      - "172.18.8.7:6789"

nodeplugin:
  httpMetrics:
    enabled: true
    containerPort: 8091
  podSecurityPolicy:
    enabled: true

provisioner:
  replicaCount: 1
  podSecurityPolicy:
    enabled: true

Обратите внимание, что адреса мониторов указываются в простой форме address:port. Для монтирования cephfs на узле эти адреса передаются в модуль ядра, который ещё не умеет работать с протоколом мониторов v2.
Порт для httpMetrics (туда будет ходить Prometheus за метриками для мониторинга) мы меняем для того, чтобы он не конфликтовал с nginx-proxy, который устанавливается Kubespray’ем. Вам это, возможно, не потребуется.

Устанавливаем Helm-чарт в кластер Kubernetes:

helm upgrade -i ceph-csi-cephfs ceph-csi/ceph-csi-cephfs -f cephfs.yml -n ceph-csi-cephfs --create-namespace

Переходим к хранилищу данных Ceph, чтобы создать там отдельного пользователя. В документации указано, что провизионеру CephFS необходимы права доступа администратора кластера. Но мы создадим отдельного пользователя fs с ограниченными правами:

ceph auth get-or-create client.fs mon 'allow r' mgr 'allow rw' mds 'allow rws' osd 'allow rw pool=cephfs_data, allow rw pool=cephfs_metadata'

И сразу же посмотрим его ключ доступа, он нам пригодится далее:

ceph auth get-key client.fs

Создадим отдельные Secret и StorageClass.
Ничего нового, мы это уже видели на примере RBD:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Необходимо для динамически создаваемых томов
  adminID: fs
  adminKey: <вывод предыдущей команды>

Применяем манифест:

kubectl apply -f secret.yaml

А теперь – отдельный StorageClass:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-cephfs-sc
provisioner: cephfs.csi.ceph.com
parameters:
  clusterID: <cluster-id>

  # Имя файловой системы CephFS, в которой будет создан том
  fsName: cephfs

  # (необязательно) Пул Ceph, в котором будут храниться данные тома
  # pool: cephfs_data

  # (необязательно) Разделенные запятыми опции монтирования для Ceph-fuse
  # например:
  # fuseMountOptions: debug

  # (необязательно) Разделенные запятыми опции монтирования CephFS для ядра
  # См. man mount.ceph чтобы узнать список этих опций. Например:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Секреты должны содержать доступы для админа и/или юзера Ceph.
  csi.storage.k8s.io/provisioner-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/controller-expand-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/node-stage-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-cephfs

  # (необязательно) Драйвер может использовать либо ceph-fuse (fuse), 
  # либо ceph kernelclient (kernel).
  # Если не указано, будет использоваться монтирование томов по умолчанию,
  # это определяется поиском ceph-fuse и mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

Заполним тут clusterID и применим в Kubernetes:

kubectl apply -f storageclass.yaml

Проверка

Для проверки, как и в прошлом примере, создадим PVC:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-cephfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: csi-cephfs-sc

И проверим наличие PVC/PV:

kubectl get pvc
kubectl get pv

Если хочется посмотреть на файлы и каталоги в CephFS, можно примонтировать эту файловую систему куда-нибудь. Например, как показано ниже.

Сходим на одну из нод кластера Ceph и выполним такие действия:

# Точка монтирования
mkdir -p /mnt/cephfs

# Создаём файл с ключом администратора
ceph auth get-key client.admin >/etc/ceph/secret.key

# Добавляем запись в /etc/fstab
# !! Изменяем ip адрес на адрес нашего узла
echo "172.18.8.6:6789:/ /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev    0       2" >> /etc/fstab

mount /mnt/cephfs

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

Ну и напоследок давайте проверим, как в случае с CephFS обстоят дела с изменением размеров тома. Возвращаемся в Kubernetes и отредактируем наш манифест для PVC — увеличим там размер, к примеру, до 7Gi.

Применим отредактированный файл:

kubectl apply -f pvc.yaml

Посмотрим на примонтированном каталоге, как изменилась квота:

getfattr -n ceph.quota.max_bytes <каталог-с-данными>

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

Глаза боятся, а руки делают

С виду все эти заклинания и длинные манифесты YAML кажутся сложными, но на практике студенты Слёрма разбираются с ними довольно быстро.
В этой статье мы не углублялись в дебри — для этого есть официальная документация. Если вас интересуют детали настройки хранилища Ceph совместно с кластером Kubernetes, помогут вот эти ссылки:

Общие принципы работы Kubernetes c томами
Документация по RBD
Интеграция RBD и Kubernetes с точки зрения Ceph
Интеграция RBD и Kubernetes с точки зрения CSI
Общая документация по CephFS
Интеграция CephFS и Kubernetes с точки зрения CSI

На курсе Слёрм Kubernetes База вы можете пойти ещё чуть дальше и развернуть в Kubernetes реальное приложение, которое будет использовать CephFS в качестве хранилища для файлов. Посредством GET/POST запросов вы сможете передавать файлы и получать их из Ceph.

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

Автор статьи: Александр Швалов, практикующий инженер Southbridge, Certified Kubernetes Administrator, автор и разработчик курсов Слёрм.