Как выполнить резервное копирование и восстановление с использованием TrilioVault в DOKS

Введение

В этом руководстве вы узнаете, как развернуть TrilioVault для Kubernetes (или TVK) на вашем кластере DOKS, создавать резервные копии и восстанавливаться из резервной копии в случае проблем. Вы можете создавать резервные копии всего кластера или выбирать резервные копии на основе пространства имен или меток.

Преимущества использования Trilio:

• Создавайте полные (или дифференциальные) резервные копии кластера и восстанавливайтесь в случае потери данных.
• Переносите данные с одного кластера на другой.
• Поддерживаются резервные копии релизов Helm.
• Запускайте предварительные и пост-хуки для операций резервного копирования и восстановления.
• Веб-консоль управления, которая позволяет подробно проверить состояние ваших операций по резервному копированию/восстановлению.
• Задавайте политики удержания для ваших резервных копий.
• Жизненный цикл приложения (то есть, TVK сам) можно управлять с помощью специального оператора TrilioVault`.
• Интеграция с Velero.
• Вы можете создавать резервные копии и восстанавливать приложения, основанные на операторе.

Дополнительную информацию можно найти в официальной документации TVK CRDs.

Содержание

• Предварительные условия
• Шаг 1 – Установка TrilioVault для Kubernetes
• Шаг 2 – Создание цели TrilioVault для хранения резервных копий
• Шаг 3 – Знакомство с веб-консолью управления TVK
• Шаг 4 – Пример резервного копирования и восстановления с пространством имен
• Шаг 5 – Пример резервного копирования и восстановления всего кластера
• Шаг 6 – Запланированные резервные копии
• Шаг 7 – Политика хранения резервных копий
• Заключение

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

Для завершения этого учебного пособия вам понадобятся следующие инструменты:

1. A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
2. A Git client to clone the Starter Kit repository.
3. Helm, для управления выпусками и обновлениями TrilioVault Operator.
4. Doctl для взаимодействия с API DigitalOcean.
5. Kubectl для взаимодействия с Kubernetes.

Чтобы TrilioVault работал корректно и выполнял резервное копирование ваших PVC, DOKS должен быть настроен для поддержки интерфейса хранилища контейнеров (или CSI в кратком виде). По умолчанию он поставляется с уже установленным и настроенным драйвером. Вы можете проверить с помощью следующей команды:

kubectl get storageclass

Вывод должен выглядеть примерно так:dobs.csi.digitalocean.com.

NAME                         PROVISIONER                 RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
do-block-storage (default)   dobs.csi.digitalocean.com   Delete          Immediate           true                   10d

Для успешной установки TrilioVault также необходимо наличие Определения Пользовательского Ресурса (CRD) volumeSnapshot. Вы можете проверить с помощью следующей команды:

kubectl get crd | grep volumesnapshot

Вывод должен выглядеть примерно так. Если CRD VolumeSnapshot не установлен, обратитесь к Установка CRD VolumeSnapshot.

volumesnapshotclasses.snapshot.storage.k8s.io         2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io        2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io               2022-02-01T06:01:15Z

Также убедитесь, что CRD поддерживает обе версии API v1beta1 и v1. Вы можете запустить следующую команду, чтобы проверить версию API:

kubectl get crd volumesnapshots.snapshot.storage.k8s.io -o yaml

В конце YAML-файла CRD должен быть список storedVersions, содержащий значения v1beta1 и v1 (если не установлен, обратитесь к Установка CRD VolumeSnapshot):

...
- lastTransitionTime: "2022-01-20T07:58:06Z"
    message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
    reason: ApprovedAnnotation
    status: "True"
    type: KubernetesAPIApprovalPolicyConformant
  storedVersions:
  - v1beta1
  - v1

Шаг 1 – Установка TrilioVault для Kubernetes

В этом шаге вы узнаете, как развернуть TrilioVault для DOKS и управлять установками TVK с помощью Helm. Резервные копии данных будут храниться в созданном ранее в разделе Предварительные требования ведре DO Spaces.

Приложение TrilioVault можно установить несколькими способами:

• Через оператор TrilioVault. Вы определяете CRD TrilioVaultManager, который сообщает оператору TrilioVault, как обрабатывать установку, постконфигурационные шаги и будущие обновления компонентов приложения Trilio.
• Через чарт triliovault-operator, полностью управляемый с помощью Helm, (рассмотрено в этом руководстве).

Установка TrilioVault с использованием Helm

Сначала клонируйте репозиторий Git Starter Kit и перейдите в каталог вашей локальной копии:

git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git
cd Kubernetes-Starter-Kit-Developers

Затем добавьте репозиторий TrilioVault Helm и перечислите доступные чарты:

helm repo add triliovault-operator http://charts.k8strilio.net/trilio-stable/k8s-triliovault-operator
helm repo update triliovault-operator
helm search repo triliovault-operator

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

NAME                                            CHART VERSION   APP VERSION     DESCRIPTION
triliovault-operator/k8s-triliovault-operator   2.9.2           2.9.2           K8s-TrilioVault-Operator is an operator designe...

Затем откройте и проверьте файл значений TrilioVault Helm, предоставленный в репозитории Starter kit, используя редактор на ваш выбор (желательно с поддержкой YAML линта).

code 05-setup-backup-restore/assets/manifests/triliovault-values-v2.9.2.yaml

Наконец, установите TrilioVault для Kubernetes, используя Helm:

helm install triliovault-operator triliovault-operator/k8s-triliovault-operator \
  --namespace tvk \
  --create-namespace \
  -f 05-setup-backup-restore/assets/manifests/triliovault-values.yaml

installTVK.ComponentConfiguration.ingressController.service.type для типа службы, предназначенной для доступа к TVK UI, например NodePort или LoadBalancer

helm ls -n tvk

Теперь проверьте развертывание TVK:

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
triliovault-manager-tvk tvk             1               2022-06-08 08:30:08.490304959 +0000 UTC deployed        k8s-triliovault-2.9.2           2.9.2
triliovault-operator    tvk             1               2022-06-08 11:32:55.755395 +0300 EEST   deployed        k8s-triliovault-operator-2.9.2  2.9.2

Выходные данные выглядят примерно так (Статус столбец должен отображать развернут):

kubectl get deployments -n tvk

Затем убедитесь, что TrilioVault запущен и работает:

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
k8s-triliovault-admission-webhook               1/1     1            1           83s
k8s-triliovault-control-plane                   1/1     1            1           83s
k8s-triliovault-exporter                        1/1     1            1           83s
k8s-triliovault-ingress-nginx-controller        1/1     1            1           83s
k8s-triliovault-web                             1/1     1            1           83s
k8s-triliovault-web-backend                     1/1     1            1           83s
triliovault-operator-k8s-triliovault-operator   1/1     1            1           4m22s

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

Если вывод выглядит так, вы успешно установили TVK. Затем вы узнаете, как проверить тип и действительность лицензии, а также как ее продлить.

Лицензирование приложения TrilioVault

Примеры стартового набора зависят от типа лицензии Кластер для правильной работы.

Создание и проверка лицензирования приложения TVK

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/tvk_install_license.yaml

Запустите следующую команду, чтобы создать новую лицензию для вашего кластера (она управляется с помощью CRD лицензии):

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

Если вы загружаете бесплатную лицензию с веб-сайта Trilio, примените ее с помощью этой команды:

kubectl get license -n tvk

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

NAME             STATUS   MESSAGE                                   CURRENT NODE COUNT   GRACE PERIOD END TIME   EDITION     CAPACITY   EXPIRATION TIME        MAX NODES
test-license-1   Active   Cluster License Activated successfully.   1                                            FreeTrial   100000     2023-02-25T00:00:00Z   1

Вывод выглядит примерно следующим образом. Обратите внимание на STATUS, который должен быть Active, а также на тип лицензии в столбце EDITION и EXPIRATION TIME.

kubectl describe license test-license-1 -n tvk

Лицензия управляется с помощью специального CRD, называемого объектом License. Вы можете осмотреть его, выполнив следующую команду:

Name:         test-license-1
Namespace:    tvk
Labels:       <none>
Annotations:
              generation: 1
              triliovault.trilio.io/creator: system:serviceaccount:tvk:k8s-triliovault
              triliovault.trilio.io/instance-id: b060660d-4851-482b-8e60-4addd260e1d3
              triliovault.trilio.io/updater:
                [{"username":"system:serviceaccount:tvk:k8s-triliovault","lastUpdatedTimestamp":"2022-02-24T06:38:21.418828262Z"}]
API Version:  triliovault.trilio.io/v1
Kind:         License
Metadata:
  Creation Timestamp:  2022-02-24T06:38:21Z
...
Status:
  Condition:
    Message:           License Key changed
    Timestamp:         2022-02-24T06:38:21Z
    Message:           Cluster License Activated successfully.
    Status:            Active
    Timestamp:         2022-02-24T06:38:21Z
  Current Node Count:  1
  Max Nodes:           1
  Message:             Cluster License Activated successfully.
  Properties:
    Active:                        true
    Capacity:                      100000
    Company:                       TRILIO-KUBERNETES-LICENSE-GEN-DIGITALOCEAN-BASIC
    Creation Timestamp:            2022-02-24T00:00:00Z
    Edition:                       FreeTrial
    Expiration Timestamp:          2023-02-25T00:00:00Z
    Kube UID:                      b060660d-4851-482b-8e60-4addd260e1d3
    License ID:                    TVAULT-5a4b42c6-953c-11ec-8116-0cc47a9fd48e
    Maintenance Expiry Timestamp:  2023-02-25T00:00:00Z
    Number Of Users:               -1
    Purchase Timestamp:            2022-02-24T00:00:00Z
    Scope:                         Cluster
...

Вывод выглядит примерно следующим образом. Обратите внимание на поля Message и Capacity, а также на Edition.

Вышеуказанный вывод также сообщит вам, когда истечет срок действия лицензии в поле Время истечения срока действия, а также Область применения (в этом случае Cluster). Вы можете выбрать лицензию для всего кластера или лицензию на основе пространства имен.

Обновление лицензии на приложение TVK

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

Чтобы продлить лицензию, вам нужно запросить новую на веб-сайте Trilio, перейдя на страницу лицензирования, чтобы заменить старую. После заполнения формы вы должны получить манифест YAML лицензии, который можно применить к вашему кластеру с помощью kubectl. Приведенные ниже команды предполагают, что TVK установлен в пространстве имен tvk по умолчанию (пожалуйста, замените необходимые места с <>):

Затем вы можете проверить статус новой лицензии, как уже изучили ранее:
kubectl get license -n tvk

# Сначала перечислите доступные лицензии TVK из пространства имен `tvk`
kubectl describe license <YOUR_LICENSE_NAME_HERE> -n tvk

# Получите информацию о конкретной лицензии из пространства имен `tvk`

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

Шаг 2 – Создание цели TrilioVault для хранения резервных копий

A typical Target definition looks like:

apiVersion: triliovault.trilio.io/v1
kind: Target
metadata:
  name: trilio-s3-target
  namespace: tvk
spec:
  type: ObjectStore
  vendor: Other
  enableBrowsing: true
  objectStoreCredentials:
    bucketName: <YOUR_DO_SPACES_BUCKET_NAME_HERE>
    region: <YOUR_DO_SPACES_BUCKET_REGION_HERE>
    url: 'https://<YOUR_DO_SPACES_BUCKET_ENDPOINT_HERE>'
    credentialSecret:
      name: trilio-s3-target
      namespace: tvk
  thresholdCapacity: 10Gi

TrilioVault сначала должен знать, где хранить ваши резервные копии. TrilioVault обращается к хранилищу, используя термин target, и его управление осуществляется с помощью специального CRD с именем Target. Поддерживаются следующие типы целей: S3 и NFS. Для DigitalOcean и целей стартового комплекта имеет смысл полагаться на тип хранилища S3, потому что он дешев и масштабируем. Чтобы получить дополнительный уровень защиты, вы можете создать несколько типов целей (как для S3, так и для NFS), чтобы ваши данные оставались в безопасности в нескольких местах, тем самым обеспечивая резервирование резервных копий.

• В этой конфигурации,
• spec.type: Тип цели для хранения резервных копий (S3 – объектное хранилище).
• spec.vendor: Хостинг цели сторонним поставщиком хранилища (для DigitalOcean Spaces вам нужно использовать Other вместо AWS).
• spec.enableBrowsing: Включение просмотра для цели.
• spec.objectStoreCredentials: Определяет необходимые учетные данные (через credentialSecret) для доступа к хранилищу S3, а также другие параметры, такие как регион и имя бакета.

spec.thresholdCapacity: Максимальная пороговая емкость для хранения данных резервных копий.

apiVersion: v1
kind: Secret
metadata:
  name: trilio-s3-target
  namespace: tvk
type: Opaque
stringData:
  accessKey: <YOUR_DO_SPACES_ACCESS_KEY_ID_HERE> Для доступа к хранилищу S3 каждой цели нужны учетные данные для ведра. Также необходимо создать секрет Kubernetes:
  secretKey: <YOUR_DO_SPACES_SECRET_KEY_HERE>    # значение должно быть закодировано в base64

# значение должно быть закодировано в base64

Обратите внимание, что имя секрета – trilio-s3-target, и на него ссылается поле spec.objectStoreCredentials.credentialSecret CRD Цели, ранее объясненное. Secret может находиться в том же namespace, где установлен TrilioVault (по умолчанию tvk), или в другом выбранном вами пространстве имен. Просто убедитесь, что вы правильно ссылаетесь на пространство имен. С другой стороны, пожалуйста, убедитесь, что вы защитили пространство имен, где хранятся секреты TrilioVault, через RBAC по соображениям безопасности.

Шаги по созданию Цели для TrilioVault:

cd Kubernetes-Starter-Kit-Developers

Сначала измените каталог, где был клонирован репозиторий Starter Kit на вашем локальном компьютере:

kubectl create secret generic trilio-s3-target \
  --namespace=tvk \
  --from-literal=accessKey="<YOUR_DO_SPACES_ACCESS_KEY_HERE>" \
  --from-literal=secretKey="<YOUR_DO_SPACES_SECRET_KEY_HERE>"

Затем создайте секрет Kubernetes, содержащий учетные данные вашего целевого ведра S3 (замените заполнители <> соответствующим образом):

code 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

–from-literal=accessKey=“<ВАШ_КЛЮЧ_ДОСТУПА_К_DO_SPACES_ЗДЕСЬ>” \

–from-literal=secretKey=“<ВАШ_СЕКРЕТНЫЙ_КЛЮЧ_DO_SPACES_ЗДЕСЬ>”

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

Затем откройте и проверьте целевой файл манифеста, предоставленный в репозитории Starter Kit, используя выбранный вами редактор (желательно с поддержкой YAML lint).

Теперь, замените заполнители <> соответственно для вашего ведра DO Spaces Trilio, такие как bucketName, region, url и credentialSecret.

kubectl get target trilio-s3-target  -n tvk

Наконец, сохраните файл манифеста и создайте объект Target с помощью kubectl:

NAME               TYPE          THRESHOLD CAPACITY   VENDOR   STATUS      BROWSING ENABLED
trilio-s3-target   ObjectStore   10Gi                 Other    Available

Далее, TrilioVault создаст рабочую задачу с именем trilio-s3-target-validator, ответственную за проверку вашего ведра S3 (например, доступность, разрешения и т. д.). Если задача завершится успешно, ведро считается здоровым или доступным, и ресурс задачи trilio-s3-target-validator удаляется после этого. Если что-то пойдет не так, задача валидатора цели S3 останется запущенной, чтобы вы могли проверить журналы и найти возможную проблему.

Вывод выглядит примерно так. Обратите внимание на значение столбца STATUS - должно быть Available, что означает, что он находится в здоровом состоянии.
kubectl get pods -n tvk | grep trilio-s3-target-validator

Если вывод выглядит так, то вы успешно сконфигурировали объект цели S3.
В случае если объект цели не становится здоровым, вы можете проверить журналы из Pod trilio-s3-target-validator, чтобы найти проблему:

# Сначала вам нужно найти целевой валидатор
kubectl logs pod/trilio-s3-target-validator-tio99a-6lz4q -n tvk

...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
  File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
    utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
    mount_s3_datastore(metadata_list, base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
    wait_until_mount(base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
    base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...

#trilio-s3-target-validator-tio99a-6lz4q 1/1 Запущен 0 104с

# Теперь получите данные журналов

Результат будет следующим исключением:

Затем вы обнаружите веб-консоль TVK, которая является полезным дополнением для управления операциями резервного копирования и восстановления, среди многих других.

Шаг 3 – Знакомство с веб-консолью управления TVK

Хотя вы можете управлять операциями резервного копирования и восстановления полностью из командной строки с помощью kubectl и CRD, TVK предоставляет веб-консоль управления для выполнения тех же операций через графический интерфейс. Управление консолью упрощает обычные задачи с помощью операций щелчка мыши, обеспечивает лучшую визуализацию и проверку объектов кластера TVK, а также создание планов восстановления после катастрофы (или DRP).

Установка на основе Helm, рассмотренная в Шаг 1 – Установка TrilioVault для Kubernetes, уже позаботилась о установке необходимых компонентов для веб-консоли управления.

kubectl get svc -n tvk

Получение доступа к веб-консоли управления TVK

NAME                                                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
k8s-triliovault-admission-webhook                               ClusterIP   10.245.202.17    <none>        443/TCP                      13m
k8s-triliovault-ingress-nginx-controller                        NodePort    10.245.192.140   <none>        80:32448/TCP,443:32588/TCP   13m
k8s-triliovault-ingress-nginx-controller-admission              ClusterIP   10.3.20.89       <none>        443/TCP                      13m
k8s-triliovault-web                                             ClusterIP   10.245.214.13    <none>        80/TCP                       13m
k8s-triliovault-web-backend                                     ClusterIP   10.245.10.221    <none>        80/TCP                       13m
triliovault-operator-k8s-triliovault-operator-webhook-service   ClusterIP   10.245.186.59    <none>        443/TCP                      16m

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

Сначала вам нужно определить службу ingress-nginx-controller из пространства имен tvk:
installTVK:
  ingressConfig:
    host: "tvk-doks.com"

Вывод будет похож на следующий. Найдите строку k8s-triliovault-ingress-nginx-controller и обратите внимание, что она прослушивает порт 80 в столбце PORT(S).

127.0.0.1 tvk-doks.com

TVK использует контроллер входящего трафика Nginx для маршрутизации трафика к службам веб-консоли управления. Маршрутизация осуществляется на основе хоста, и имя хоста tvk-doks.com определено в файле значений Helm из Начального комплекта:

kubectl port-forward svc/k8s-triliovault-ingress-nginx-controller 8080:80 -n tvk

# Имя хоста для доступа к веб-консоли через контроллер входящего трафика TVK ingress nginx

Имея вышеуказанную информацию под рукой, пожалуйста, перейдите к редактированию файла /etc/hosts и добавьте эту запись:
doctl k8s cluster list

Затем создайте перенаправление порта для службы контроллера входящего трафика TVK:
doctl kubernetes cluster kubeconfig show <YOUR_CLUSTER_NAME_HERE> > config_<YOUR_CLUSTER_NAME_HERE>.yaml

DOKS_CLUSTER_NAME="$(doctl k8s cluster list --no-header --format Name)"
doctl kubernetes cluster kubeconfig show $DOKS_CLUSTER_NAME > config_${DOKS_CLUSTER_NAME}.yaml

# Перечислите доступные кластеры

Если у вас есть только один кластер, выполните следующую команду:

После выполнения этих шагов вы сможете получить доступ к консоли в веб-браузере, перейдя по адресу: http://tvk-doks.com:8080. Когда будет запрошен файл kubeconfig, выберите тот, который вы создали в предыдущей команде выше.

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

• Изучение пользовательского интерфейса веб-консоли TVK
• Исследуйте каждый раздел слева, например:
• Управление кластером: Здесь показан список основных и других кластеров с экземплярами TVK, добавленных в основной кластер OVH с использованием функции управления несколькими кластерами.
• Резервное копирование и восстановление: Это основная панель управления, которая предоставляет общий обзор всего кластера, таких как обнаруженные пространства имен, приложения, список планов резервного копирования, цели, хуки, политики и т. д.

Мониторинг: Здесь есть два варианта – Мониторинг TrilioVault и Мониторинг Velero, если у пользователя настроен Velero на их кластере OVH.

Аварийное восстановление: Позволяет управлять и выполнять операции по аварийному восстановлению.

Аварийное восстановление: Позволяет управлять и выполнять операции по аварийному восстановлению.

Вы также можете увидеть ранее созданную цель S3, перейдя в Резервное копирование и восстановление -> Цели -> <Пространство_имен> из выпадающего списка вверху.

Далее вы можете просматривать цель и перечислять доступные резервные копии, нажав на кнопку Действия справа, а затем выбрав опцию Запустить браузер из всплывающего меню. Для работы этой функции цель должна иметь флаг enableBrowsing, установленный в true.

Для получения дополнительной информации и доступных функций ознакомьтесь с официальной документацией Пользовательский интерфейс веб-консоли управления TVK.

Затем вы узнаете, как выполнять операции по резервному копированию и восстановлению для конкретных случаев использования.

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

apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
metadata:
  name: ambassador-helm-release-backup-plan
  namespace: ambassador
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupPlanComponents:
    helmReleases:
      - ambassador

На этом этапе вы узнаете, как создать одноразовую резервную копию для всего пространства имен (ambassador в данном случае) из вашего кластера DOKS и затем восстановить ее, убедившись, что все ресурсы воссозданы. TVK имеет функцию, позволяющую выполнять резервное копирование на более высоком уровне, чем пространства имен.

• Создание резервной копии релиза Helm Ambassador
• Для выполнения резервного копирования для отдельного приложения на уровне пространства имен (или релиза Helm) требуется BackupPlan, за которым следует Backup CRD. BackupPlan – это определение ‘что’, ‘где’, ‘куда’ и ‘как’ процесса резервного копирования, но само по себе не выполняет фактическое резервное копирование. CRD Backup отвечает за запуск фактического процесса резервного копирования в соответствии с характеристиками BackupPlan.
• В этой конфигурации,

A typical Backup CRD looks like below:

apiVersion: triliovault.trilio.io/v1
kind: Backup
metadata:
  name: ambassador-helm-release-full-backup
  namespace: ambassador
spec:
  type: Full
  backupPlan:
    name: ambassador-helm-release-backup-plan
    namespace: ambassador

spec.backupConfig.target.name: Сообщает TVK, какое имя цели использовать для сохранения резервных копий.

• spec.backupConfig.target.namespace: Сообщает TVK, в каком пространстве имен была создана цель.
• spec.backupComponents: Определяет список ресурсов для резервного копирования.

В этой конфигурации,

spec.type: Указывает тип резервного копирования.

spec.backupPlan: Указывает BackupPlan, который должен использовать это резервное копирование.

cd Kubernetes-Starter-Kit-Developers

Шаги для запуска единоразового резервного копирования Helm-релиза Ambassador:

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

Сначала убедитесь, что Ambassador Edge Stack развернут в вашем кластере, следуя инструкциям из учебника Ambassador Ingress.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

Затем перейдите в каталог, куда был клонирован репозиторий Starter Kit на вашем локальном компьютере:

kubectl get backupplan ambassador-helm-release-backup-plan -n ambassador

Затем откройте и проверьте файлы манифестов Ambassador BackupPlan и Backup, предоставленные в репозитории Starter Kit, с помощью редактора по вашему выбору (желательно с поддержкой YAML-линтера).

NAME                                  TARGET             ...   STATUS
ambassador-helm-release-backup-plan   trilio-s3-target   ...   Available

Наконец, создайте ресурсы BackupPlan и Backup с помощью kubectl.

kubectl get backup ambassador-helm-release-full-backup -n ambassador

Теперь проверьте статус BackupPlan (нацелившись на Helm-релиз ambassador) с помощью kubectl:

NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS       ...
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          InProgress   ...

Вывод будет похож на следующий. Обратите внимание на значение столбца STATUS, которое должно быть установлено на Available.

Затем проверьте статус объекта Backup с помощью kubectl:
NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS      ...   PERCENTAGE
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          Available   ...   100

Вывод будет похож на следующий. Обратите внимание на значение столбца STATUS, которое должно быть установлено на InProgress, а также на значение BACKUP TYPE, установленное на Full.

s3cmd ls s3://trilio-starter-kit --recursive

После того как все компоненты релиза посла Helm загрузятся в целевую точку S3, вы должны получить следующие результаты:

2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04          311  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04          302  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04          305  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04          330  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...

kubectl get pods -n ambassador | grep metamover

ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx   1/1     Running   0          4m32s

kubectl logs pod/ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx -n ambassador -f

...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...

Вывод будет похож на следующий:

Теперь получите данные журналов:

Вывод будет похож на следующий.

helm delete ambassador -n ambassador

Наконец, вы можете проверить, что резервная копия также доступна в веб-консоли, перейдя в Управление ресурсами -> Посол -> Планы резервного копирования. Обратите внимание, что он находится в состоянии Available и что релиз посла Helm был резервирован в подвижке Детали компонента.

kubectl get all -n ambassador

Удаление релиза посла и ресурсов посла Helm

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Теперь продолжайте и имитируйте катастрофу путем намеренного удаления релиза Helm ambassador:

Если восстанавливаете то же самое пространство имен, убедитесь, что исходные компоненты приложения были удалены. Особенно PVC приложения удален.

apiVersion: triliovault.trilio.io/v1
kind: Restore
metadata:
  name: ambassador-helm-release-restore
  namespace: ambassador
spec:
  source:
    type: Backup
    backup:
      name: ambassador-helm-release-full-backup
      namespace: ambassador
  skipIfAlreadyExists: true

Если восстановление происходит в другой кластер (сценарий миграции), убедитесь, что TrilioVault для Kubernetes также работает в удаленном пространстве имен/кластере. Для восстановления в новый кластер (где CR резервного копирования не существует), source.type должен быть установлен в location. Пожалуйста, обратитесь к разделу Определение ресурсов настраиваемого восстановления, чтобы посмотреть пример восстановления по местоположению.

• При удалении пространства имен ambassador также будет удален ресурс балансировщика нагрузки, связанный с сервисом ambassador. Поэтому при восстановлении сервиса ambassador балансировщик нагрузки будет воссоздан DigitalOcean. Проблема заключается в том, что вы получите НОВЫЙ IP адрес для вашего балансировщика нагрузки, поэтому вам нужно будет настроить A записи, чтобы направить трафик на ваши домены, размещенные на кластере.
• Для восстановления конкретной резервной копии необходимо создать CRD Restore. Типичный CRD для восстановления выглядит следующим образом:
• В этой конфигурации,

spec.source.type: Указывает тип резервной копии для восстановления.

spec.source.backup: Содержит ссылку на объект резервной копии, из которого нужно восстанавливаться.

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

spec.skipIfAlreadyExists: Указывает, следует ли пропустить восстановление ресурса, если он уже существует в восстановленном пространстве имен.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

Восстановление позволяет восстановить последнее успешное резервное копирование для приложения. Оно используется для восстановления одного пространства имен или Helm-релиза, защищенного резервным копированием CRD. Резервное копирование CRD идентифицируется по имени ambassador-helm-release-full-backup.

kubectl get restore ambassador-helm-release-restore -n ambassador

Сначала просмотрите пример CRD восстановления из репозитория Starter Kit Git:

NAME                              STATUS      DATA SIZE   START TIME             END TIME               PERCENTAGE COMPLETED   DURATION
ambassador-helm-release-restore   Completed   0           2021-11-25T15:06:52Z   2021-11-25T15:07:35Z   100                    43.524191306s

Затем создайте ресурс восстановления с помощью kubectl:

Наконец, просмотрите статус объекта восстановления:

Вывод будет похож на следующий. Обратите внимание на столбец STATUS, установленный в Completed, а также на PERCENTAGE COMPLETED, установленный в 100.

kubectl get all -n ambassador

Если вывод выглядит так, то процесс восстановления релиза Helm ambassador завершен успешно.

NAME                                    READY   STATUS    RESTARTS   AGE
pod/ambassador-5bdc64f9f6-42wzr         1/1     Running   0          9m58s
pod/ambassador-5bdc64f9f6-nrkzd         1/1     Running   0          9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv    1/1     Running   0          9m58s
pod/ambassador-redis-64b7c668b9-69drs   1/1     Running   0          9m58s

NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
service/ambassador         LoadBalancer   10.245.173.90    157.245.23.93   80:30304/TCP,443:30577/TCP   9m59s
service/ambassador-admin   ClusterIP      10.245.217.211   <none>          8877/TCP,8005/TCP            9m59s
service/ambassador-redis   ClusterIP      10.245.77.142    <none>          6379/TCP                     9m59s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ambassador         2/2     2            2           9m59s
deployment.apps/ambassador-agent   1/1     1            1           9m59s
deployment.apps/ambassador-redis   1/1     1            1           9m59s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/ambassador-5bdc64f9f6         2         2         2       9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8    1         1         1       9m59s
replicaset.apps/ambassador-redis-64b7c668b9   1         1         1       9m59s

Проверка целостности приложений после восстановления

kubectl get hosts -n ambassador

Проверьте, что все ресурсы пространства имен ambassador на месте и работают:

NAME         HOSTNAME                   STATE   PHASE COMPLETED   PHASE PENDING   AGE
echo-host    echo.starter-kit.online    Ready                                     11m
quote-host   quote.starter-kit.online   Ready                                     11m

Вывод будет похож на:

kubectl get mappings -n ambassador

Получите хосты ambassador:

NAME                          SOURCE HOST                SOURCE PREFIX                               DEST SERVICE     STATE   REASON
ambassador-devportal                                     /documentation/                             127.0.0.1:8500
ambassador-devportal-api                                 /openapi/                                   127.0.0.1:8500
ambassador-devportal-assets                              /documentation/(assets|styles)/(.*)(.css)   127.0.0.1:8500
ambassador-devportal-demo                                /docs/                                      127.0.0.1:8500
echo-backend                  echo.starter-kit.online    /echo/                                      echo.backend
quote-backend                 quote.starter-kit.online   /quote/                                     quote.backend

Вывод будет похож на следующий. Столбец STATE должен быть Ready, а столбец HOSTNAME должен указывать на полностью определенное имя хоста.

Получите сопоставления ambassador:

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Выходные данные выглядят примерно так. Обратите внимание на echo-backend, который сопоставлен с хостом echo.starter-kit.online и префиксом источника /echo/, то же самое для quote-backend.

Теперь вам необходимо обновить записи DNS A, потому что ресурс балансировщика нагрузки DigitalOcean был воссоздан, и ему был назначен новый внешний IP-адрес.

Наконец, проверьте, отвечают ли бэкэнд-приложения на HTTP-запросы. Пожалуйста, обратитесь к Создание бэкэнд-сервисов Ambassador Edge Stack относительно используемых в учебнике Starter Kit бэкэнд-приложений.

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

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

A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: starter-kit-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupComponents:
    - namespace: ambassador
    - namespace: backend
    - namespace: monitoring

На этом шаге вы симулируете сценарий восстановления после катастрофы. Весь кластер DOKS будет удален, а затем важные приложения восстановлены из предыдущей резервной копии.

Создание резервной копии кластера DOKS

cd Kubernetes-Starter-Kit-Developers

Основная идея здесь заключается в выполнении резервного копирования кластера DOKS путем включения всех важных пространств имен, которые содержат ваши основные приложения и конфигурации.

code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

Обратите внимание, что пространства имен, связанные с кластером DOKS, такие как kube-system, не включены в список. Обычно они не требуются, если только нет особых случаев, когда требуется сохранить некоторые настройки на этом уровне.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

Сначала измените каталог, в котором был клонирован репозиторий Starter Kit на вашем локальном компьютере:

kubectl get clusterbackupplan starter-kit-cluster-backup-plan -n tvk

Затем откройте и проверьте файлы манифестов ClusterBackupPlan и ClusterBackup, предоставленные в репозитории Starter Kit, с использованием редактора по вашему выбору (желательно с поддержкой проверки YAML).

NAME                              TARGET             ...   STATUS
starter-kit-cluster-backup-plan   trilio-s3-target   ...   Available

Наконец, создайте ресурсы ClusterBackupPlan и ClusterBackup с помощью kubectl:

kubectl get clusterbackup starter-kit-cluster-backup -n tvk

Теперь проверьте статус ClusterBackupPlan с помощью kubectl:

NAME                        BACKUPPLAN                        BACKUP TYPE   STATUS      ...   PERCENTAGE COMPLETE
starter-kit-cluster-backup  starter-kit-cluster-backup-plan   Full          Available   ...   100

Вывод будет похож на следующий. Обратите внимание на значение столбца STATUS, которое должно быть установлено в Available.

Вывод будет похож на следующий. Обратите внимание на значение столбца STATUS, которое должно быть установлено в Available, а также на значение PERCENTAGE COMPLETE, установленное на 100.

Если вывод выглядит как выше, то все ваши важные пространства имен приложений были успешно скопированы.

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

Вы также можете открыть главную панель инструментов веб-консоли и проверить резервную копию мультипространства имен (обратите внимание, как все важные пространства имен, которые были сохранены, выделены зеленым цветом, в структуре сота):

doctl kubernetes cluster delete <DOKS_CLUSTER_NAME>

Повторное создание кластера DOKS и восстановление приложений

Важным аспектом, который следует иметь в виду, является то, что каждый раз, когда вы уничтожаете кластер DOKS, а затем восстанавливаете его, создается новый балансировщик нагрузки с новым внешним IP-адресом, когда TVK восстанавливает ваш контроллер входа. Поэтому, пожалуйста, убедитесь в обновлении ваших записей DNS DigitalOcean A соответственно.

Теперь удалите весь кластер DOKS (убедитесь в замене заполнителей <> соответствующим образом):

Затем повторно создайте кластер, как описано в Настройка Kubernetes DigitalOcean.

Чтобы выполнить операцию восстановления, вам необходимо установить приложение TVK, как описано в Шаг 1 – Установка TrilioVault для Kubernetes. Важно использовать тот же номер версии Helm Chart.

После успешного завершения установки настройте целевую ТВК, как описано в Шаг 2 – Создание целевого объекта TrilioVault для хранения резервных копий и укажите тот же ведро S3, где находятся ваши резервные данные. Также убедитесь, что просмотр целей включен.

Затем проверьте и активируйте новую лицензию, как описано в разделе Лицензирование приложения TrilioVault.

Для доступа к веб-интерфейсу консоли пользователя обратитесь к разделу Получение доступа к веб-консоли управления TVK.

Затем перейдите в Управление ресурсами -> Пространство имен TVK -> Цели (в случае Starter Kit пространство имен TVK – tvk):

Далее просмотрите цель и перечислите доступные резервные копии, нажав на кнопку Действия. Затем выберите опцию Запуск браузера из всплывающего меню. Для этого работы цель должна иметь флаг enableBrowsing, установленный в true.

Теперь щелкните по элементу starter-kit-cluster-backup-plan в списке, а затем щелкните и разверните элемент starter-kit-cluster-backup из правого подоконника:

kubectl get all --all-namespaces

Для запуска процесса восстановления нажмите кнопку Восстановление.

Проверка состояния приложений кластера DOKS

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

Сначала убедитесь, что все ресурсы кластера Kubernetes проверены.

Затем убедитесь, что ваши записи DNS A обновлены, чтобы указывать на внешний IP-адрес вашего нового балансировщика нагрузки.

Наконец, бэкенд-приложения должны также реагировать на HTTP-запросы. Обратитесь к Создание бэкенд-сервисов Ambassador Edge Stack относительно используемых в учебнике Starter Kit бэкенд-приложений.

На следующем этапе вы узнаете, как выполнять запланированные (или автоматические) резервные копии для приложений вашего кластера DOKS.

kind: Policy
apiVersion: triliovault.trilio.io/v1
metadata:
  name: scheduled-backup-every-5min
  namespace: tvk
spec:
  type: Schedule
  scheduleConfig:
    schedule:
      - "*/5 * * * *" Шаг 6 - Запланированные резервные копии

Автоматическое создание резервных копий в соответствии с расписанием – это действительно полезная функция. Она позволяет перемотать время и восстановить систему к предыдущему рабочему состоянию, если что-то пойдет не так. В этом разделе представлен пример автоматического резервного копирования по расписанию каждые 5 минут (выбрано пространство имен kube-system).

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    schedulePolicy:
      fullBackupPolicy:
        name: scheduled-backup-every-5min
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

Сначала вам нужно создать CRD Policy типа Schedule, который определяет расписание резервного копирования в формате cron (таком же, как Linux cron). Политики расписания могут использоваться как для CRD BackupPlan, так и для CRD ClusterBackupPlan. Типичный CRD политики расписания выглядит следующим образом (определяет расписание каждые 5 минут):

# запуск каждые 5 минут

Затем вы можете применить политику расписания к CRD ClusterBackupPlan, например, как показано ниже:

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/scheduled-backup-every-5min.yaml

Вы можете заметить, что это базовый CRD ClusterBackupPlan, ссылающийся на ранее определенный CRD Policy через поле spec.backupConfig.schedulePolicy. Вы можете создавать отдельные политики для полных или инкрементальных резервных копий, поэтому спецификация может содержать fullBackupPolicy или incrementalBackupPolicy.

kubectl get policies -n tvk

Теперь, пожалуйста, создайте расписание Policy, используя образец манифеста, предоставленный в руководстве по Starter Kit.

NAME                          POLICY     DEFAULT
scheduled-backup-every-5min   Schedule   false

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

Проверьте, был ли создан ресурс политики:
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-plan-scheduled.yaml

Вывод выглядит примерно следующим образом. Обратите внимание на тип POLICY, установленный в Schedule.
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-scheduled.yaml

Наконец, создайте ресурсы для запланированных резервных копий в пространстве имен kube-system:

kubectl get clusterbackupplan kube-system-ns-backup-plan-5min-schedule -n tvk

# Сначала создайте план резервного копирования для пространства имен kube-system

NAME                                       TARGET             ...   FULL BACKUP POLICY            STATUS
kube-system-ns-backup-plan-5min-schedule   trilio-s3-target   ...   scheduled-backup-every-5min   Available

# Создайте и запустите запланированную резервную копию для пространства имен kube-system

kubectl get clusterbackup kube-system-ns-full-backup-scheduled -n tvk

Проверьте состояние запланированного резервного копирования для kube-system:

NAME                                   BACKUPPLAN                                 BACKUP TYPE   STATUS      ...
kube-system-ns-full-backup-scheduled   kube-system-ns-backup-plan-5min-schedule   Full          Available   ...

Вывод выглядит аналогично следующему. Обратите внимание на значение FULL BACKUP POLICY, установленное на ресурс политики резервного копирования, созданный ранее, scheduled-backup-every-5min, а также на значение STATUS, которое должно быть Available.

Проверьте состояние запланированного резервного копирования для kube-system:

Вывод выглядит аналогично следующему. Обратите внимание на значение BACKUPPLAN, установленное на ресурс резервного плана, созданный ранее, а также на значение STATUS, которое должно быть Available.

Теперь вы можете убедиться, что резервные копии выполняются с регулярным интервалом (5 минут), запросив ресурс резервного копирования кластера и проверив столбец START TIME (kubectl get clusterbackup -n tvk). Он должен отражать 5-минутный интервал, как показано на картинке ниже:

На следующем этапе вы узнаете, как настроить политику удержания резервных копий.

Шаг 7 – Политика удержания резервных копий

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: sample-policy
spec:
  type: Retention
  retentionConfig:
    latest: 2
    weekly: 1
    dayOfWeek: Wednesday
    monthly: 1
    dateOfMonth: 15
    monthOfYear: March
    yearly: 1

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

• Использование политик хранения
• Политики хранения могут использоваться для CRD BackupPlan или ClusterBackupPlan. Типичный манифест Policy для типа Retention выглядит следующим образом:
• Вышеописанная политика хранения переводится как:
• Каждую неделю сохранять одну резервную копию в среду.

Каждый месяц сохранять одну резервную копию 15-го числа.

A typical ClusterBackupPlan example configuration that has a retention set looks like:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    retentionPolicy:
      fullBackupPolicy:
        name: ambassador-backups-retention-policy
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

Каждый год сохранять одну резервную копию в марте.

В общем, должно быть 2 самые последние доступные резервные копии.

Базовый процесс создания ресурса политики хранения проходит таким же образом, как и для запланированных резервных копий. Вам нужно определить CRD BackupPlan или ClusterBackupPlan, чтобы ссылаться на политику хранения, а затем иметь объект Backup или ClusterBackup, чтобы запустить процесс.

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: garbage-collect-policy
spec:
  type: Cleanup
  cleanupConfig:
    backupDays: 5

Обратите внимание, что для ссылки на соответствующую политику используется поле retentionPolicy. Конечно, вы можете иметь план резервного копирования, в котором установлены оба типа политик, чтобы выполнять запланированные резервные копии, а также управлять стратегиями хранения.

Использование политик очистки

Вам нужен способ утилизации всех тех объектов, которые больше не используются. Для этого вам необходимо ввести CRD Cleanup Policy:

Вышеуказанная политика очистки должна быть определена в пространстве имен установки TVK. Затем для вас автоматически создается крон-задание, которое запускается каждые 30 минут и удаляет неудачные резервные копии на основе значения, указанного для backupdays в поле spec.

Вывод

• В этом руководстве вы узнали, как выполнять резервное копирование как единовременно, так и по расписанию, а также восстанавливать все.
• Все основные задачи и операции, объясненные в этом руководстве, призваны дать вам базовое представление и понимание того, что способен делать TrilioVault для Kubernetes.
• Узнать больше

Резервное копирование и восстановление данных DOKS с использованием Velero