Alauda Build of Nexus
  • Русский

    • Как выполнить резервное копирование и восстановление nexus с помощью Velero

    Содержание

    Область примененияТерминологияПредварительные требованияРезервное копированиеПодготовкаСоздание бакетаНастройка репозитория резервных копий VeleroВыполнение резервного копированияУдаление сервиса экземпляра nexus для предотвращения изменений данных во время резервного копированияСоздание политики резервного копирования томовВыполнение резервного копированияПосле успешного резервного копирования восстановите сервис экземпляра nexusВосстановлениеПодготовкаВыбор резервной копии для восстановленияОпределение целевого пространства имёнУдаление Nexus operator из кластера.Операции восстановленияСоздание файла конфигурации восстановленияСоздание задачи восстановленияОчистка ресурсовИзменение ресурса Nexus CRРазвертывание Nexus operator в кластере.Вопросы и ответыКак определить, поддерживает ли PVC snapshot?

    Область применения

    Это решение применимо к экземплярам Nexus версии 3.76 и выше.

    WARNING

    Это решение не поддерживает экземпляры Nexus, развернутые с использованием хранилища HostPath.

    Если необходимо выполнить резервное копирование экземпляров с использованием HostPath, обратитесь к разделу Как выполнить резервное копирование и восстановление nexus с помощью функций Nexus.

    Терминология

    ТерминЗначение
    Original InstanceЭкземпляр инструмента до резервного копирования
    New InstanceЭкземпляр инструмента после восстановления
    Original NamespaceПространство имён экземпляра инструмента до резервного копирования
    New NamespaceПространство имён экземпляра инструмента после восстановления
    Nexus CR ResourceЭтот ресурс используется для описания способа развертывания экземпляра Nexus. Nexus Operator развернет экземпляр Nexus на основе этого ресурса.

    Предварительные требования

    1. Развернуть MinIO Object Storage: Это решение резервного копирования и восстановления использует объектное хранилище для сохранения данных резервных копий, поэтому необходимо предварительно развернуть экземпляр MinIO. ACP предоставляет Быстрое создание экземпляра MinIO.

    2. Развернуть Velero: Velero — это инструмент для резервного копирования и восстановления. ACP предоставляет Alauda Container Platform Data Backup for Velero, который можно развернуть во вкладке Administrator в разделе Marketplace -> Cluster Plugins, выполнив поиск по слову Velero.

    3. Установить командную утилиту mc: mc — это командный инструмент управления MinIO. Инструкции по установке см. в официальной документации MinIO.

    4. Установить командную утилиту kubectl: kubectl — это командный инструмент управления Kubernetes. Инструкции по установке см. в официальной документации Kubernetes.

    5. Удалить nexus operator из кластера.

      kubectl get subscription --all-namespaces | grep nexus-ce-operator | awk '{print "kubectl delete subscription "$2" -n "$1}' | sh

# Вывод:
# subscription.operators.coreos.com "nexus-ce-operator" deleted
      Почему нужно удалить Nexus operator?

      Во время восстановления Velero необходимо запускать backup pods для восстановления данных PVC, что занимает много времени. Если Operator не удалить, могут возникнуть следующие проблемы:

      1. Operator может пересоздавать workloads на основе Nexus CR, из-за чего восстановленные pods будут перезапущены или пересозданы, что приведет к прерыванию или неудаче восстановления.
      2. Некоторые восстановленные ресурсы могут конфликтовать с существующими ресурсами, например, Ingress.
      Влияние удаления Nexus operator

      После удаления Operator изменения в Nexus CR не будут применяться, например, изменение ресурсов или размера хранилища.

      Удаление Operator не вызовет сбоев в работе существующих экземпляров.

    Для удобства последующих операций сначала задайте следующие переменные окружения:

    export MINIO_HOST=<адрес доступа к экземпляру MinIO> # Пример: http://192.168.1.100:32008
