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

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

Выполняйте команды на машине с правами администратора API Kubernetes.

Быстрый старт

Следующие шаги включают модуль, подключают кластер к uStor и создают первый том.

Включение модуля

Модуль находится на стадии Experimental. Перед включением разрешите экспериментальные модули в ModuleConfig deckhouse:

d8 k patch moduleconfig deckhouse --type=merge --patch '{"spec":{"settings":{"allowExperimentalModules":true}}}'

Затем включите модуль.

После включения модуль устанавливает клиент uStor на узлы и запускает CSI node plugin. CSI-контроллер запускается, когда создан MindUstorStorageConnection.

Подготовка пользователя uStor

CSI-контроллер управляет образами от имени пользователя uStor. Создайте для него отдельного пользователя с ролью user вместо пользователя с ролью admin.

На этого пользователя, как и на любого другого, распространяется политика паролей uStor:

  • Имя пользователя не должно содержать дефис. В пароле допустимы только специальные символы @$!%*?&.
  • Пароль, заданный администратором при создании пользователя или при сбросе, временный: uStor отклоняет вход, пока пользователь его не сменит. Войдите от имени пользователя и смените пароль командой ucli user-passwd, прежде чем помещать его в секрет.
  • По умолчанию срок действия пароля — 60 дней. После этого uStor отклоняет вход, пока пароль не сменят.
  • Пользователь, который не входил в систему 45 дней, блокируется до разблокировки администратором. Модуль выполняет вход с учётными данными раз в час, поэтому пользователь остаётся активным, даже если тома не создаются.
  • После трёх неудачных попыток входа подряд пользователь блокируется на 15 минут.

Срок действия пароля и период неактивности задаются в /etc/ustor/ustor-middleware.conf на узлах управления uStor (раздел «Политика паролей» руководства администратора uStor). Они применяются ко всем пользователям uStor, включая людей.

Создание секретов

Подключение ссылается на два секрета в неймспейсе d8-csi-mind-ustor: в одном учётные данные пользователя uStor, в другом клиентские сертификаты uStor.

Скопируйте ustor_ca.crt, ustor_client.crt, ustor_client.key, ustor_etcd-client.crt и ustor_etcd-client.key из /etc/ustor/certs узла uStor в текущую директорию, затем создайте секреты:

d8 k -n d8-csi-mind-ustor create secret generic ustor-credentials \
  --from-literal=username='<USERNAME>' \
  --from-literal=password='<PASSWORD>'

d8 k -n d8-csi-mind-ustor create secret generic ustor-client-tls \
  --from-file=ca.crt=ustor_ca.crt \
  --from-file=client.crt=ustor_client.crt \
  --from-file=client.key=ustor_client.key \
  --from-file=etcd-client.crt=ustor_etcd-client.crt \
  --from-file=etcd-client.key=ustor_etcd-client.key

В команде:

  • <USERNAME> — имя пользователя uStor, подготовленного для CSI-контроллера;
  • <PASSWORD> — пароль этого пользователя.

Описание подключения

Опишите подключение к кластеру uStor ресурсом MindUstorStorageConnection. Укажите адрес API управления uStor, клиентские адреса etcd uStor и сеть OSD uStor:

d8 k apply -f - <<EOF
apiVersion: storage.deckhouse.io/v1alpha1
kind: MindUstorStorageConnection
metadata:
  name: main
spec:
  controlPlane:
    address: "https://ustor-api.example.lab:23004"
    credentialsSecretName: ustor-credentials
  dataPlane:
    etcdAddresses:
      - "https://10.101.0.1:23000"
      - "https://10.101.0.2:23000"
      - "https://10.101.0.3:23000"
    osdNetwork: "10.101.0.0/24"
    tlsSecretName: ustor-client-tls
EOF

Параметр controlPlane.address нельзя изменить после создания подключения: тома остаются в том кластере uStor, где были созданы.

Проверьте состояние подключения:

d8 k get mindustorstorageconnections.storage.deckhouse.io -o wide

Фаза Created означает, что подключение используется, в обоих секретах есть все нужные ключи и API управления uStor принимает вход пользователя. Если фаза Failed, в столбце REASON указано, что не так.

Создание StorageClass

Опишите StorageClass ресурсом MindUstorStorageClass, который ссылается на подключение и пул uStor:

d8 k apply -f - <<EOF
apiVersion: storage.deckhouse.io/v1alpha1
kind: MindUstorStorageClass
metadata:
  name: ustor-nbd
spec:
  connectionName: main
  pool: data
  fsType: ext4
  reclaimPolicy: Delete
  volumeBindingMode: Immediate
EOF

Проверьте, что ресурс находится в фазе Created и StorageClass создан:

d8 k get mindustorstorageclasses.storage.deckhouse.io -o wide
d8 k get storageclass ustor-nbd

Модуль создаёт StorageClass с тем же именем для драйвера ustor-nbd.csi.mindsw.io.

Создание тома

Создайте PersistentVolumeClaim с новым StorageClass:

d8 k apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ustor-test
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ustor-nbd
  resources:
    requests:
      storage: 1Gi
EOF

Проверьте, что PersistentVolumeClaim находится в состоянии Bound:

d8 k get pvc ustor-test

Ограничение узлов, использующих uStor

По умолчанию конфигурация клиента uStor размещается на всех узлах типов CloudEphemeral, CloudPermanent, CloudStatic и Static, а CSI node plugin работает на тех из них, где установлен клиент uStor. Если доступ к сети данных uStor есть только у части узлов, выберите их параметром dataPlane.nodeSelector подключения:

