30.11.2023 12:53
fil106 0 3000 Источник

Разработчикам и системным администраторам важно обеспечивать надежность и доступность данных в приложениях Kubernetes. Несмотря на высокую степень автоматизации и управления контейнерами, всегда остаются риски сбоев или человеческих ошибок — поэтому необходимо заранее задуматься о резервном копировании.

Меня зовут Филипп, я системный администратор в отделе Data- и ML-продуктов Selectel. В этой статье постараюсь раскрыть, какие есть решения для резервного копирования в Kubernetes, и на простом примере покажу, как с ними работать. Подробности под катом.

Оглавление

→ Резервное копирование в Kubernetes
→ Какие есть варианты
→ Подготовка рабочего окружения
→ Резервное копирование на базе K8up
→ Резервное копирование на базе Kasten K10 by Veeam

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


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


Важно отметить, что в Kubernetes управление постоянным хранилищем осуществляется через основные компоненты:

  • PVC (Persistent Volume Claim) — это запрос на использование хранилища со стороны приложения или пользователя.
  • PV (Persistent Volume) — Физическое или логическое хранилище в кластере, которое может быть связано с внешними хранилищами.
  • Storage Class — определяет, как PV создается.
  • CSI (Container Storage Interface) — плагин, который позволяет взаимодействовать с различными внешними хранилищами.
  • Внешнее хранилище: Облачное или локальное хранилище, где фактически хранятся данные.


Также Kubernetes поддерживает парадигму Infrastructure as code, IaC. Это позволяет автоматизировать и стандартизировать развертывание и управление ресурсами с помощью GitOps. Однако даже в таком случае есть важная деталь, которую нельзя игнорировать: сохранность данных.

Пока ресурсы типа config-map, secret, deployment, service, ingress и другие могут быть воссозданы из кода по IaC, данные в PV восстановить в случае сбоя, удаления или взлома не получится.


Какие есть варианты




Можно придумать разные способы создания резервной копии постоянных данных. Это могут быть, например, кастомные скрипты, которые запускаются по расписанию (cron) и создают снапшоты (снимки) самих PV.

При создании снимков PV могут возникнуть проблемы, если во время процесса в базу данных активно записываются данные. Например, снапшот может получиться неполным или поврежденным. Тогда при попытке восстановиться есть риск, что база данных запустится некорректно.

Однако есть сложные системы, которые обеспечивают непрерывное резервное копирование и автоматическое восстановление в случае сбоя. Среди них — Velero.io, Kaste K10, Cohesity, Portworx и другие.

Выбор стратегии резервного копирования будет зависеть от текущей реализации. Например, если ваше высоконагруженное приложение запущено в Managed Kubernetes, а стремительно растущие базы данных — на сетевых дисках, необходимо подумать о том, чтобы резервное копирование не влияло на работоспособность IT-систем.

Например, если основная база данных — PostgreSQL, необходимо подумать о бэкапировании с помощью streaming replication и настроить резервное копирование на secondary-реплике через pg_dump, pg_basebackup, Barman или WAL-E. А также — определиться с периодичностью бэкапирования, его шифрованием, способом хранения, мониторингом и проверкой восстановления из резервных копий.

Далее мы рассмотрим два инструмента K8UP и Kasten K10 от Veeam, которые предоставляют различные функции для резервного копирования. Но прежде подготовим тестовый стенд в облаке Selectel.


Подготовка рабочего окружения


Подготовим тестовый стенд, в который установим простейшее приложение с постоянным хранилищем данных. За основу возьмем Managed Kubernetes, а в качестве хранилища резервных копий — объектное хранилище S3, к которому настроим доступ через сервисного пользователя и S3-ключ.

Подготовка кластера Managed Kubernetes


В панели управления нужно перейти в раздел Kubernetes:




Далее дождитесь статуса ACTIVE и скачайте kubeconfig для дальнейшей работы с кластером:


Для работы с кластером можно использовать Lens или Kubectl. Для kubectl необходимо указать переменную KUBECONFIG:

 #: export KUBECONFIG=<ПОЛНЫЙ ПУТЬ ДО KUBECONFIG ФАЙЛА>

В качестве проверки можно получить пространство имен кластера:

#: kubectl get namespace

Подготовка объектного хранилища



Далее нужно создать и настроить контейнер: ввести его название, выбрать Приватный тип, класс хранения Стандартное хранение и нажать кнопку.


