Стадия жизненного цикла модуля: Общедоступная версия

У модуля есть требования для установки

Как получить список томов RBD, разделенный по узлам?

Для мониторинга и диагностики полезно знать, какие RBD-тома подключены к каждому узлу кластера. Следующая команда позволяет получить детальную информацию о маппинге томов:

d8 k -n d8-csi-ceph get po -l app=csi-node-rbd -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName --no-headers \
  | awk '{print "echo "$2"; kubectl -n d8-csi-ceph exec  "$1" -c node -- rbd showmapped"}' | bash

Какие версии Ceph кластеров поддерживаются

Модуль csi-ceph имеет определенные требования к версии Ceph-кластера для обеспечения совместимости и стабильной работы. Официально поддерживаются версии Ceph >= 16.2.0. На практике текущая версия модуля обычно работает и с кластерами >= 14.2.0, но для надёжной эксплуатации рекомендуется обновить Ceph до актуальной поддерживаемой версии.

Какие режимы работы томов поддерживаются

Различные типы хранилища Ceph поддерживают разные режимы доступа к томам, что важно учитывать при планировании архитектуры приложений.

  • RBD — поддерживает только ReadWriteOnce (RWO) — доступ к тому только с одного узла кластера.
  • CephFS — поддерживает ReadWriteOnce (RWO) и ReadWriteMany (RWX) — одновременный доступ к тому с нескольких узлов кластера.

Разрешения (caps) для пользователей в Ceph

Для обеспечения корректной работы модуля csi-ceph пользователи Ceph должны иметь соответствующие разрешения (caps). Необходимые разрешения зависят от используемого типа хранилища. Ниже приведены примеры правильных конфигураций разрешений для различных сценариев.

RBD

Для одного пула с названием rbd требуются следующие разрешения:

[client.name]
        key = key
        caps mgr = "profile rbd pool=rbd"
        caps mon = "profile rbd"
        caps osd = "profile rbd pool=rbd"

CephFS

Перед настройкой разрешений CephFS убедитесь, что в CephFS создан subvolumegroup csi (или другой, указанный в Custom resources).

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

ceph fs subvolumegroup create <fs_name> <group_name>

Например, для создания subvolumegroup csi для файловой системы myfs:

ceph fs subvolumegroup create myfs csi

Требуемые разрешения для CephFS с названием myfs:

[client.name]
        key = key
        caps mds = "allow rwps fsname=myfs"
        caps mgr = "allow rw"
        caps mon = "allow r fsname=myfs"
        caps osd = "allow rw tag cephfs data=myfs, allow rw tag cephfs metadata=myfs"

CephFS + RBD

Для пользователя, которому необходим доступ к CephFS myfs и RBD пулу rbd, объедините разрешения следующим образом:

[client.name]
        key = key
        caps mds = "allow rwps fsname=myfs"
        caps mgr = "allow rw,profile rbd pool=rbd"
        caps mon = "allow r fsname=myfs,profile rbd"
        caps osd = "allow rw tag cephfs metadata=myfs, allow rw tag cephfs data=myfs,profile rbd pool=rbd"

Сколько места тома резервируется под суперпользователя?

По умолчанию — нисколько: RBD-образ с ext4 форматируется с -m0, весь объём тома доступен нагрузке.

Если классический 5-процентный резерв ext4 всё же нужен — например, чтобы привилегированный процесс мог писать в файловую систему после того, как нагрузка заняла её целиком, — задайте процент аннотацией на ресурсе CephStorageClass:

d8 k annotate cephstorageclass <name> storage.deckhouse.io/ext4-reserved-percent=5

Значение — целое число процентов от 0 до 50; при некорректном значении CephStorageClass переходит в фазу Failed с причиной в conditions, а не ломает создание томов позже.

