Что резервировать — базовые слои

Etcd (state of cluster) — единственный источник истины для Kubernetes-ресурсов (Pod, Deployments, Services, RBAC и т.д.).
Манифесты/CR — YAML/Helm-чарты/CRD, которые описывают ресурсы; полезно иметь лог в Git.
Persistent Volumes (данные приложений) — диски/бэкенды, где хранятся базы, файлы, логи.
Секреты и ключи — шифровать при хранении бэкапов.
Внешние артефакты — docker registry, внешние сервисы, конфигурации облака.

Подходы к бэкапу и восстановлению (две основные стратегии)

Снимок etcd (full cluster restore) — быстрый способ вернуть весь API-server state в том виде, в котором был на момент снимка; удобен при катастрофе кластера.
Rebuild cluster + восстановление ресурсов и PV — создать новый контроль-плейн/кластер и применить сохранённые манифесты/Helm + восстановить PV из снимков; более гибкий и чаще применим в облачных/managed окружениях.

Снимок: etcdctl snapshot save /backup/etcd-snap.db (используйте правильные --endpoints, --cacert/--cert/--key если TLS).
Храните снимки в надёжном хранилище (S3/GCS/репликация). Держите ротацию и retention.
Восстановление (общая схема): остановить kube-apiserver/etcd service на мастере, выполнить etcdctl snapshot restore /backup/etcd-snap.db --data-dir /var/lib/etcd-from-backup, поправить конфигурацию и запустить etcd с восстановленной директорией, затем стартовать kube-apiserver. Точные шаги зависят от вашей установки (kubeadm, managed cloud и т.д.).
Тестируйте restore на стенде; проверяйте версии etcd и совместимость.

CSI VolumeSnapshots — стандартизованный CRD: создать VolumeSnapshot (который использует CSI driver) и сохранять снимки в бекенде (облако/цифровое хранилище). Для восстановления создать PVC из VolumeSnapshot.
Cloud provider snapshots — EBS/Azure Disk/GCE snapshots через облачный API; часто интегрируются с CSI.
File-level / application-level backup — для баз данных рекомендуются логические дампы (pg_dump, mysqldump) или репликация/WAL shipping для PITR; файловые системы — rsync/backup agents.
Учитывайте reclaimPolicy, StorageClass и возможность маппинга имен/кластеров при restore.

Храните манифесты в Git (GitOps) — helm charts / kustomize / raw YAML.
Экспорт ресурсов для бэкапа: kubectl get <kind> -n <ns> <name> -o yaml > backup.yaml или собрать набор ресурсов (deployments, services, configmaps, secrets, pv,pvc,sc,crd,roles,rolebindings,clusterroles,clusterrolebindings) и сохранять. Учтите: kubectl get all не включает CRD и некоторые ресурсы, поэтому выбирайте список целенаправленно.
Секреты экспортировать осторожно; хранить зашифрованными (SOPS/SealedSecrets).

Velero — инструмент для бэкапа ресурсов кластера и PVC (через snapshot или копирование данных), умеет сохранять в S3-подобные хранилища и восстанавливать namespace/ресурсы.
CSI snapshots + cron jobs / automation для регулярных snapshot’ов PV.
Operators/backup products (Restic-based, Kasten, Stash) — предлагают application-aware backup, шифрование, управление retention, GUI.
GitOps (ArgoCD/Flux) как часть стратегии: хранить manifests/helm в git, чтобы восстановление конфигурации было одним git apply/sync.

План восстановления (runbook): документ с шагами для разных сценариев (частичный restore namespace, полный cluster restore).
При полном крахе: либо restore etcd snapshot (восстановит все ресурсы), либо создать новый control plane и восстановить из манифестов + PV-снимков.
При частичном сбое (например, потеря namespace): восстановить PV (snapshot → PVC), затем применить манифесты (ConfigMap/Secrets/Deployments) и дождаться Ready.
Порядок восстановления: сначала StorageClasses/CRDs/namespace → затем PV/PVC (или snapshots) → затем приложения (Deployments/StatefulSets) → затем проверить данные/логи.
Тестирование: регулярные rehearsal restores в staging; автоматические smoke-тесты проверяют целостность.

Шифруйте бэкапы и ограничьте доступ (IAM, RBAC).
Сегрегируйте хранилище бэкапов от кластера (удалённый S3/GCS/backup site).
Автоматизируйте ротацию, retention и мониторьте успешность бэкапов, оповещения о провалах.
Документируйте RTO/RPO для приложений; от этого зависят частота снимков и способ (логический vs. снепшот).

Secrets: хранить зашифрованными (SOPS/SealedSecrets); при восстановлении учитывать KMS/ключи.
Версии API/CRD: убедитесь, что целевой кластер поддерживает нужные версии CRD перед применением старых манифестов.
Consistency: для stateful приложений снимки нужно делать согласованно (stop/flush, fsfreeze, или использовать application-consistent snapshot механизмы).

14-08-2025

Medium 4 просмотров