export MINIO_ACCESS_KEY=<ключ доступа к экземпляру MinIO> # Пример: minioadmin
export MINIO_SECRET_KEY=<секретный ключ экземпляра MinIO> # Пример: minioadminpassword
export MINIO_ALIAS_NAME=<псевдоним экземпляра MinIO> # Пример: myminio

export VELERO_BACKUP_BUCKET=<имя бакета для резервных копий Velero> # Пример: backup
export VELERO_BACKUP_REPO_NAME=<имя репозитория резервных копий Velero> # Пример: nexus-backup-repo

export NEXUS_NAMESPACE=<пространство имён экземпляра NEXUS для резервного копирования>
export NEXUS_NAME=<имя экземпляра NEXUS для резервного копирования>

    Выполните следующие команды для настройки инструмента mc и проверки подключения:

    mc alias set ${MINIO_ALIAS_NAME} ${MINIO_HOST} ${MINIO_ACCESS_KEY} ${MINIO_SECRET_KEY}
mc ping ${MINIO_ALIAS_NAME}

# Пример вывода:
#   1: http://192.168.131.56:32571:32571   min=98.86ms    max=98.86ms    average=98.86ms    errors=0   roundtrip=98.86ms
#   2: http://192.168.131.56:32571:32571   min=29.57ms    max=98.86ms    average=64.21ms    errors=0   roundtrip=29.57ms
#   3: http://192.168.131.56:32571:32571   min=29.57ms    max=98.86ms    average=52.77ms    errors=0   roundtrip=29.88ms

    Если ping до экземпляра MinIO успешен, значит mc настроен корректно.

    Резервное копирование

    Подготовка

    Подготовка к резервному копированию состоит из двух шагов:

    1. Создание бакета
    2. Настройка репозитория резервных копий Velero

    Создание бакета

    Выполните следующую команду для создания бакета для хранения данных резервных копий:

    mc mb ${MINIO_ALIAS_NAME}/${VELERO_BACKUP_BUCKET}

# Вывод:
# Bucket created successfully `myminio/backup`.

    Настройка репозитория резервных копий Velero

    Выполните следующую команду для создания репозитория резервных копий Velero:

    nexus_backup_repo_credentials_secret_name="nexus-backup-repo-credentials"
minio_nexus_backup_bucket="${VELERO_BACKUP_BUCKET:-backup}"
minio_nexus_backup_bucket_directory="nexus"

kubectl apply -f - <<EOF
apiVersion: v1
stringData:
  cloud: |
    [default]
    aws_access_key_id = ${MINIO_ACCESS_KEY}
    aws_secret_access_key = ${MINIO_SECRET_KEY}
kind: Secret
metadata:
  labels:
    component: velero
    cpaas.io/backup-storage-location-repo: ${VELERO_BACKUP_REPO_NAME}
  name: ${nexus_backup_repo_credentials_secret_name}
  namespace: cpaas-system
type: Opaque
---
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: ${VELERO_BACKUP_REPO_NAME}
  namespace: cpaas-system
spec:
  config:
    checksumAlgorithm: ""
    insecureSkipTLSVerify: "true"
    region: minio
    s3ForcePathStyle: "true"
    s3Url: ${MINIO_HOST}
  credential:
    key: cloud
    name: ${nexus_backup_repo_credentials_secret_name}
  objectStorage:
    bucket: ${minio_nexus_backup_bucket}
    prefix: ${minio_nexus_backup_bucket_directory}
  provider: aws
EOF

# Вывод
# secret/nexus-backup-repo-credentials created
# backupstoragelocationrepo.ait.velero.io/nexus-backup-repo created

    Выполнение резервного копирования

    Ручное резервное копирование состоит из четырёх шагов:

    1. Удалить сервис экземпляра nexus, чтобы предотвратить изменения данных
    2. Создать политику резервного копирования томов
    3. Выполнить резервное копирование
    4. После успешного резервного копирования восстановить сервис экземпляра nexus

    Удаление сервиса экземпляра nexus для предотвращения изменений данных во время резервного копирования

    Выполните следующую команду для удаления сервиса экземпляра nexus:

    kubectl delete service -l release=${NEXUS_NAME} -n ${NEXUS_NAMESPACE}