Резерв применяется только к томам, созданным после установки аннотации: уже существующие файловые системы сохраняют тот резерв, с которым были созданы. Аннотация имеет смысл только для RBD: тома CephFS — это подкаталоги уже существующей файловой системы, они не форматируются, поэтому на классе CephFS аннотация игнорируется. Не действует она и на тома с defaultFSType: xfs — XFS не резервирует блоки под суперпользователя.

Изменение аннотации приводит к пересозданию StorageClass контроллером, поскольку поле parameters у существующего StorageClass в Kubernetes иммутабельно. На уже созданные тома и PVC это не влияет.

Почему не удаляется CephClusterConnection?

CephClusterConnection хранит Secret с пользователем, от имени которого созданы её тома, и Kubernetes читает этот Secret, чтобы подключить, отключить, смонтировать, расширить и удалить такие тома. Если удалить подключение раньше, тома застрянут: например, том уже не удастся отключить от узла. Поэтому подключение и его Secret остаются, пока они нужны хотя бы одному PersistentVolume. Условие Ready при этом False с причиной PersistentVolumesExist, в нём указано число таких PersistentVolume и имена первых десяти:

d8 k get cephclusterconnection <name> -o jsonpath='{.status.conditions[?(@.type=="Ready")].message}'

PersistentVolume удерживает подключение, пока он подключён к узлу, пока он в состоянии Bound или ещё не привязан к PVC, а в состоянии Released или Failed с политикой Delete — пока том не будет удалён. PersistentVolume в состоянии Released или Failed с политикой Retain, не подключённый ни к одному узлу, подключение не удерживает: без подключения им уже не воспользоваться, поэтому удалите его вручную, когда данные станут не нужны.

Снапшоты тоже удерживают подключение: Secret нужен, чтобы удалить снапшот, поэтому VolumeSnapshotContent с политикой удаления Delete удерживает подключение, пока он не будет удалён. Если остались только снапшоты, причина — VolumeSnapshotContentsExist, а в сообщении названы до десяти VolumeSnapshotContent. Чтобы подключение удалилось, удалите их VolumeSnapshot.

Что означает условие ClusterConfigConflict у CephClusterConnection?

ceph-csi хранит в своей конфигурации одну запись на кластер Ceph. В ней лежат пользователь одного CephClusterConnection для RBD и группа subvolume одного подключения для CephFS. Если на один кластер указывают несколько подключений, некоторым томам может понадобиться не то, что записано. Это тома RBD, созданные до того, как csi-ceph стал класть секрет для отключения в PersistentVolume, если у их подключения другой пользователь, и тома CephFS, лежащие в другой группе subvolume. Такой том RBD не отключается от узла, а такой том CephFS монтируется, но его уже нельзя удалить, расширить или снять с него снапшот.

ClusterConfigConflict=True у подключения перечисляет такие тома и называет подключение, чьи настройки хранит запись. Все затронутые подключения можно найти так:

d8 k get cephclusterconnection -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="ClusterConfigConflict")].status}{"\t"}{.status.conditions[?(@.type=="ClusterConfigConflict")].message}{"\n"}{end}' | awk -F'\t' '$2 == "True"'

Запись хранит настройки того подключения, чьи тома от неё зависят, поэтому условие держится, пока перечисленные тома не будут удалены. Новые тома RBD от записи не зависят. Для CephFS используйте одну группу subvolume на кластер Ceph во всех его подключениях.

Секрет существующего PersistentVolume поменять нельзя: spec.csi у PersistentVolume неизменяем. Чтобы перечисленные тома RBD отключались, дайте пользователю Ceph того подключения, чьи настройки хранит запись, доступ к их пулам. ceph auth caps заменяет все права пользователя, поэтому сначала прочитайте текущие и повторите их:

ceph auth get client.<пользователь подключения, чьи настройки хранит запись>
ceph auth caps client.<пользователь> mon '<текущие права mon>' osd '<текущие права osd>, profile rbd pool=<пул перечисленных томов>'

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