apiVersion: storage.deckhouse.io/v1alpha1
kind: MindUstorStorageConnection
metadata:
  name: main
spec:
  # ...
  dataPlane:
    # ...
    nodeSelector:
      matchLabels:
        node.deckhouse.io/group: storage-clients

StorageClass и PersistentVolume модуля ограничены узлами, на которых работает CSI node plugin, поэтому поды, использующие тома uStor, планируются только на эти узлы как в режиме привязки томов Immediate, так и в режиме WaitForFirstConsumer.

Не исключайте узлы, на которых смонтированы тома uStor: с них удаляется CSI node plugin, и тома нельзя отмонтировать.

Смена пароля пользователя uStor

Смените пароль до истечения срока его действия или после сброса администратором.

Пока uStor отклоняет вход, подключение находится в фазе Failed, условие Authenticated подключения указывает причину (например, PasswordExpired или UserLocked) и срабатывает алерт D8CsiMindUstorStorageConnectionNotInUse. Смонтированные тома продолжают работать, так как путь данных не проходит через API управления. Создание, удаление и расширение томов останавливается, пока вход не выполнится успешно.

Чтобы сменить пароль:

  1. Смените пароль в uStor от имени самого пользователя командой ucli user-passwd.

  2. Поместите новый пароль в секрет:

    d8 k -n d8-csi-mind-ustor create secret generic ustor-credentials \
  --from-literal=username='<USERNAME>' \
  --from-literal=password='<NEW_PASSWORD>' \
  --dry-run=client -o yaml | d8 k apply -f -

    В команде:

    • <USERNAME> — имя пользователя uStor подключения;
    • <NEW_PASSWORD> — новый пароль этого пользователя.

Модуль и CSI-контроллер используют новый пароль без перезапуска: модуль выполняет вход повторно сразу после изменения секрета.

uStor позволяет пользователю менять пароль не чаще одного раза в 7 дней. Чтобы сменить его раньше, администратор сбрасывает пароль командой ucli user-modify <USERNAME> --reset-password, после чего пользователь меняет временный пароль, как описано выше.

Обновление клиентских сертификатов

Чтобы заменить клиентские сертификаты uStor, обновите ключи TLS-секрета подключения. Модуль записывает новые сертификаты на узлы без перезапуска CSI node plugin.

Создание снимков и восстановление томов

Для снимков томов требуется модуль, предоставляющий API snapshot.storage.k8s.io, например snapshot-controller. Если такой модуль включён, csi-mind-ustor создаёт VolumeSnapshotClass csi-mind-ustor и указывает его в аннотации storage.deckhouse.io/volumesnapshotclass каждого создаваемого StorageClass, поэтому класс в VolumeSnapshot указывать не обязательно.

Снимок хранится в пуле своего тома. Том, восстановленный из снимка, — полная независимая копия: удаление снимка или исходного тома на него не влияет.

Чтобы создать снимок PersistentVolumeClaim data и восстановить его в новый PersistentVolumeClaim, примените манифесты:

d8 k apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: data-snapshot
spec:
  volumeSnapshotClassName: csi-mind-ustor
  source:
    persistentVolumeClaimName: data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-restored
spec:
  storageClassName: ustor-nbd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  dataSource:
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: data-snapshot
EOF

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

Использование блочных томов

PersistentVolumeClaim с volumeMode: Block предоставляет поду том uStor как блочное устройство без файловой системы. Такой том может использовать только один под одновременно, поэтому PersistentVolumeClaim должен запрашивать режим доступа ReadWriteOncePod. Режим ReadWriteOnce для блочного тома отклоняется.

Пример PersistentVolumeClaim для блочного тома:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: raw
spec:
  storageClassName: ustor-nbd
  volumeMode: Block
  accessModes:
    - ReadWriteOncePod
  resources:
    requests:
      storage: 10Gi

В поде указывайте том в volumeDevices вместо volumeMounts. Блочные тома можно расширять без остановки, для них поддерживаются снимки и восстановление, как для томов с файловой системой.

Блочные тома для виртуальных машин

Для живой миграции виртуальной машины её диск должен быть подключён одновременно к исходному и целевому узлу. Для этого драйвер принимает режим доступа ReadWriteMany для блочных томов.

Модуль принимает PersistentVolumeClaim драйвера с режимом ReadWriteMany только от сервисных аккаунтов модуля virtualization и отклоняет его для других пользователей. Режим ReadWriteMany с volumeMode: Filesystem отклоняется для всех: ext4 и xfs нельзя смонтировать на нескольких узлах одновременно.

Модуль добавляет каждому создаваемому StorageClass следующие аннотации:

  • virtualdisk.virtualization.deckhouse.io/volume-mode: Block;
  • virtualdisk.virtualization.deckhouse.io/access-mode: ReadWriteMany.

С этими аннотациями VirtualDisk модуля virtualization на этом StorageClass создаются как блочные тома ReadWriteMany, и использующие их виртуальные машины можно мигрировать без остановки. Если аннотация уже задана в StorageClass, модуль сохраняет её значение.

Изменение и удаление StorageClass

Параметры MindUstorStorageClass нельзя изменить. Чтобы создавать тома с другими параметрами, например в другом пуле, создайте ещё один MindUstorStorageClass.

Удаление MindUstorStorageClass удаляет его StorageClass. Уже созданные тома остаются на месте.