# Вывод:
# service "nexus-nxrm-ha" deleted
# service "nexus-nxrm-ha-hl" deleted

    Создание политики резервного копирования томов

    Политика томов используется для указания метода резервного копирования PVC. По умолчанию PVC резервируются с помощью метода fs-backup.

    export BACKUP_POLICY_NAME=${BACKUP_POLICY_NAME:-nexus-backup}
export VELERO_BACKUP_REPO_NAME=${VELERO_BACKUP_REPO_NAME:-nexus-backup-repo}

kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: ${BACKUP_POLICY_NAME}-volume-policy
  namespace: cpaas-system
data:
  resourcepolicies: |
    version: v1
    volumePolicies:
      - conditions:
          csi: {}
        action:
          type: fs-backup
      - conditions:
          csi: {}
        action:
          type: fs-backup
EOF

# Вывод
# configmap/nexus-backup-volume-policy created

    Если PVC поддерживает snapshot, можно использовать snapshot для резервного копирования pvc, чтобы ускорить процесс. Для этого необходимо изменить configmap политики томов, указав, что класс хранилища использует snapshot для резервного копирования. Например, если класс хранилища ceph поддерживает snapshot, добавьте следующую конфигурацию (условие, добавленное в начало, имеет более высокий приоритет):

    Как определить, поддерживает ли PVC snapshot?

    WARNING

    Если вы используете резервное копирование pvc через snapshot, при восстановлении нельзя менять класс хранилища. Пожалуйста, корректируйте класс хранилища в соответствии с реальной ситуацией.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ${BACKUP_POLICY_NAME}-volume-policy
  namespace: cpaas-system
data:
  resourcepolicies: |
    version: v1
    volumePolicies:
# Если класс хранилища поддерживает snapshot, можно использовать snapshot для резервного копирования pvc, чтобы ускорить процесс.
# Добавьте следующую конфигурацию в configmap политики томов.
      - conditions:
          storageClass:
            - ceph
        action:
          type: snapshot
# конец конфигурации snapshot
      - conditions:
          csi: {}
        action:
          type: fs-backup
      - conditions:
          csi: {}
        action:
          type: fs-backup
    WARNING

    Если Velero не включен с поддержкой CSI snapshot, при резервном копировании вы получите следующую ошибку:

    Skip action velero.io/csi-pvc-backupper for resource persistentvolumeclaims:xxx, because the CSI feature is not enabled.

    Для исправления необходимо добавить параметр --features=EnableCSI в развертывание velero.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: velero
spec:
  template:
    spec:
      containers:
      - args:
        - server
        - --uploader-type=restic
+        - --features=EnableCSI
        - --namespace=cpaas-system
        command:
        - /velero
        name: velero

    Выполнение резервного копирования

    Выполните следующие команды для создания расписания резервного копирования и запуска задания резервного копирования:

    export BACKUP_POLICY_NAME=${BACKUP_POLICY_NAME:-nexus-backup}
export VELERO_BACKUP_REPO_NAME=${VELERO_BACKUP_REPO_NAME:-nexus-backup-repo}

kubectl apply -f - <<EOF
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: ${BACKUP_POLICY_NAME}
  namespace: cpaas-system
spec:
  schedule: '@every 876000h'
  template:
    defaultVolumesToFsBackup: true
    hooks: {}
    includedNamespaces:
    - ${NEXUS_NAMESPACE}
    includedResources:
    - '*'
    resourcePolicy:
      kind: configmap
      name: ${BACKUP_POLICY_NAME}-volume-policy
    storageLocation: ${VELERO_BACKUP_REPO_NAME}
    ttl: 720h0m0s
EOF

kubectl create -f - <<EOF
apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/schedule-name: ${BACKUP_POLICY_NAME}
    velero.io/storage-location: ${VELERO_BACKUP_REPO_NAME}
  generateName: ${BACKUP_POLICY_NAME}-
  namespace: cpaas-system
