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, автор и разработчик курсов Слёрм.
ссылка на оригинал статьи https://habr.com/ru/company/southbridge/blog/519642/
Добавить комментарий