Полное аварийное восстановление кластера Kubernetes: пошаговое руководство от etcd до приложений

Потеря работоспособности кластера Kubernetes в продакшене - это не гипотетический риск, а неизбежный инцидент. Он случается из-за человеческой ошибки, отказа оборудования, программного сбоя или повреждения данных. Случайное удаление критического неймспейса, полный выход из строя мастер-ноды, потеря кворума в etcd - эти события парализуют работу приложений. Это руководство дает проверенный на практике алгоритм действий для полного восстановления, от состояния кластера в etcd до данных приложений в Persistent Volumes. Все команды и шаги проверены на версиях Kubernetes 1.28+ и актуальны на 2026 год.

Почему без стратегии восстановления ваш кластер Kubernetes - это риск

Сложность распределенной системы Kubernetes делает ее уязвимой к каскадным сбоям. Отказ одного ключевого компонента, такого как etcd, приводит к неработоспособности всей контрольной плоскости. Без проверенного плана аварийного восстановления (Disaster Recovery, DR) время простоя измеряется часами, а не минутами. Полное восстановление требует работы на двух уровнях: сначала восстанавливается состояние самого кластера (его объекты и конфигурация), затем - рабочие нагрузки и их данные. Эта инструкция закрывает оба сценария, предоставляя четкую последовательность команд, которую можно выполнить под давлением инцидента.

Архитектура восстановления: что восстанавливать в первую очередь

Процесс следует строгому порядку, основанному на архитектурных зависимостях. Сначала должна быть восстановлена контрольная плоскость кластера. Без нее невозможна работа kube-apiserver, а значит, и управление любыми ресурсами. Второй этап - восстановление пользовательских ресурсов (неймспейсов, развертываний, сервисов) и их данных. Нарушение этой последовательности приведет к ошибкам и усугубит ситуацию.

Ключевые компоненты: etcd, Velero и Persistent Volumes

Etcd - это распределенное key-value хранилище, в котором Kubernetes хранит все свои объекты: ноды, поды, конфигурации. Его состояние - это состояние кластера. Velero - это инструмент для резервного копирования и миграции ресурсов Kubernetes. Он умеет создавать бэкапы объектов (YAML-манифесты) и данных из Persistent Volumes, используя либо снапшоты облачных провайдеров, либо утилиту Restic. Persistent Volume (PV) и Persistent Volume Claim (PVC) - это механизм предоставления постоянного хранилища для stateful-приложений, таких как базы данных. Восстановление только приложений без их данных бессмысленно, поэтому работа с PV - обязательная часть процесса.

Подготовка к катастрофе: создание и проверка резервных копий

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

Создание и валидация снапшота etcd

Создайте снапшот состояния etcd, указав актуальные endpoints и сертификаты аутентификации. Команду необходимо выполнять на одной из мастер-нод или на хосте, имеющем доступ к etcd.

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /opt/etcd-backup/snapshot-$(date +%Y%m%d-%H%M).db

Сразу после создания проверьте валидность снапшота. Эта команда не восстанавливает данные, а только проверяет их.

ETCDCTL_API=3 etcdctl snapshot status /opt/etcd-backup/snapshot-20260505-1430.db

Сохраните конфигурационные файлы etcd и сертификаты вместе со снапшотом в безопасное, внешнее хранилище (например, S3-бакет).

Настройка Velero для регулярного бэкапа ресурсов и данных

Установите Velero в кластер, настроив его на использование вашего объектного хранилища. Пример для AWS S3 (для других провайдеров логика аналогична):

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket your-velero-backups \
  --secret-file ./credentials-velero \
  --use-volume-snapshots=true \
  --backup-location-config region=eu-central-1,s3ForcePathStyle="true",s3Url=https://s3.eu-central-1.amazonaws.com

Создайте расписание для автоматического ежедневного бэкапа всего кластера, исключая системные неймспейсы:

velero schedule create daily-full-backup \
  --schedule="@every 24h" \
  --include-namespaces="*" \
  --exclude-namespaces=kube-system,kube-public,kube-node-lease \
  --ttl 720h

Убедитесь, что бэкапы создаются успешно: velero backup get. Для защиты данных в Persistent Volumes на on-premise-инфраструктуре используйте интеграцию с Restic: velero install --use-restic. Подробнее о настройке рабочих нагрузок читайте в нашем полном руководстве по Kubernetes Deployment.

Сценарий 1: Восстановление после полной потери мастер-ноды или сбоя etcd

Этот сценарий предполагает, что контрольная плоскость уничтожена или etcd поврежден. Цель - развернуть новую мастер-ноду и восстановить на ней состояние кластера.

Шаг 1: Подготовка новой инфраструктуры и установка базовых компонентов

Подготовьте чистый сервер с той же версией ОС. Установите пакеты kubeadm, kubelet, kubectl и etcd, идентичные версиям из утраченного кластера. Например, для версии 1.28:

apt-get update && apt-get install -y kubeadm=1.28.5-00 kubelet=1.28.5-00 kubectl=1.28.5-00 etcd=3.5.9-00

Инициализируйте kubeadm без запуска контрольной плоскости, так как мы восстановим etcd вручную: kubeadm init --skip-phases=control-plane.

Шаг 2: Критическая операция - восстановление etcd из снапшота

Остановите службу etcd, если она была запущена: systemctl stop etcd. Восстановите данные из снапшота в новый data-dir, указав параметры для нового однонодового кластера.

ETCDCTL_API=3 etcdctl snapshot restore /opt/etcd-backup/snapshot-20260505-1430.db \
  --data-dir /var/lib/etcd-restored \
  --initial-cluster master-new=https://192.168.1.100:2380 \
  --initial-advertise-peer-urls https://192.168.1.100:2380 \
  --name master-new