spec:
  csiSnapshotTimeout: 10m0s
  defaultVolumesToFsBackup: true
  includedNamespaces:
    - ${NEXUS_NAMESPACE}
  includedResources:
    - "*"
  itemOperationTimeout: 4h0m0s
  resourcePolicy:
    kind: configmap
    name: ${BACKUP_POLICY_NAME}-volume-policy
  snapshotMoveData: false
  storageLocation: ${VELERO_BACKUP_REPO_NAME}
  ttl: 720h0m0s
EOF

# Вывод
# schedule.velero.io/nexus-backup created
# backup.velero.io/nexus-backup-r6hht created

    Просмотр логов резервного копирования:

    kubectl logs -f -n cpaas-system -l app.kubernetes.io/instance=velero --max-log-requests 100 | grep nexus-backup

# Вывод
# time="2025-11-03T12:08:00Z" level=info msg="PodVolumeBackup completed" backup=cpaas-system/nexus-backup-n4lxm controller=podvolumebackup logSource="pkg/controller/pod_volume_backup_controller.go:244" pvb=cpaas-system/nexus-backup-n4lxm-5hs4m

    Проверьте прогресс задачи. Если статус Completed, резервное копирование прошло успешно.

    kubectl get backup -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep ${BACKUP_POLICY_NAME}

# Вывод
# nexus-backup-n4lxm	Completed	2025-11-03T12:07:53Z

    После успешного резервного копирования восстановите сервис экземпляра nexus

    Перейдите на страницу Administrator -> Marketplace -> Operator Hub, переключитесь на целевой кластер и повторно разверните Operator Alauda Build of Nexus.

    Восстановление

    Подготовка

    Подготовка к восстановлению состоит из четырёх шагов:

    1. Выбрать резервную копию для восстановления
    2. Определить целевое пространство имён для восстановления
    3. Удалить Nexus operator из кластера.

    Выбор резервной копии для восстановления

    Выполните следующую команду для просмотра всех успешных записей резервного копирования и выберите нужную по времени начала.

    kubectl get backup -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep ${BACKUP_POLICY_NAME} | grep Completed

# Вывод:
# nexus-backup-n4lxm	Completed	2025-11-03T12:07:53Z

    Задайте переменную окружения BACKUP_NAME:

    export BACKUP_NAME=<имя выбранной записи резервного копирования>

    Определение целевого пространства имён

    Рекомендуется восстанавливать в новое пространство имён. Задайте следующие переменные окружения:

    export NEW_NEXUS_NAMESPACE=<имя нового пространства имён>
kubectl create namespace ${NEW_NEXUS_NAMESPACE}

    Удаление Nexus operator из кластера.

    Выполните следующую команду для удаления Nexus operator:

    kubectl get subscription --all-namespaces | grep nexus-ce-operator | awk '{print "kubectl delete subscription "$2" -n "$1}' | sh

# Вывод:
# subscription.operators.coreos.com "nexus-ce-operator" deleted
    Почему нужно удалить Nexus operator?

    Во время восстановления Velero необходимо запускать backup pods для восстановления данных PVC, что занимает много времени. Если Operator не удалить, могут возникнуть следующие проблемы:

    1. Operator может пересоздавать workloads на основе Nexus CR, из-за чего восстановленные pods будут перезапущены или пересозданы, что приведет к прерыванию или неудаче восстановления.
    2. Некоторые восстановленные ресурсы могут конфликтовать с существующими ресурсами, например, Ingress.
    Влияние удаления Nexus operator

    После удаления Operator изменения в Nexus CR не будут применяться, например, изменение ресурсов или размера хранилища.

    Удаление Operator не вызовет сбоев в работе существующих экземпляров.

    Операции восстановления

    Операции восстановления состоят из пяти шагов:

    1. Создать файл конфигурации восстановления
    2. Создать задачу восстановления
    3. Очистить ресурсы
    4. Изменить ресурс Nexus CR
    5. Развернуть Nexus operator в кластере.

    Создание файла конфигурации восстановления

    Внимательно прочитайте комментарии в YAML и при необходимости внесите изменения (например, измените класс хранилища) перед созданием.

    # Если необходимо изменить класс хранилища, задайте следующие переменные окружения