Создание сервисного пользователя и ключа S3






Важно: S3 access и secret keys необходимо сохранить в надежном месте.

Установка тестового приложения в кластере


Теперь осталось установить в кластер простейшее тестовое приложение. Для этого подготовим манифест создания Storage Class, Deployment и Persistent Volume Claim и применим его:

# nginx-pvc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: 'true'
provisioner: cinder.csi.openstack.org
parameters:
  availability: ru-9a
  fsType: ext4
  type: fast.ru-9a
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-volume
              mountPath: /usr/share/nginx/html
      volumes:
        - name: nginx-volume
          persistentVolumeClaim:
            claimName: nginx-pvc


#: kubectl apply -f nginx-pvc.yaml

Готово — теперь можем начать работу с инструментами резервного копирования в Kubernetes.

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


K8up (/keɪtæpp/ или просто «кетчуп») — это оператор для автоматизации резервного копирования данных в Kubernetes, в основе которого лежит restic.

Возможности инструмента

  • Автоматическое копирование данных из PVC и БД.
  • Запуск резервного копирования по требованию и расписанию.
  • Сохранение копий в разных местах, включая Amazon S3 и Minio.
  • Восстановление данных через командную строку.
  • Возможность создавать резервные копии, которые учитывают особенности приложений и включают в себя результаты работы любого инструмента, способного выдавать данные в стандартный поток вывода.

Установка


Рассмотрим процесс установки и настройки K8up в подготовленном рабочем окружении. Для наглядности представим схему работы инструмента.


Устанавливаем Custom Resource Definition:

#: kubectl apply -f https://github.com/k8up-io/k8up/releases/download/k8up-4.4.1/k8up-crd.yaml

Для удобства устанавливаем K8up в отдельное пространство имен:

#: kubectl create namespace k8up
#: helm repo add k8up-io https://k8up-io.github.io/k8up
#: helm install -n k8up k8up k8up-io/k8up

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


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

Секреты для доступа по S3

Ранее мы подготовили объектное хранилище. Теперь создадим секреты, чтобы у K8up был к нему доступ. Укажем токен доступа к S3 и пароль для restic-репозитория:

# secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: "s3-secrets"
  namespace: k8up
stringData:
  bucket: "<BUCKET NAME>"
  password: ”<S3 SECRET KEY>”
  username: ”<S3 ACCESS KEY>”
---
apiVersion: v1
kind: Secret
metadata:
  name: "restic-repository-password"
  namespace: k8up
stringData:
  password: "secret_pass" # Это пароль для restic repository - создается при инициализации, его можно поменять на любой, желательно надежный и состоящий из более чем 16 символов

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

#: kubectl apply -f secrets.yaml

Подготовительные работы выполнены, теперь можем приступить к созданию резервных копий.

Создание снимка из PVC


Теперь попробуем сделать бэкап данных приложения, которое мы задеплоили на этапе подготовки рабочего окружения. Для этого необходимо создать Custom Resource для K8up, тем самым объяснить, что и как мы хотим копировать.

Создадим CR-Backup, который сделает резервное копирование всех PVC в пространстве имен, где будет создан данный ресурс, а после — применим манифест:

# backup.yaml
apiVersion: k8up.io/v1
kind: Backup
metadata:
  name: k8up-test-swift
  namespace: k8up
spec:
  failedJobsHistoryLimit: 4
  successfulJobsHistoryLimit: 0
  backend:
    repoPasswordSecretRef:
      name: "restic-repository-password"
      key: "password"
    s3:
      accessKeyIDSecretRef:
        key: username
        name: s3-secrets
      bucket: test
      endpoint: s3.ru-1.storage.selcloud.ru
      secretAccessKeySecretRef:
        key: password
        name: s3-secrets


#: kubectl apply -f backup.yaml

После создания ресурса K8up автоматически начнет поиск и создание снимков всех PVC с режимами доступа к хранилищу типа RMX (ReadMany, Execute) и RWO (ReadWriteOnce). Если все было выполнено правильно, мы должны увидеть успешно завершенный под с именем “backup-k8up-....”, который подмонтировал к себе нужный PVC (в нашем случае — nginx-pvc) и создал снимок файловой системы с помощью restic, пример успешно завершенного пода представлен на скриншоте ниже:


Под K8up.


То же самое можно проверить через CLI с помощью команд:

#: kubectl get -A backups.k8up.io
#: kubectl get -A snapshots.k8up.io

