Стадия жизненного цикла модуля: General Availability

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

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

Для этого необходимо проверить состояние подов в неймспейсе d8-csi-nfs. Все поды должны быть в состоянии Running или Completed и запущены на всех узлах. Проверьте командой:

d8 k -n d8-csi-nfs get pod -owide -w

Возможно ли изменение параметров NFS-сервера уже созданных PV?

Нет, данные для подключения к NFS-серверу сохраняются непосредственно в манифесте PV, и не подлежат изменению. Изменение StorageClass также не повлечёт изменений настроек подключения в уже существующих PV.

Как делать снимки томов?

Перед созданием снимков ознакомьтесь с ограничениями в разделе «Создание снимков томов».

В csi-nfs снимки создаются путём архивирования директории тома. Архив сохраняется в корне директории NFS-сервера, указанной в параметре spec.connection.share.

  1. Включите модуль snapshot-controller.

  2. Создайте снимки томов. Для этого выполните следующую команду, указав нужные параметры:

    d8 k apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
  namespace: <имя неймспейса, в котором находится PVC>
spec:
  volumeSnapshotClassName: csi-nfs-snapshot-class
  source:
    persistentVolumeClaimName: <имя PVC, для которого необходимо создать снимок>
EOF

  3. Проверьте состояние созданного снимка командой:

    d8 k get volumesnapshot

Эта команда покажет список всех снимков и их текущее состояние.

Как выбрать метод очистки тома перед удалением PV?

Возможность очистки тома доступна только в коммерческих редакциях Deckhouse Kubernetes Platform.

На удаляемом томе могут остаться файлы с пользовательскими данными. Эти файлы будут удалены и не будут доступны другим пользователям через NFS.

Однако данные удалённых файлов могут оказаться доступными другим клиентам, если сервер предоставит доступ к своему хранилищу на уровне блочных устройств.

Выбрать метод очистки тома перед удалением поможет параметр volumeCleanup.

Эта опция не влияет на файлы, уже удалённые клиентским приложением.

Эта опция влияет только на команды, отправляемые по протоколу NFS. Выполнение этих команд на стороне сервера определено:

  • сервисом NFS-сервера;
  • файловой системой;
  • уровнем блочных устройств и их виртуализации (например, LVM);
  • самими физическими устройствами.

Убедитесь в доверенности сервера. Не отправляйте деликатные данные на серверы, в которых нет уверенности.

Метод SinglePass

Используется, если для параметра volumeCleanup задано значение RandomFillSinglePass.

Содержимое файлов переписывается случайной последовательностью перед удалением. Случайная последовательность передаётся по сети.

Метод ThreePass

Используется, если для параметра volumeCleanup задано значение RandomFillThreePass.

Содержимое файлов трижды переписывается случайной последовательностью перед удалением. Три случайных последовательности передаются по сети.

Метод Discard

Используется, если для параметра volumeCleanup задано значение Discard.

Многие файловые системы реализуют поддержку твердотельных накопителей, позволяя освободить место, занятое файлом, на блочном уровне без записи новых данных для увеличения срока службы твердотельного накопителя. Однако не все накопители гарантируют недоступность данных освобождённых блоков.

Если для volumeCleanup установлено значение Discard, содержимое файлов помечается как свободное через системный вызов falloc с флагом FALLOC_FL_PUNCH_HOLE. Файловая система освободит полностью используемые файлом блоки через вызов blkdiscard, а остальное место будет перезаписано нулями.

Преимущества этого метода:

  • объём трафика не зависит от размера файлов, а только от их количества;
  • метод может обеспечить недоступность старых данных при некоторых конфигурациях сервера;
  • работает как для жёстких дисков, так и для твердотельных накопителей;
  • позволяет увеличить время жизни твердотельного накопителя.

Почему не удаляются PV, созданные в StorageClass с поддержкой RPC-with-TLS, а вместе с ними и каталоги <имя PV> на NFS-сервере?

Если ресурс NFSStorageClass был настроен с поддержкой RPC-with-TLS, может возникнуть ситуация, когда PV не удастся удалить. Это происходит из-за удаления секрета (например, после удаления NFSStorageClass), который хранит параметры монтирования. В результате контроллер не может смонтировать NFS-директорию для удаления директории <имя PV>.

Как в настройках ModuleConfig в параметре tlsParameters.ca разместить несколько CA?

Объедините сертификаты в один файл и закодируйте результат в Base64. Примеры:

  • Два CA
  • Три CA
cat CA1.crt CA2.crt | base64 -w0
cat CA1.crt CA2.crt CA3.crt | base64 -w0

Какие требования к дистрибутиву Linux для развёртывания NFS-сервера с поддержкой RPC-with-TLS?

