Alauda Build of Harbor Docs
  • Русский

    • Резервное копирование и восстановление HARBOR с использованием Velero

    В этом руководстве показано, как использовать Velero — инструмент с открытым исходным кодом для аварийного восстановления в облачных нативных средах, для выполнения операций резервного копирования и восстановления HARBOR.

    Содержание

    Область примененияТерминологияПредварительные требованияРезервное копированиеПодготовкаСоздание бакетаНастройка репозитория резервных копий VeleroВыполнение резервного копированияПеревод экземпляра harbor в режим только для чтенияСоздание Pod для резервного копированияСоздание политики резервного копирования томовВыполнение резервного копированияПосле успешного резервного копирования отключите режим только для чтения в HarborВосстановлениеПодготовкаВыбор резервной копии для восстановленияОпределение целевого пространства имёнУдаление оператора HARBOR CEОперации восстановленияСоздание конфигурационного файла восстановленияСоздание задачи восстановленияОчистка ресурсовИзменение ресурса HARBOR CRРазвёртывание оператора HARBOR CEВопросы и ответыКак определить, поддерживает ли PVC снапшоты?

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

    Данное решение применимо к экземплярам HARBOR версии 2.12 и выше.

    Данные Harbor состоят из трёх основных компонентов: хранилище, база данных PostgreSQL.
    Это решение поддерживает резервное копирование только хранилища.
    Резервное копирование базы данных PostgreSQL необходимо выполнять отдельно в соответствии со стратегией резервного копирования вашего поставщика базы данных.

    DANGER

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

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

    ТерминОписание
    Исходный экземплярЭкземпляр HARBOR до резервного копирования
    Целевой экземплярЭкземпляр HARBOR после восстановления
    Исходное пространство имёнПространство имён, в котором расположен исходный экземпляр
    Целевое пространство имёнПространство имён, в котором расположен целевой экземпляр
    Ресурс HARBOR CRПользовательский ресурс, описывающий конфигурацию развертывания HARBOR, используемый Operator для развертывания экземпляров HARBOR

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

    1. Развернуть объектное хранилище MinIO: данное решение для резервного копирования и восстановления опирается на объектное хранилище для сохранения данных резервных копий, поэтому необходимо заранее развернуть экземпляр 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.

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

    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> # Пример: harbor-backup-repo

export HARBOR_NAMESPACE=<пространство имён экземпляра HARBOR для резервного копирования>
export HARBOR_NAME=<имя экземпляра HARBOR для резервного копирования>

    Выполните следующие команды для настройки инструмента 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:

    harbor_backup_repo_credentials_secret_name="harbor-backup-repo-credentials"