В K8up также можно настроить резервное копирование по расписанию, добавить проверку целостности с помощью custom-resource — Schedule.

Восстановление из снимка PVC


Локальное восстановление


Можно установить утилиту restic и подмонтировать снимок локально, указав чувствительные данные для доступа к объектному хранилищу. Но прежде необходимо узнать SNAPSHOT ID:

RESTIC_REPOSITORY="s3://s3.ru-1.storage.selcloud.ru/<S3-BUCKET NAME>/<S3 K8UP FOLDER PATH>" \
AWS_ACCESS_KEY_ID="" \
AWS_SECRET_ACCESS_KEY="" \
RESTIC_PASSWORD="" \
restic snapshots

Теперь мы можем скопировать к себе резервную копию командой:

RESTIC_REPOSITORY="s3://s3.ru-1.storage.selcloud.ru/<S3-BUCKET NAME>/<S3 K8UP FOLDER PATH>" \
AWS_ACCESS_KEY_ID="" \
AWS_SECRET_ACCESS_KEY="" \
RESTIC_PASSWORD="" \
restic restore <SNAPSHOT ID> --target ~/Desktop/mnt/

В папке ~/Desktop/mnt/ можно увидеть все файлы, находящиеся в снимке.

Восстановление в кластере Custom Resource


Для демонстрации изменим index.html — вернем предыдущее состояние файла до внесения правок. Просто добавим какой-то текст в файл index.html, например Hacker destroyed this site!


Теперь восстановим предыдущее состояние файла в кластере, для этого необходимо создать customResource Restore и новый PVC, в который будем восстанавливать данные:

# restore.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: restore-test-mfw
  namespace: k8up
  annotations:
    # set to "true" to include in future backups
    k8up.io/backup: "false"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: k8up.io/v1
kind: Restore
metadata:
  name: restore-test-mfw
  namespace: k8up
spec:
  podSecurityContext:
    fsGroup: 65532
    fsGroupChangePolicy: OnRootMismatch
  restoreMethod:
    folder:
      claimName: restore-test-mfw
  backend:
    envFrom:
    - secretRef:
        name: "open-stack-secret"
    repoPasswordSecretRef:
      name: "restic-repository-password"
      key: "password"
    swift:
      path: "/container-path"
      container: "cmlp-testing-rpd-5921-ff-research-k8up"

В качестве восстановленной PVC можем указать новую, в которую восстановили бэкап при помощи следующей CLI команды:

kubectl patch -n k8up deployment nginx-deployment -p '{"spec":{"template":{"spec":{"volumes":[{"name":"nginx-volume","persistentVolumeClaim":{"claimName":"restore-test-mfw"}}]}}}}'

И убедиться, что файл index.html будет без внесенных изменений, т.е. файл будет восстановлен из резервной копии.

Создание бэкапа баз данных


Проблема при создании бэкапов баз данных в том, что необходимо остановить запись в базу, чтобы на момент создания снимка не было никаких активных и открытых ячеек. Иначе в резервной копии будут незавершенные операции.

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

Добавление аннотаций


Процесс создания аннотаций и их описание есть в документации K8up. Ниже — основные конфигурации для них.

annotations:
        k8up.io/backupcommand: sh -c 'mongodump --username=$MONGODB_ROOT_USER --password=$MONGODB_ROOT_PASSWORD --archive'
            k8up.io/file-extension: .archive

Конфигурация аннотации MongoDB.

annotations:
      k8up.io/backupcommand: sh -c 'PGDATABASE="$POSTGRES_DB" PGUSER="$POSTGRES_USER" PGPASSWORD="$POSTGRES_PASSWORD" pg_dump --clean'
      k8up.io/file-extension: .sql

Конфигурация аннотации PostgreSQL.

<SNIP>
template:
  metadata:
    labels:
      app: my-db
    annotations:
      k8up.io/backupcommand: sh -c 'PGDATABASE="$POSTGRES_DB" PGUSER="$POSTGRES_USER" PGPASSWORD="$POSTGRES_PASSWORD" pg_dump --clean'
      k8up.io/file-extension: .sql
      k8up.io/backupcommand-container: postgres
  spec:
    containers:
      - name: pgbouncer
      - name: postgres
      - name: prometheus-exporter
        ...
<SNIP>

Сборка аннотации на определенный контейнер.

Резервное копирование на базе Kasten K10 by Veeam