Замените IP-адрес на актуальный для новой ноды. Обновите конфигурационный файл etcd (/etc/etcd/etcd.conf) так, чтобы он указывал на восстановленный --data-dir. Запустите etcd: systemctl start etcd и проверьте его здоровье: ETCDCTL_API=3 etcdctl endpoint health.

Шаг 3: Подключение контрольной плоскости к восстановленному etcd

Теперь нужно направить kube-apiserver на восстановленный etcd. Отредактируйте манифест kube-apiserver:

vim /etc/kubernetes/manifests/kube-apiserver.yaml

Найдите аргумент --etcd-servers и измените его значение на https://127.0.0.1:2379 (или соответствующий IP). Убедитесь, что пути к сертификатам etcd (--etcd-cafile, --etcd-certfile, --etcd-keyfile) корректны. Kubelet автоматически перезапустит pod kube-apiserver. Аналогично проверьте аргументы --etcd-servers в манифестах kube-controller-manager и kube-scheduler. После рестарта компонентов проверьте состояние кластера: kubectl get nodes. На этом этапе должна отображаться новая мастер-нода в статусе Ready.

Сценарий 2: Восстановление приложений и данных с помощью Velero

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

Шаг 1: (Если необходимо) Повторная установка Velero в восстановленный кластер

Если Velero не был установлен заранее, установите его, используя те же настройки BackupStorageLocation, что и для исходного кластера. Это критично для доступа к существующим бэкапам. Команда установки идентична приведенной в разделе подготовки.

Шаг 2: Выбор целевого бэкапа и создание задачи восстановления

Получите список доступных бэкапов: velero backup get. Выберите последний успешный бэкап и запустите восстановление. Для тонкого контроля можно восстанавливать отдельные неймспейсы или типы ресурсов.

velero restore create --from-backup daily-full-backup-20260505-0200 \
  --include-namespaces production,monitoring

Мониторьте прогресс: velero restore describe <RESTORE_NAME>. Если вы используете Helm для управления релизами, после восстановления базовых ресурсов может потребоваться синхронизация. Команды для этого вы найдете в шпаргалке по Helm CLI.

Шаг 3: Особенности восстановления Persistent Volumes и данных

Способ восстановления PV зависит от исходной конфигурации Velero. При использовании снапшотов облачного провайдера Velero создаст новые тома из этих снапшотов. При использовании Restic данные будут восстановлены в существующие тома. Если StorageClass в новом кластере отличается, используйте флаг --storage-class для маппинга. Проверьте, что PVC перешли в статус Bound:

kubectl get pvc -A

Для проверки целостности данных подключитесь к одному из восстановленных подов и убедитесь в наличии файлов: kubectl exec -it <pod_name> -- ls -la /data. Для диагностики более сложных проблем с пользовательскими ресурсами обратитесь к руководству по полной диагностике Custom Resources в Kubernetes.

Пост-восстановительные проверки и типичные проблемы

После завершения всех операций необходимо системно проверить кластер. Пропуск этого этапа может оставить скрытые проблемы.

Чек-лист полной проверки восстановленного кластера

1. Кластер: kubectl get nodes - все ноды в статусе Ready.
2. Поды: kubectl get pods -A - все критические поды (особенно в kube-system) работают. Нет pods в статусе CrashLoopBackOff.
3. Сервисы: kubectl get svc -A - проверьте, что у сервисов есть ClusterIP и Endpoints.
4. Рабочие нагрузки: kubectl get deployments,statefulsets -A - все реплики готовы.
5. Данные: kubectl get pv,pvc -A - все PVC Bound, PV Available или Bound.
6. Сеть: Проверьте доступность ingress-контроллера и внутренний DNS.
7. Логи: Просмотрите логи ключевых приложений на наличие ошибок инициализации.

Решение частых ошибок: конфликты, доступы и классы хранилищ

• Конфликт ресурсов (AlreadyExists): Velero не может создать ресурс, потому что он уже есть в кластере. Решение: удалить существующий ресурс перед восстановлением или использовать флаг --allow-partially-failed и флаг --existing-resource-policy со значением update.
• Отсутствующие Secrets или ServiceAccounts: Восстановите их отдельно из бэкапа или создайте вручную. Проверьте, что у подов есть правильные serviceAccountName.
• Проблемы с StorageClass: Если оригинальный StorageClass отсутствует, PVC останутся в статусе Pending. Создайте StorageClass с тем же именем или укажите при восстановлении флаг --storage-class new-storage-class.
• Сетевые политики: Восстановленные NetworkPolicy могут блокировать трафик. Временно отключите их для проверки базовой связности.

Интеграция восстановления в процессы DevOps и мониторинг

Разовая процедура восстановления должна превратиться в стандартизированный процесс. Автоматизируйте создание бэкапов etcd с помощью cron-заданий или systemd-таймеров. Настройте в Velero несколько расписаний с разной гранулярностью (например, ежечасно для данных, ежедневно для полного состояния). Интегрируйте проверку свежести бэкапов в ваш мониторинг (Prometheus, Grafana): настройте алерт, если последний успешный бэкап старше 24 часов. Самый важный шаг - регулярно проводите учебные тревоги. Восстанавливайте тестовый кластер из бэкапов продакшена в изолированном окружении. Это не только проверяет работоспособность бэкапов, но и тренирует команду. Документируйте все шаги в структурированной базе знаний, чтобы любой член команды мог действовать по инструкции. О том, как построить такую систему, читайте в нашем практическом руководстве по построению базы знаний. Для автоматизации рутинных операций и анализа логов рассмотрите использование специализированных AI-инструментов для разработчиков, таких как AiTunnel, которые могут ускорить поиск решений.