minio_harbor_backup_bucket="${VELERO_BACKUP_BUCKET:-backup}"
minio_harbor_backup_bucket_directory="harbor"

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: ${harbor_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: ${harbor_backup_repo_credentials_secret_name}
  objectStorage:
    bucket: ${minio_harbor_backup_bucket}
    prefix: ${minio_harbor_backup_bucket_directory}
  provider: aws
EOF

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

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

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

    1. Перевести экземпляр harbor в режим только для чтения
    2. Создать Pod для резервного копирования
    3. Выполнить резервное копирование
    4. После успешного резервного копирования отключить режим только для чтения в harbor

    Перевод экземпляра harbor в режим только для чтения

    Войдите в Harbor, перейдите в Administration -> Configuration -> System Settings -> Repository Read Only и установите режим только для чтения.

    После изменения в верхней части интерфейса Harbor появится сообщение:
    "Harbor is set to read-only mode, Deleting repository, artifact, tag and pushing image will be deactivated under read-only mode."

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

    На этом шаге создаётся Pod, который монтирует PVC HARBOR, что позволяет Velero выполнить резервное копирование данных PVC.

    image=''

if [ -z "${IMAGE}" ]; then
  image=$(kubectl get deployment -n ${HARBOR_NAMESPACE} -l release=${HARBOR_NAME} -o jsonpath='{range .items[0].spec.template.spec.containers[]}{.image}{"\n"}{end}' | head -n1)
fi

PVC_NAMES=($(kubectl get pvc -n ${HARBOR_NAMESPACE} -l release=${HARBOR_NAME} -o jsonpath='{range .items[*]}{.metadata.name}{" "}{end}'))

VOLUME_MOUNTS=""
VOLUMES=""
INDEX=0
for pvc in ${PVC_NAMES[@]}; do
  VOLUME_MOUNTS="${VOLUME_MOUNTS}
        - name: data-${INDEX}
          mountPath: /mnt/data-${INDEX}"
  VOLUMES="${VOLUMES}
    - name: data-${INDEX}
      persistentVolumeClaim:
        claimName: ${pvc}"
  INDEX=$((INDEX+1))
done

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${HARBOR_NAME}-backup-pod
  namespace: ${HARBOR_NAMESPACE}
  labels:
    release: ${HARBOR_NAME}
spec:
  containers:
    - name: backup
      image: ${image}
      command: ["/bin/sh", "-c", "sleep 86400"]
      resources:
        limits:
          cpu: 1
          memory: 1Gi
      volumeMounts:${VOLUME_MOUNTS}
  volumes:${VOLUMES}
  restartPolicy: Never
EOF

kubectl wait --for=condition=ready pod -n ${HARBOR_NAMESPACE} ${HARBOR_NAME}-backup-pod

# Вывод
# pod/xxxx-harbor-backup-pod created
# pod/xxxx-harbor-backup-pod condition met

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

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

    export BACKUP_POLICY_NAME=${BACKUP_POLICY_NAME:-harbor-backup}
export VELERO_BACKUP_REPO_NAME=${VELERO_BACKUP_REPO_NAME:-backup}

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/harbor-backup-volume-policy создан

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

    Как определить, поддерживает ли PVC снапшоты?

    WARNING

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

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ${BACKUP_POLICY_NAME}-volume-policy
  namespace: cpaas-system
data:
  resourcepolicies: |
    version: v1
    volumePolicies:
+      - conditions:
+          storageClass:
+            - ceph
+        action:
+          type: 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:-harbor-backup}
export VELERO_BACKUP_REPO_NAME=${VELERO_BACKUP_REPO_NAME:-backup}

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:
    - ${HARBOR_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:
    - ${HARBOR_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/harbor-backup создан
# backup.velero.io/harbor-backup-r6hht создан

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

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

# Вывод
# time="2025-07-01T07:29:54Z" level=info msg="PodVolumeBackup completed" controller=PodVolumeBackup logSource="pkg/controller/pod_volume_backup_controller.go:244" pvb=harbor-backup-xxx-q7prc

    Проверка статуса задачи. Если статус 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}

# Вывод
# Completed

    После успешного резервного копирования отключите режим только для чтения в Harbor

    Войдите в Harbor и снимите галочку в Administration -> Configuration -> System Settings -> Repository Read Only.

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

    Подготовка

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

    1. Выбор резервной копии для восстановления
    2. Определение целевого пространства имён для восстановления
    3. Удаление оператора HARBOR CE

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

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

    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

# Вывод:
# harbor-backup-xxx     Completed       2025-07-01T07:29:19Z

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

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

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

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

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

    Удаление оператора HARBOR CE

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

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

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

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

    1. Оператор может заново создавать рабочие нагрузки на основе HARBOR CR, что приведёт к перезапуску или пересозданию восстановленных Pod, в итоге прервав или сорвав восстановление.
    2. Некоторые восстановленные ресурсы могут конфликтовать с существующими, например, Ingress.
    Влияние удаления оператора HARBOR CE

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

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

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

    Восстановление состоит из пяти шагов:

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

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

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

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

if [ -n "${OLD_STORAGECLASS_NAME}" ] && [ -n "${NEW_STORAGECLASS_NAME}" ] && [ ${NEW_STORAGECLASS_NAME} != ${OLD_STORAGECLASS_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_STORAGECLASS_NAME}
          - operation: replace
            path: /spec/storageClassName
            value: ${NEW_STORAGECLASS_NAME}
      - conditions:
          groupResource: persistentvolume
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches: *a1
      - conditions:
          groupResource: persistentvolumeclaims
          resourceNameRegex: .*
          namespaces:
            - "*"
        patches:
          - operation: test
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${HARBOR_NAMESPACE}
          - operation: replace
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${NEW_HARBOR_NAMESPACE}
kind: ConfigMap
metadata:
  labels:
    component: velero
  name: harbor-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: test
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${HARBOR_NAMESPACE}
          - operation: replace
            path: "/metadata/annotations/meta.helm.sh~1release-namespace"
            value: ${NEW_HARBOR_NAMESPACE}
kind: ConfigMap
metadata:
  labels:
    component: velero
  name: harbor-restore-modifier
  namespace: cpaas-system
EOF
fi

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

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

    kubectl create -f - <<EOF
apiVersion: velero.io/v1
kind: Restore
metadata:
  generateName: ${HARBOR_NAME}-restore-
  namespace: cpaas-system
spec:
  backupName: ${BACKUP_NAME}
  hooks: {}
  includedNamespaces:
    - ${HARBOR_NAMESPACE}
  includedResources:
    - persistentvolumeclaims
    - persistentvolumes
    - secrets
    - pods
    - harbors.operator.alaudadevops.io
    - volumesnapshots
    - volumesnapshotcontents
  itemOperationTimeout: 10h0m0s
  namespaceMapping:
    ${HARBOR_NAMESPACE}: ${NEW_HARBOR_NAMESPACE}
  resourceModifier:
    kind: configmap
    name: harbor-restore-modifier
EOF

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

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

# Вывод
# time="2025-07-01T08:01:41Z" level=info msg="Async fs restore data path completed" PVR=xxxx-HARBOR-restore-mv6l5-sc4pk controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:275" pvr=xxxx-HARBOR-restore-mv6l5-sc4pk
# time="2025-07-01T08:01:41Z" level=info msg="Restore completed" controller=PodVolumeRestore logSource="pkg/controller/pod_volume_restore_controller.go:327" pvr=xxxx-HARBOR-restore-mv6l5-sc4pk

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

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

# Вывод
# xxx-harbor-restore-xxx    InProgress      2025-07-01T10:18:17Z

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

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

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

    kubectl delete configmap,secrets,sa -n ${NEW_HARBOR_NAMESPACE} -l release=${HARBOR_NAME}

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

kubectl get secret -n ${NEW_HARBOR_NAMESPACE} | grep sh.helm.release.v1.${HARBOR_NAME} | awk '{print $1}' | xargs kubectl delete secret -n ${NEW_HARBOR_NAMESPACE}

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

    kubectl edit harbor ${HARBOR_NAME} -n ${NEW_HARBOR_NAMESPACE}

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

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

    Развёртывание оператора HARBOR CE

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

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

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

    • Группы
    • Репозитории
    • Образы

    Одновременно отключите режим только для чтения для восстановленного экземпляра Harbor (войдите в Harbor и снимите галочку в Administration -> Configuration -> System Settings -> Repository Read Only).

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

    Как определить, поддерживает ли PVC снапшоты?

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

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

    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-драйвер должен поддерживать операции со снапшотами