Kasten K10 создан специально для Kubernetes и представляет собой платформу управления данными Cloud Native для операций «второго дня».

Возможности инструмента


Инструмент предоставляет командам DevOps простую, масштабируемую и безопасную систему для резервного копирования и восстановления приложений Kubernetes. Kasten K10 можно интегрировать с реляционными и NoSQL-базами данных и основными дистрибутивами Kubernetes.

Важно: бесплатная версия Kasten K10 ограничена пятью нодами.

Установка


PRE-FLIGHT проверки


Проверим наличие всех необходимых компонентов для Kasten K10:

#: curl <a href="https://docs.kasten.io/tools/k10_primer.sh">https://docs.kasten.io/tools/k10_primer.sh</a> | bash

В выводе команды мы увидим, чего не хватает для корректной работы K10. В нашем случае отсутствует CRD для создания снапшотов. Решим эту проблему.

Выведем имеющиеся для Volume CRD:

#: kubectl api-resources | grep volume

Теперь мы можем установить недостающие CRD и проверить, что они появились в списке api-resources:

#: kubectl apply -f https://raw.githubusercontent.com/selectel/mks-csi-snapshotter/master/deploy/setup-snapshot-controller.yaml


#: kubectl api-resources | grep volume
persistentvolumeclaims                pvc                     v1                                          true         PersistentVolumeClaim
persistentvolumes                     pv                      v1                                          false        PersistentVolume
volumesnapshotclasses                 vsclass,vsclasses   snapshot.storage.k8s.io/v1                  false        VolumeSnapshotClass
volumesnapshotcontents                vsc,vscs                snapshot.storage.k8s.io/v1                  false        VolumeSnapshotContent
volumesnapshots                       vs                      snapshot.storage.k8s.io/v1                  true         VolumeSnapshot
volumeattachments                                         storage.k8s.io/v1                           false        VolumeAttachment

Повторно прогоняем проверки PRE-FLIGHT:

#: curl <a href="https://docs.kasten.io/tools/k10_primer.sh">https://docs.kasten.io/tools/k10_primer.sh</a> | bash

Ошибка по CRD-Base пропала, но появилась новая: CSI Provisioner doesn't have VolumeSnapshotClass — Error. Все верно: CRD есть, а VolumeSnapshotClass отсутствует. Попробуем решить эту проблему.

Рабочий вариант — вручную подготовить манифест. Приведу пример для Cinder OpenStack. Подробнее о драйверах можно почитать на сайте.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
driver: cinder.csi.openstack.org
metadata:
  annotations:
    k10.kasten.io/is-snapshot-class: "true"
  name: csi-hostpath-snapclass-v1
deletionPolicy: Delete

Применим манифест и проверим наличие ресурса VolumeSnapshotClass:

#: kubectl apply -f VolumeSnapshotClass.yaml
volumesnapshotclass.snapshot.storage.k8s.io/cinder-csi-openstack-org created
#: kubectl get -f VolumeSnapshotClass.yaml
NAME                           DRIVER                         DELETIONPOLICY   AGE
csi-hostpath-snapclass-v1   cinder.csi.openstack.org   Delete               20s

Теперь можем снова запустить проверку PRE-FLIGHT:

#: curl https://docs.kasten.io/tools/k10_primer.sh | bash

Все пункты должны быть в статусе ОК.

Дополнительно необходимо добавить аннотацию k10.kasten.io/volume-snapshot-class в default storage-class:

#: kubectl annotate storageclass default \
    k10.kasten.io/volume-snapshot-class=csi-hostpath-snapclass-v1

На этом предварительные настройки для работы Kasten K10 закончены. Теперь можем перейти к установке самого инструмента.

Установка Kasten K10


Добавляем репозиторий Kasten:

#: helm repo add kasten https://charts.kasten.io/

Создаем отдельное пространство имен:

#: kubectl create namespace kasten-io

Устанавливаем Helm-чарт с включением sidecar kanister, который необходим для создания снапшотов. С версии Kasten K10 6.5.0 он по умолчанию выключен.

#: helm install k10 kasten/k10 --namespace=kasten-io --set injectKanisterSidecar.enabled=true --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecar=true

Дожидаемся полной установки компонентов и пробрасываем порт на локальный хост:

#: kubectl get pods --namespace kasten-io --watch


#: kubectl --namespace kasten-io port-forward service/gateway 8080:8000