OLD_STORAGE_CLASS_NAME='' # Исходное имя класса хранилища
NEW_STORAGE_CLASS_NAME='' # Новое имя класса хранилища

if [ -n "${OLD_STORAGE_CLASS_NAME}" ] && [ -n "${NEW_STORAGE_CLASS_NAME}" ] && [ ${NEW_STORAGE_CLASS_NAME} != ${OLD_STORAGE_CLASS_NAME} ]; then
kubectl apply -f - <<EOF
apiVersion: v1
data:
  resourcemodifier: |
    version: v1
    resourceModifierRules:
      - conditions:
          groupResource: persistentvolumeclaims
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches: &a1
          - operation: test
            path: /spec/storageClassName
            value: ${OLD_STORAGE_CLASS_NAME}
          - operation: replace
            path: /spec/storageClassName
            value: ${NEW_STORAGE_CLASS_NAME}
      - conditions:
          groupResource: persistentvolume
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches: *a1
kind: ConfigMap
metadata:
  labels:
    component: velero
  name: nexus-restore-modifier
  namespace: cpaas-system
EOF

else

kubectl apply -f - <<EOF
apiVersion: v1
data:
  resourcemodifier: |
    version: v1
    resourceModifierRules:
      - conditions:
          groupResource: persistentvolumeclaims
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches:
          - operation: add
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${NEW_NEXUS_NAMESPACE}
kind: ConfigMap
metadata:
  labels:
    component: velero
  name: nexus-restore-modifier
  namespace: cpaas-system
EOF
fi

# Вывод:
# configmap/nexus-restore-modifier created

    Создание задачи восстановления

    Выполните следующую команду для создания задачи восстановления:

    kubectl create -f - <<EOF
apiVersion: velero.io/v1
kind: Restore
metadata:
  generateName: ${NEXUS_NAME}-restore-
  namespace: cpaas-system
spec:
  backupName: ${BACKUP_NAME}
  hooks: {}
  includedNamespaces:
    - ${NEXUS_NAMESPACE}
  includedResources:
    - persistentvolumeclaims
    - persistentvolumes
    - configmaps
    - secrets
    - pods
    - nexuses.operator.alaudadevops.io
    - volumesnapshots
    - volumesnapshotcontents
  itemOperationTimeout: 10h0m0s
  namespaceMapping:
    ${NEXUS_NAMESPACE}: ${NEW_NEXUS_NAMESPACE}
  resourceModifier:
    kind: ConfigMap
    name: nexus-restore-modifier
EOF

# Вывод:
# restore.velero.io/<nexus-name>-restore-m2n8f created

    Просмотр логов восстановления:

    kubectl logs -f -n cpaas-system -l app.kubernetes.io/instance=velero --max-log-requests 100 | grep ${NEXUS_NAME}-restore

# Вывод
# time="2025-11-03T12:27:38Z" level=info msg="Async fs restore data path completed" PVR=<nexus-name>-restore-m2n8f-n2tx2 controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:275" pvr=<nexus-name>-restore-m2n8f-n2tx2
# time="2025-11-03T12:27:38Z" level=info msg="Restore completed" controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:327" pvr=<nexus-name>-restore-m2n8f-n2tx2

    Проверьте прогресс задачи. Если статус Completed, восстановление прошло успешно.

    kubectl get restore -n cpaas-system -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.phase}{'\t'}{.status.startTimestamp}{'\n'}{end}" | grep ${NEXUS_NAME}-restore

