Миграция Ceph CSI на shturval-ceph-csi

На странице описано, как перевести уже работающие в кластере сервисы shturval-ceph-cephfs и shturval-ceph-rbd на сервис shturval-ceph-csi без прерывания работы существующих томов. Данные в Ceph не будут утеряны, драйверы сохраняют прежние имена (cephfs.csi.ceph.com и rbd.csi.ceph.com).

Утилита миграции только читает данные кластера и записывает YAML на диск, объекты в кластере не изменяются.

До запуска скрипта миграции #

Сохраните вывод команд в текстовый файл в каталоге утилиты, например, pre-migration.txt. Сделайте это до выключения сервисов. После отключения сервисов Secret и StorageClass чарта удаляются, потом потребуется проверить, что Secret из backup вернулся в свой неймспейс, что старый StorageClass исчез, и какие поды нельзя перезапускать, пока CSI-поды оператора не станут Running.

• Имя Secret (spec.customvalues.secret.name) и неймспейс (spec.namespace) каждого SSC.

  kubectl get shturvalserviceconfig shturval-ceph-cephfs shturval-ceph-rbd -o custom-columns=NAME:.metadata.name,NAMESPACE:.spec.namespace,SECRET:.spec.customvalues.secret.name
  

• Имя StorageClass (spec.customvalues.storageClass.name), если оно задано.

  kubectl get shturvalserviceconfig shturval-ceph-cephfs shturval-ceph-rbd -o custom-columns=NAME:.metadata.name,STORAGECLASS:.spec.customvalues.storageClass.name
  

• Список PVC, которые уже смонтированы. Их поды нельзя перезапускать, пока новые CSI-поды оператора не станут Running.

  kubectl get pvc -A --field-selector=status.phase=Bound
  

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

Шаг 1. Собрать утилиту и запустить миграцию #

На этом шаге создаются YAML-манифесты и помещаются в каталог manifests/. В кластере ничего не применяется.

go build -o ceph-operator-migration .
./ceph-operator-migration --kubeconfig /path/to/kubeconfig.conf

Запуск без сборки: go run . --kubeconfig /path/to/kubeconfig.conf.

Сообщения saved ... пишутся в stderr. Код выхода 0 означает, что оба SSC прочитаны. Если в stderr есть error:, не переходите к следующему шагу - выключению сервисов: исправьте причину и запустите утилиту снова.

После успешного запуска в каталоге запуска должны быть созданы:

manifests/
├── step0/
│   └── namespace.yaml
├── backup/
│   ├── ceph-fs-csi-secret.yaml
│   └── ceph-rbd-csi-secret.yaml
├── step1/
│   ├── operator-images-configmap.yaml
│   ├── cephfs-driver.yaml
│   ├── rbd-driver.yaml
│   ├── ceph-fs-connection.yaml
│   ├── ceph-rbd-connection.yaml
│   ├── ceph-fs-client-profile.yaml
│   ├── ceph-rbd-client-profile.yaml
│   ├── ceph-fs-operator-secret.yaml
│   └── ceph-rbd-operator-secret.yaml
└── step2/
    ├── ceph-fs-storageclass.yaml
    └── ceph-rbd-storageclass.yaml

Образы CSI #

В файл с образами CSI manifests/step1/operator-images-configmap.yaml - записываются адреса по умолчанию. Если поды должны браться из вашего реестра, замените их в этом файле и примените его на шаге 7. Пересобирать утилиту не нужно.

Проверьте перед выключением SSC:

