Зауважимо: коли production-кластер падає через помилку оператора або збій в інфраструктурі, кожна година простою обертається збитками. Без резервної копії відновлення може зайняти дні. Disaster Recovery для Kubernetes — це не просто бекапи, а повноцінна стратегія відновлення. Velero (раніше Heptio Ark) — open-source інструмент, що став стандартом для backup та restore в Kubernetes. Він підтримує всі популярні хмарні сховища та дозволяє гнучко налаштовувати політики резервування. Наші інженери з 10+ річним досвідом в Kubernetes реалізували понад 50 успішних проектів з резервного копіювання. Нижче — практичне керівництво з налаштування Velero з урахуванням реальних кейсів.
Чому Velero краще вбудованих снапшотів хмари?
Вбудовані снапшоти хмари (EBS Snapshots, GCP Snapshots) прив'язані до конкретного провайдера і не переносимі. Velero зберігає дані в portable object storage — ви можете відновити кластер в іншій хмарі або on-prem. Більше того, Velero бекапить не лише PV, а й всі об'єкти Kubernetes: ConfigMaps, Secrets, RBAC, CRDs. На практиці це прискорює відновлення в 3-4 рази порівняно з ручним відтворенням. Згідно з офіційною документацією Velero, використання CSI VolumeSnapshots підвищує надійність на 40%, а вартість зберігання в S3 виявляється в 2 рази нижчою за локальні снапшоти. Так ви отримуєте Disaster Recovery з RTO до 30 хвилин та суттєву економію.
Встановлення та попередні вимоги
Velero потребує доступу до object storage і, для бекапу PersistentVolume, до snapshots або файлової системи через Node Agent (Kopia). Базова інсталяція для AWS S3 включає послідовність кроків:
- Створіть IAM роль з мінімальними правами: доступ до EC2 для снапшотів та S3 для зберігання бекапів.
- Встановіть Velero CLI.
- Виконайте команду встановлення:
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.9.0 \
--bucket velero-backups-prod \
--backup-location-config region=us-east-1 \
--snapshot-location-config region=us-east-1 \
--secret-file ./credentials-velero \
--use-node-agent \
--features=EnableCSI--features=EnableCSI активує підтримку CSI VolumeSnapshots — найкращий метод для снапшотів PV у сучасних кластерах. Важно налаштувати IAM роль з мінімальними правами, що включають доступ до EC2 для створення снапшотів та S3 для зберігання бекапів.
Детальніше про права доступу
Для AWS: політика повинна включати дії ec2:CreateSnapshot, ec2:DescribeSnapshots, ec2:DeleteSnapshot, s3:PutObject, s3:GetObject, s3:ListBucket. Приклад arn: arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy.
Стратегія бекапів: що та як часто
Не бекапимо все підряд. Визначаємо критичні namespace та ресурси. Типовий підхід:
| Рівень | Об'єкти | Розклад | Retention |
|---|---|---|---|
| Production | Бізнес-namespace (production, databases) | Щоденно о 01:00 | 14 днів |
| Системні | ClusterRoles, StorageClasses, CRDs | Щоденно о 02:00 | 30 днів |
| Експериментальні | Pre-prod, dev | Щотижня | 7 днів |
Приклад розкладу для production:
---
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: production-full
namespace: velero
spec:
schedule: "0 1 * * *"
template:
includedNamespaces:
- production
- databases
- monitoring
excludedResources:
- events
- endpointslices
labelSelector:
matchLabels:
backup: "true"
storageLocation: aws-s3
volumeSnapshotLocations:
- aws-snapshots
ttl: 336h
snapshotMoveData: true
snapshotMoveData: true переносить дані снапшота в object storage через Kopia. Це критично для міграції між хмарами. Порівняння підходів до зберігання бекапів:
| Критерій | Object storage (S3) | Snapshot локальний |
|---|---|---|
| Переносимість між хмарами | Так | Ні |
| Вартість зберігання | ~$0.023/ГБ/міс | ~$0.05/ГБ/міс |
| Час відновлення | 5-10 хв | 2-5 хв |
| Надійність | 99.999999999% | 99.99% |
Як організувати бекапи StatefulSet з базами даних?
Для stateful-навантажень (PostgreSQL, MySQL, Elasticsearch) простого снапшота PV недостатньо — потрібна консистентність на рівні БД. Використовуємо pre- та post-hooks Velero:
---
spec:
hooks:
pre:
- exec:
container: db
command:
- /bin/sh
- -c
- "pg_dumpall > /tmp/backup.sql"
post:
- exec:
container: db
command:
- /bin/sh
- -c
- "rm /tmp/backup.sql"
Це гарантує, що під час бекапу дані консистентні. Нещодавно зіткнулися з задачею: клієнт втратив кластер через помилку оператора. Завдяки Velero з pre-hook дампом бази відновили PostgreSQL за 15 хвилин. Без хуків дані були б неконсистентні та відновлення зайняло б години. Хуки дозволяють підключати будь-які скрипти: від дампів до очищення тимчасових файлів.
Як відновити кластер з бекапу?
Повне відновлення namespace або часткове — за ресурсами та мітками. Для тестування бекапів відновлюємо в ізольований namespace з маппінгом імен. Приклади команд:
# Повне відновлення namespace
velero restore create --from-backup production-backup-latest --include-namespaces production --wait
# Часткове відновлення за мітками
velero restore create --from-backup production-backup-latest --include-resources deployments,services --selector app=orders-service
# В ізольований namespace для тесту
velero restore create --from-backup production-backup-latest --namespace-mappings production:production-testТак ви перевіряєте цілісність без ризику для живого кластера. Замовник може виконати тестове відновлення самостійно за нашим runbook. Velero підтримує міграцію між кластерами: створіть бекап у старому кластері, розгорніть новий, відновіть бекап. На практиці мігрували production ELK-стек за 40 хвилин.
Моніторинг стану бекапів
Velero експортує метрики в Prometheus. Ключові алерти:
---
- alert: VeleroBackupFailed
expr: velero_backup_last_status{schedule!=""} == 1
for: 1m
labels:
severity: critical
annotations:
summary: "Бекап {{ $labels.schedule }} провалено"
---Ми налаштовуємо дашборди в Grafana з часом останнього успішного бекапу та обсягом даних. Це входить до стандартного пакету обстеження. Додатково додаємо алерт на "бекап старше N днів". Хочете побачити моніторинг бекапів в реальному часі? Зв'яжіться з нами — покажемо на діючому кластері.
Поширені помилки при налаштуванні Velero
Часто зустрічаються проблеми з правами доступу до object storage: забувають вказати коректний регіон або політики IAM. Друга за частотою — невірна конфігурація CSI-драйвера: якщо драйвер не підтримує VolumeSnapshots, Velero падає з помилкою. Вирішується встановленням CSI Driver та увімкненням --features=EnableCSI. Також варто перевіряти, що kubelet на нодах має доступ до файлової системи для Node Agent.
Обсяг робіт з налаштування Velero під ключ
- Аудит кластера: namespace, PVC, CSI-драйвери, RBAC
- Створення service account з мінімальними правами (IAM / cloud provider)
- Встановлення Velero з плагінами під ваше сховище (S3, GCS, Azure Blob)
- Налаштування розкладів бекапів та політик retention
- Пре- та пост-хуки для stateful-додатків
- Тестування відновлення в ізольованому середовищі
- Налаштування Prometheus-алертів (failed backup, too old backup)
- Документація та runbook
Термін: 2-4 дні. Вартість розраховується індивідуально. Гарантуємо коректне відновлення: якщо не вийде, доведемо безкоштовно. Замовте аудит вашого кластера прямо зараз. Отримайте консультацію з налаштування Velero — наші сертифіковані інженери готові допомогти.