Для развёртывания NFS-сервера с поддержкой RPC-with-TLS дистрибутив должен удовлетворять следующим требованиям:

  • Ядро должно быть собрано с включёнными параметрами CONFIG_TLS и CONFIG_NET_HANDSHAKE;
  • Пакет nfs-utils (в дистрибутивах основанных на Debian - nfs-common) должен быть >= 2.6.3.

Что произойдет, если репозитории узла не могут предоставить rpcbind и nfs-utils?

Модуль сам установит два нужных ему демона, из собственного образа.

От узла модулю требуется меньше, чем кажется. Контейнер csi-nfs монтирует экспорт своим собственным nfs-utils, поэтому клиентские утилиты на хосте не нужны. Но монтирование NFSv3 регистрируется в хостовом портмаппере, а блокировки идут через хостовый rpc.statd. Эти два демона — обязанность хоста, и пока они не отвечают, узловой Pod CSI на этом узле вообще не запускается: его init-контейнер ждет /run/rpcbind.sock.

На каждом обслуживаемом узле — то есть на тех, где есть метка storage.deckhouse.io/csi-nfs-node, — NodeGroupConfiguration сначала просит пакетный менеджер узла установить rpcbind и nfs-common/nfs-utils. Этот путь остается предпочтительным: портмаппер — служба общесистемная, все остальное на узле, что говорит на RPC, рассчитывает на дистрибутивный, и пока он на месте, модуль не вмешивается.

Если установка не удалась — закрытая среда без доступа к репозиториям или дистрибутив, который этих пакетов не поставляет, — модуль разворачивает собственный образ-пакет nfs-tools. bashible скачивает его из реестра модуля, распаковывает на узле и запускает скрипт установки. Полезная нагрузка размещается в /var/lib/deckhouse/sds/csi-nfs, каждый бинарный файл запускается через собственный загрузчик со своим путем к библиотекам, и поднимаются два юнита:

systemctl is-active d8-csi-nfs-rpcbind.service d8-csi-nfs-rpc-statd.service

Скрипт установки проверяет собственный результат, а не сообщает об успехе на основании того, что файлы юнитов записаны. Весь контракт — это отвечающий сокет, поэтому скрипт дожидается сокета и, если тот так и не появился, печатает то, что сказали демоны, и завершает шаг bashible с ошибкой. Это разница между узлом, который сообщает об ошибке, и узлом, на котором любой том NFSv3 просто ждет вечно.

Три вещи, о которых стоит знать: ни одна из них не заметна до того момента, когда монтирование зависнет.

Путь к сокету не угадывается. То, где rpcbind открывает локальный сокет, зашито в бинарный файл; образ читает этот путь при сборке и сообщает скрипту установки, чего ожидать. Сборка, в которой использовался бы /var/run/rpcbind.sock, запустилась бы без ошибок и оставила узловой Pod CSI ждать по тому пути, за которым он следит.

rpcbind и rpc.statd — это целиком userspace SUN RPC, а libtirpc нужна таблица транспортов, чтобы сделать хотя бы один вызов. Пакет несет собственный netconfig, и обертки указывают демонам на него; без него любой вызов завершается ошибкой RPC_UNKNOWNPROTO.

А rpc.statd запускает sm-notify по абсолютному пути, зашитому в него, и это не копия под нашим префиксом. Скрипт установки связывает этот путь с копией из полезной нагрузки и записывает ссылку, чтобы удаление забрало ровно ее. Без этой ссылки только что перезагрузившийся узел не может объявить о перезагрузке узлам, удерживающим на нем блокировки.

Два пути никогда не смешиваются. Узел, у которого уже есть свой rpcbind, сохраняет все свое, и скрипт установки там ничего не делает.

Чтобы понять, какой путь выбран на узле, посмотрите, что на нем запущено:

# демоны дистрибутива
systemctl is-active rpcbind rpc-statd
# собственные демоны модуля
ls /var/lib/deckhouse/sds/csi-nfs/bin
rpcinfo -p localhost

Два ограничения стоит назвать прямо.

Откат поставляет два демона, нужных модулю, а не полноценный клиент NFS. Все остальное на узле, что монтирует NFS самостоятельно — встроенный в kubelet плагин томов nfs или mount -t nfs руками, — по-прежнему требует дистрибутивный mount.nfs и здесь его не получает. На тома самого модуля это не влияет: они монтируются изнутри контейнера.

И ничего из этого не касается NFSv4. Четвертая версия несет блокировки в самом протоколе и не нуждается в портмаппере, поэтому узлу, обслуживающему только шары NFSv4, не нужны ни пакеты дистрибутива, ни откат.

Удаление останавливает юниты и забирает файлы, размещенные установкой на хосте, и намеренно оставляет на месте /var/lib/nfs: списки sm/sm.bak — это запись о том, какие узлы удерживают блокировки на этом узле, и установленный позже пакет дистрибутива рассчитывает найти их там, где они есть.