Налаштування бекапу Kubernetes через Velero: досвід та терміни
Втрата даних у StatefulSet після невдалого деплою — стандартна ситуація в бойових кластерах. Без бекапу на рівні namespace відновлення займає години: перестворювати StatefulSet, шукати останній снапшот etcd, піднімати PV вручну. Ми стикалися з цим десятки разів і знаємо, як уникнути таких сценаріїв. Velero закриває цей gap: namespace-level та resource-level backup з підтримкою PV через CSI snapshot або Kopia (колишній Restic). При тестовому restore в ізольованому namespace дані відновлюються за 5–15 хвилин — це в 10 разів швидше ручного підняття, яке займає 2–3 години.
Чому Velero краще ніж etcd-снапшоти?
etcd зберігає стан кластера, але відновлення з нього — це повернення всього кластера цілком. Якщо потрібно відкотити один namespace або один PersistentVolume після помилкового деплою — etcd не підійде. Velero дає гранулярність на рівні ресурсів і підтримує гнучкі політики зберігання.
Крім того, Velero інтегрується з хмарними об'єктними сховищами (S3, GCS, Azure Blob), що дозволяє зберігати бекапи в іншому регіоні або акаунті — ключовий елемент disaster recovery. За нашими вимірами, час відновлення окремого застосунку знижується в 10 разів порівняно з ручним процесом. При типовому кластері з 100 PVC та 50 workloads повний бекап займає близько 20 хвилин.
Як уникнути типових помилок при налаштуванні Velero?
Перша проблема: CSI-драйвер без підтримки VolumeSnapshot API. Якщо такий драйвер не зареєстрував VolumeSnapshotClass, Velero мовчки пропустить дані томів. У логах — Included Volumes: 0. Рішення: увімкніть Node Agent (Kopia) для файлового бекапу або додайте анотацію velero.io/csi-volumesnapshot-class до PVC.
Друга помилка — IAM-політика для object storage без прав на запис об'єктів. На AWS типово: у service account є доступ до bucket, але не до шляху /*. Бекап метаданих проходить, а дані — ні. Помилка в логах: AccessDenied на s3:PutObject для backups/*. Виправляється додаванням окремого statement на arn:aws:s3:::velero-bucket/*.
Третя — restore у кластер з іншим StorageClass. Velero не перейменує StorageClass автоматично. Потрібен --namespace-mappings або ConfigMap з resource modifier для маппінгу імен. Без цього PVC зависнуть у Pending.
Правильна архітектура бекапу
Для production-кластера схема виглядає так: Object storage: окремий S3-bucket (або GCS/Azure Blob) в іншому регіоні або акаунті. Політика бекапів: два розклади через Schedule CR:
- Щоденний повний бекап всього кластера з TTL 30 днів
- Погодинний бекап критичних namespace'ів (бази даних, stateful workloads) з TTL 7 днів
Приклад Schedule для погодинних бекапів
---
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: hourly-databases
namespace: velero
spec:
schedule: "0 * * * *"
template:
includedNamespaces:
- postgres
- redis
storageLocation: default
volumeSnapshotLocations:
- default
ttl: 168h0m0s
---Node Agent (Kopia) обов'язково включати, якщо хоча б частина PV використовує hostPath або NFS — там CSI snapshot недоступний.
Тестування restore — обов'язкова частина налаштування. Запускаємо restore в окремий namespace з суфіксом -restore-test кожні два тижні. Автоматично перевіряємо, що застосунок піднявся і дані цілі.
Порівняння підходів: Velero vs etcd-снапшоти
| Критерій | Velero | etcd-снапшот |
|---|---|---|
| Гранулярність | namespace, resource | весь кластер |
| Відновлення PV | CSI/Kopia | вручну + ручне підняття PV |
| Зберігання | object storage (S3/GCS) | локальний файл |
| Час відновлення одного застосунку | 5–15 хвилин | 1–2 години |
| Підтримка крос-регіону | вбудована | ні |
Моніторинг бекапів
Velero експортує метрики Prometheus на порту 8085. Ключові:
-
velero_backup_success_total -
velero_backup_failure_total -
velero_backup_duration_seconds -
velero_restore_success_total
Алерт на velero_backup_failure_total > 0 за 2 години — must-have. У Grafana є готовий дашборд (ID 11055) з візуалізацією статусів і тривалості. Наша послуга включає автоматизацію бекапів в рамках DevOps практик.
Процес налаштування під ключ
- Інвентаризація — перевіряємо StorageClass, CSI-драйвер, наявність
VolumeSnapshotClass, список застосунків. - Вибір object storage та налаштування IAM/service account з мінімальними правами.
- Встановлення Velero через Helm-чарт (
vmware-tanzu/velero), налаштуванняBackupStorageLocationтаVolumeSnapshotLocation. - Створення розкладів — для всього кластера та для критичних namespace.
- Налаштування моніторингу — метрики, алерти, дашборд.
- Пробний restore — в окремий namespace з перевіркою цілісності даних.
- Документація — опис усіх Schedule CR, процедура повного та часткового відновлення.
Що входить в роботу
- Аудит поточної інфраструктури
- Встановлення та конфігурація Velero під ваше хмару
- Налаштування файлового бекапу через Kopia при необхідності
- Інтеграція з Prometheus та Grafana (3 алерти)
- Проведення тестового restore
- Документація та інструкція для команди
- 2 тижні супроводу після запуску
Орієнтовні терміни
| Сценарій | Терміни |
|---|---|
| Один кластер, CSI snapshot, S3 | від 1 дня |
| Декілька кластерів, крос-регіон restore | 2–3 дні |
| + Налаштування моніторингу та алертів | +0.5 дня |
| + Тестування disaster recovery | +1 день |
Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами для оцінки вашої інфраструктури. DevOps-інженери нашої компанії мають десятирічний досвід в області резервного копіювання Kubernetes, виконано більше 200 проектів з міграції та резервного копіювання K8s. Гарантуємо працездатність налаштувань і готові навчити вашу команду. Замовте налаштування Velero для вашого кластера вже сьогодні.
Документація Velero на GitHub