# Вывод
# <nexus-name>-restore-m2n8f    InProgress      2025-11-03T12:27:38Z

    Очистка ресурсов

    Убедитесь, что операция восстановления завершена, прежде чем продолжить!

    Выполните следующие команды для очистки ресурсов:

    kubectl delete configmap,secrets,sa -n ${NEW_NEXUS_NAMESPACE} -l release=${NEXUS_NAME}

kubectl get pod -n ${NEW_NEXUS_NAMESPACE} | grep ${NEXUS_NAME} | awk '{print $1}' | xargs kubectl delete pod -n ${NEW_NEXUS_NAMESPACE}

kubectl get secret -n ${NEW_NEXUS_NAMESPACE} | grep sh.helm.release.v1.${NEXUS_NAME} | awk '{print $1}' | xargs kubectl delete secret,configmap -n ${NEW_NEXUS_NAMESPACE}
kubectl delete configmap ${NEXUS_NAME}-nxrm-ha-logback-tasklogfile-override -n ${NEW_NEXUS_NAMESPACE}

    Изменение ресурса Nexus CR

    kubectl edit nexus ${NEXUS_NAME} -n ${NEW_NEXUS_NAMESPACE}

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

    1. Доменное имя:
      • Применимый сценарий: исходный экземпляр был развернут с использованием доменного имени
      • Причина: одинаковое доменное имя в ресурсах Ingress старого и нового экземпляров вызовет конфликт, из-за чего не удастся создать Ingress для нового экземпляра
      • Рекомендация:
        • (Рекомендуется) Изменить домен исходного экземпляра на временный, оставить новый экземпляр без изменений
        • Или оставить исходный экземпляр без изменений, а новый экземпляр изменить на новый домен
      • Как изменить: см. Настройка сетевого доступа экземпляра
    2. NodePort:
      • Применимый сценарий: исходный экземпляр был развернут с использованием NodePort
      • Причина: одинаковый NodePort в ресурсах Service старого и нового экземпляров вызовет конфликт, из-за чего не удастся создать Service для нового экземпляра
      • Рекомендация:
        • (Рекомендуется) Изменить NodePort исходного экземпляра на временный порт, оставить новый экземпляр без изменений
        • Или оставить исходный экземпляр без изменений, а новый экземпляр изменить на новый порт
      • Как изменить: см. Настройка сетевого доступа экземпляра
    3. Класс хранилища:
      • Применимый сценарий: класс хранилища старого и нового экземпляров отличается (например, исходный использовал NFS, новый — Ceph)
      • Причина: если не изменить, Operator продолжит использовать старый класс хранилища для создания PVC, что вызовет конфликт с восстановленными PVC
      • Рекомендация: изменить на корректный класс хранилища
      • Как изменить: см. Настройка хранилища экземпляра

    Развертывание Nexus operator в кластере.

    Перейдите во вкладку Administrator, на страницу Marketplace -> OperatorHub и повторно разверните Operator Alauda Build of Nexus.

    После развертывания Operator он развернет новый экземпляр согласно Nexus CR. Вы можете отслеживать прогресс на странице деталей экземпляра.

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

    • Пользователи
    • Репозитории
    • Задачи

    Вопросы и ответы

    Как определить, поддерживает ли PVC snapshot?

    Чтобы определить, поддерживает ли PVC snapshot, необходимо проверить, поддерживает ли его базовый StorageClass функцию snapshot. PVC поддерживает snapshot, если в кластере существует VolumeSnapshotClass, у которого поле driver совпадает со значением provisioner StorageClass. Если такой VolumeSnapshotClass есть, значит StorageClass (а значит и PVC) поддерживает функцию snapshot.

    Пример конфигурации:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph
provisioner: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
  csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
  fsName: cephfs
  pool: cephfs-data0
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-cephfs-snapshotclass
deletionPolicy: Delete
driver: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: rook-ceph

    Ключевые моменты:

    • Значение provisioner в StorageClass должно точно совпадать со значением driver в VolumeSnapshotClass
    • Оба ресурса должны существовать в кластере
    • CSI драйвер должен поддерживать операции snapshot