• В backup/ у Secret тот же metadata.name, что в SSC, и metadata.namespace равен исходному неймспейсу CSI (ceph-fs или ceph-rbd).
• В step1/ те же Secret лежат уже в неймспейсе оператора.
• В step1/*-connection.yaml список spec.monitors совпадает с мониторами соответствующего SSC.
• В step2/ классы называются shturval-cephfs и shturval-rbd. Эти имена утилита задаёт сама, даже если в customvalues чарта класс назывался иначе.
• parameters.clusterID, fsName (CephFS) и pool (RBD) совпадают с customvalues своего SSC.

Шаг 2. Выключить SSC #

Два драйвера с одним именем одновременно работать не могут. Сначала снимается чартовый CSI, затем поднимается оператор.

Для Модуль Ceph CSI - CephFS и Модуль Ceph CSI - CephRBD:

1. Сервисы и репозитории → Установленные сервисы.
2. Найдите Модуль Ceph CSI - CephFS и смените режим управления на Выкл.
3. Найдите Модуль Ceph CSI - CephRBD и смените режим управления на Выкл.

То же через kubectl. Сервисы не критические, снимать iscritical не нужно:

kubectl patch shturvalserviceconfig shturval-ceph-cephfs --type merge -p '{"spec":{"mode":"absent"}}'
kubectl patch shturvalserviceconfig shturval-ceph-rbd --type merge -p '{"spec":{"mode":"absent"}}'

Дождитесь, пока поды чартов удалятся:

kubectl get pods -n ceph-fs
kubectl get pods -n ceph-rbd

Выключение удаляет поды controller/node plugin и StorageClass, которые создал чарт. Объекты PersistentVolume и PersistentVolumeClaim не удаляются. Данные в Ceph остаются. Уже смонтированный том на узле продолжает работать: монтирование в ядре или через ceph-fuse уже выполнено.

Шаг 3. Убедиться, что старые StorageClass удалены #

kubectl get storageclass shturval-cephfs shturval-rbd

Если в customvalues было другое имя класса, проверьте и его. Пустой вывод — ожидаемый результат.

Если StorageClass остался, удалите его:

kubectl delete storageclass shturval-cephfs shturval-rbd

Secret, PersistentVolume и PersistentVolumeClaim в неймспейсах старых драйверов не удаляйте.

Шаг 4. Вернуть Secrets в исходные неймспейсы #

На шаге 1 были сохранены Secret в файлы manifests/backup/, который необходимо применить в кластере:

kubectl apply -f manifests/backup/

Secret возвращаются в неймспейсы, из которых утилита их прочитала (ceph-fs, ceph-rbd или фактический spec.namespace). Существующие PVC ссылаются на Secret именно там. Неймспейс Secret у уже созданного PVC сменить нельзя, поэтому этот шаг обязателен: без него том не смонтируется заново после рестарта пода.

Проверка:

kubectl get secret -n ceph-fs
kubectl get secret -n ceph-rbd

Имена должны совпасть с metadata.name в файлах backup/.

Шаг 5. Создать неймспейс оператора #

kubectl apply -f manifests/step0/

Появится неймспейс ceph-csi-operator (или значение установленное флагом --operator-namespace на шаге 1).

Шаг 6. Установить чарт оператора #

Чарт ceph-csi-operator/ceph-csi-operator из репозитория https://ceph.github.io/ceph-csi-operator/.

helm install ceph-csi-operator ceph-csi-operator/ceph-csi-operator \
  -n ceph-csi-operator --create-namespace=false \
  --values values.yaml

В неймспейсе оператора запускается один под: ceph-csi-operator-controller-manager. Поды CSI ещё не запущены. Они будут созданы после применения манифестов из step1.

Шаг 7. Применить манифесты и дождаться подов CSI #

kubectl apply -f manifests/step1/
kubectl get pods -n ceph-csi-operator -w

К шагу 8 переходите, когда все поды неймспейса в статусе Running, включая поды на каждом узле, где должны монтироваться тома. ContainerCreating и CrashLoopBackOff означают, что новый плагин ещё не готов принимать remount. Смотрите события пода: чаще всего это недоступный образ из ConfigMap operator-images или ошибка в ClientProfile (мониторы, clusterID).

На этом этапе уже можно перезапустить под с существующим PVC и убедиться, что том монтируется снова. Секрет для этого монтирования берётся из каталога backup.

Шаг 8. Применить StorageClass #

kubectl apply -f manifests/step2/
kubectl get storageclass shturval-cephfs shturval-rbd

Классы shturval-cephfs и shturval-rbd ссылаются на Secret в неймспейсе оператора. Они нужны новым PVC. Уже созданные PVC продолжают использовать Secret из шага 4 и прежнее имя драйвера в PV. Менять у них storageClassName не требуется.

Проверка нового тома: создайте PVC с storageClassName: shturval-cephfs или shturval-rbd, дождитесь Bound и запуска пода. Если PVC остаётся в Pending, смотрите kubectl describe pvc и логи provisioner в неймспейсе ceph-csi-operator.

Что попадает в манифесты #