Теперь можем открыть веб-интерфейс по следующему адресу:

http://127.0.0.1:8080/k10/#/dashboard

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


Для создания резервных копий из снимков, перемещения приложений и их данных между кластерами и разными облаками, а также — последующего импорта/экспорта этих резервных копий в другой кластер используются профили хранилища.

Инициализация профиля S3


Как и в случае с K8up, настроим объектное хранилище в качестве основного для всех резервных копий. Это можно сделать как через веб-интерфейс, так и с помощью YAML-манифестов.

Создадим и настроим S3-профиль хранения резервных копий в объектном хранилище Selectel. Для этого перейдем на страницу профилей (http://127.0.0.1:8080/k10/#/profiles/location) — нас встретит такая страница:



Важно: в качестве endpoint нужно указать s3.ru-1.storage.selcloud.ru

Далее необходимо сохранить профиль. Если все сделали правильно, в списке увидите профиль со статусом VALID:


Настройка резервного копирования


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

Укажем label для пространства имен, куда установлено приложение. В нашем случае namespace=default:

#: kubectl label namespace default k10/injectKanisterSidecar=true

Создадим Policy. Это можно сделать из веб-панели Kasten K10, но мы воспользуемся манифестом:

#sample-backup-action.yam
apiVersion: config.kio.kasten.io/v1alpha1
kind: Policy
metadata:
  name: test
  namespace: kasten-io
spec:
  frequency: "@hourly"
  paused: false
  actions:
    - action: backup
      backupParameters:
        profile:
          name: selectel-s3
          namespace: kasten-io
    - action: export
      exportParameters:
        frequency: "@hourly"
        migrationToken:
          name: test-migration-token
          namespace: kasten-io
        exportData:
          enabled: true
      retention: {}
  retention:
    hourly: 24
    daily: 7
    weekly: 4
    monthly: 12
    yearly: 7
  selector:
    matchExpressions:
      - key: k10.kasten.io/appNamespace
        operator: In
        values:
          - default

Применим манифест в кластере:

#: kubectl create -f sample-backup-action.yaml

Если все сделано правильно, должен создаться backupaction. Его можно вывести с помощью специальной команды:

#: kubectl get backupactions.actions.kio.kasten.io
NAME              CREATED AT             STATE      PCT
scheduled-pwbvk   2023-11-02T09:08:00Z   Complete   100

Во вкладке Action веб-интерфейса можно проверить статус резервного копирования:


Копируем файл в приложение


Для проверки восстановления из резервной копии скопируем файл, например, Snapshot-class.yaml и вручную запустим бэкапирование. После удалим файл и восстановимся из резервной копии.

Копируем файл Snapshot-class.yaml:

#: kubectl cp Snapshot-class.yaml default/nginx-deployment-5dcc6d978b-lc96j:/usr/share/nginx/html/

Вручную запускаем резервное копирование. Это можно сделать на странице Policies:


Дожидаемся завершения резервного копирования (статус можно отслеживать на странице Dashboard), а после — удаляем файл из примонтированной папки в контейнере:

#: kubectl --namespace default exec -it nginx-deployment-5dcc6d978b-ps6rs -- /bin/sh
Defaulted container "nginx-container" out of: nginx-container, kanister-sidecar
# rm /usr/share/nginx/html/Snapshot-class.yaml

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


Теперь можем проверить, восстанавливается ли система из резервной копии.

Перейдем во вкладку Application → Item-Menu → Restore:


Выберем нужную точку восстановления:


В появившемся окне Restore Point выберем приложение, поставим галочку рядом с Data-Only Restore и нажмем кнопку Restore:


Необходимо дождаться, пока задача на восстановление будет выполнена, и проверить, что ранее удаленный файл снова доступен в примонтированной папке:


Готово — резервное копирование на базе Kasten K10 работает!

Подводим итоги


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

В своей ML-платформе мы используем инструмент K8up для резервного копирования важной информации — например, служебных данных ClearML. В качестве хранилища используем объектное хранилище. K8up создает файловые копии один раз в день, а также проверяет их на целостность.

Если вам интересно посмотреть, как это работает на практике, протестируйте нашу ML-платформу. Мы разворачиваем ее индивидуально для каждого клиента и можем включить в сборку такие open source-инструменты, как ClearML или Kubeflow. В общем, все для того, чтобы вы смогли организовать полный цикл обучения и тестирования ML-моделей.

Комментарии (0)