Какие инструменты и стратегии вы используете для резервного копирования кластера Kubernetes?

Для надёжного бэкапа production-кластера Kubernetes я использую многоуровневую стратегию, разделяя резервное копирование ресурсов Kubernetes (декларативное состояние) и данных приложений (состояние в Persistent Volumes).

Основной инструмент: Velero. Я выбрал Velero, потому что он является стандартом де-факто в сообществе, поддерживается VMware, и умеет делать и то, и другое.

1. Бэкап ресурсов Kubernetes (YAML-манифесты, конфиги): Velero создаёт снимок всех или выбранных ресурсов (Pods, Deployments, Services, ConfigMaps, Secrets и т.д.) и сохраняет их как архив в объектном хранилище (например, AWS S3, MinIO).

2. Бэкап данных приложений (Persistent Volumes): Здесь есть два основных подхода, которые я применяю в зависимости от инфраструктуры:

• Snapshot API облачного провайдера: Если кластер развёрнут в облаке (AWS EBS, GCP PD, Azure Disk), Velero может через плагин инициировать создание снапшота диска. Это быстро и согласованно на уровне блока.

  velero backup create app-backup --include-namespaces production --snapshot-volumes

• Restic/File-system backup: Для он-премис решений или когда снапшоты дисков недоступны, я настраиваю Velero с интеграцией Restic. Он делает бэкап на уровне файлов внутри PV.

  velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.5.0 
    --bucket my-velero-backups --secret-file ./cloud-credentials 
    --use-restic --backup-location-config region=us-east-1

Типичный пайплайн восстановления при аварии:

1. Развернуть чистый кластер Kubernetes.
2. Установить Velero, указав на тот же bucket с бэкапами.
3. Восстановить ресурсы и данные одной командой:

   velero restore create --from-backup app-backup-20231001

Другие инструменты в стеке:

• Для баз данных: Я никогда не полагаюсь только на снапшоты PV. Для stateful-приложений (PostgreSQL, Redis) я настраиваю нативные механизмы бэкапа (pg_dump, redis RDB) внутри контейнера и выгружаю дампы в S3 с помощью cronJobs или операторов (например, K8up).
• GitOps как бэкап конфигурации: Весь декларативный манифест кластера (Helm charts, Kustomize) хранится в Git. Это даёт «бэкап желаемого состояния» и позволяет воссоздать инфраструктуру с нуля с помощью ArgoCD или Flux.
• Для etcd: В self-hosted кластерах критически важно иметь отдельный бэкап etcd (через etcdctl snapshot save), так как в нём хранится всё состояние API Kubernetes. Velero этого не делает.