Резервное копирование и восстановление etcd: полное руководство по безопасному обновлению Kubernetes на практике | AdminWiki
Logo

Резервное копирование и восстановление etcd: полное руководство по безопасному обновлению Kubernetes на практике

06 августа 2026 11 мин. чтения
Содержание статьи

Снапшот etcd - это страховка, без которой обновление Kubernetes превращается в игру в русскую рулетку. Если вы планируете апгрейд кластера, первое и обязательное действие - создание полного бэкапа хранилища ключ-значение. Без него любая ошибка в процессе обновления может привести к необратимой потере конфигурации всего кластера: от неймспейсов и деплойментов до секретов и сервисных аккаунтов.

В этом руководстве разобраны все актуальные методы резервного копирования etcd: от ручного создания снапшота утилитой etcdctl до автоматизации выгрузки в облачное S3-хранилище. Вы получите готовые команды для проверки целостности данных, пошаговые сценарии восстановления на существующий и новый кластер, а также план отката при неудачном обновлении. Все инструкции проверены на практике в production-окружениях.

Почему бэкап etcd - это критически важно при обновлении Kubernetes

etcd - это распределенное key-value хранилище, в котором Kubernetes хранит все свои объекты. Поды, сервисы, конфигурации, секреты, роли, политики сети - полное состояние кластера находится именно здесь. Без работающего etcd API-сервер не может обслуживать запросы, а кластер превращается в черный ящик без памяти.

Обновление Kubernetes - операция повышенного риска для etcd. Причина проста: меняется версия API хранилища, формат данных может мигрировать, а сам процесс требует перезапуска мастер-компонентов. Типовые фатальные последствия потери данных etcd:

  • Полная потеря информации о всех запущенных подах - кластер продолжает работать, но управление исчезает.
  • Удаление всех секретов и конфигураций - приложения теряют доступ к базам данных и внешним сервисам.
  • Разрушение RBAC-политик - доступ к кластеру становится неконтролируемым.

Восстановление после таких инцидентов без бэкапа - это ручное пересоздание всех ресурсов. На практике это часы или дни простоя. Снапшот etcd, сделанный до обновления, позволяет откатить состояние кластера за считанные минуты. Это не рекомендация - это обязательный этап подготовки, такой же как проверка совместимости версий или чтение changelog'а.

Если вы используете инструменты автоматизации вроде Kubespray, они часто делают снапшот автоматически. Но полагаться только на это - ошибка. Детальнее стратегии обновления с минимизацией простоя разобраны в руководстве по отказоустойчивости и реальным сценариям обновлений. Там же - готовые команды отката и настройки мониторинга.

Подготовка к резервному копированию: что нужно знать и проверить

Перед созданием снапшота выполните три обязательных проверки. Они занимают минуту, но исключают ошибки «на лету» в стрессовой ситуации.

Первое: убедитесь, что утилита etcdctl доступна и ее версия соответствует версии etcd в кластере. Команда для проверки:

etcdctl version

Второе: проверьте доступность кластера etcd. Отправьте простой запрос на запись и чтение тестового ключа - это подтвердит, что хранилище работает и аутентификация корректна.

Третье: оцените размер текущих данных etcd. Снапшот будет примерно такого же объема. Убедитесь, что на целевом разделе достаточно места - минимум в 1.5 раза больше текущего размера БД etcd.

Определение endpoints и аутентификация

Для подключения к etcd утилите etcdctl нужны три параметра: адреса endpoints, пути к сертификатам для TLS-аутентификации. В кластере, развернутом через kubeadm, эти данные лежат в статическом манифесте etcd и в директории сертификатов.

Типовые пути для kubeadm-кластера:

  • Endpoints: https://127.0.0.1:2379 (если etcd работает локально на мастер-ноде)
  • CA-сертификат: /etc/kubernetes/pki/etcd/ca.crt
  • Клиентский сертификат: /etc/kubernetes/pki/etcd/server.crt
  • Клиентский ключ: /etc/kubernetes/pki/etcd/server.key

Проверьте соединение командой:

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 \
  endpoint health

Ответ должен содержать статус здоровья кластера и список всех узлов etcd. Если получаете ошибку аутентификации - проверьте права на файлы ключей. Они должны читаться пользователем, от которого запускается etcdctl (обычно root).

Выбор места хранения бэкапа

Хранение снапшота на том же диске, где лежат данные etcd - критическая ошибка. При выходе из строя файловой системы или всего узла вы теряете и оригинал, и копию. Бэкап должен размещаться на отдельном физическом носителе или удаленной машине.

Рекомендованные варианты в порядке надежности:

  1. Удаленный сервер по SSH/NFS - бэкап доступен даже при полном отказе мастер-ноды.
  2. Облачное объектное хранилище (S3) - геораспределенное хранение с версионированием.
  3. NAS или SAN в локальной сети - защита от отказа одного узла, но не от проблем сети.
  4. Отдельный локальный раздел - приемлемо только для тестовых кластеров.

Для продакшена минимальный стандарт - хранение снапшота вне узла, где работает etcd. Это гарантирует доступность бэкапа при восстановлении на новый кластер.

Пошаговое создание снапшота etcd с помощью etcdctl

Снапшот создается одной командой. Но важно понимать каждый флаг - это исключает ошибки при автоматизации и отладке.

Базовая команда для создания снапшота:

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 /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

Разбор флагов:

  • ETCDCTL_API=3 - принудительно использует API третьей версии. Без этого часть команд может не работать.
  • --endpoints - адрес etcd. Для локального узла 127.0.0.1:2379, для удаленного - IP ноды.
  • --cacert, --cert, --key - пути к TLS-сертификатам. Без них etcdctl не пройдет аутентификацию.
  • snapshot save - подкоманда создания снапшота.
  • /backup/... - путь к файлу снапшота. Рекомендуется включать дату и время в имя для версионирования.

При успешном выполнении команда выводит информацию о созданном снапшоте: хеш, ревизию, количество ключей. Файл снапшота - это полная бинарная копия базы данных etcd на момент выполнения команды. Все транзакции, завершенные до этого момента, в него включены.

Запуск от обычного пользователя возможен, если у него есть права на чтение сертификатов. На практике чаще всего используют root или sudo. Если кластер развернут не через kubeadm - пути к сертификатам могут отличаться. Найдите их в конфигурации etcd или манифесте пода.

Проверка целостности снапшота

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

Первая проверка - статус снапшота:

ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot-20260806-120000.db

Вывод содержит три ключевых параметра:

  • hash - контрольная сумма данных. Поврежденный файл выдаст ошибку проверки хеша.
  • revision - номер последней транзакции, включенной в снапшот. Должен быть положительным числом.
  • total keys - количество ключей в снапшоте. Нулевое значение при работающем кластере - признак проблемы.

Вторая, более глубокая проверка - тестовое восстановление снапшота во временную директорию:

ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot-20260806-120000.db \
  --data-dir=/tmp/etcd-test-restore

Если команда отрабатывает без ошибок и создает файлы в указанной директории - снапшот целостен. После проверки временную директорию можно удалить. Эта процедура занимает несколько секунд и гарантирует, что бэкап не подведет в аварийной ситуации.

Для полной уверенности настройте автоматическое тестирование восстановления. Это обсуждается в разделе best practices.

Автоматизация резервного копирования etcd

Ручной бэкап перед обновлением - обязательный минимум. Для production-кластеров этого недостаточно. Состояние кластера меняется постоянно, и снапшот недельной давности означает потерю всех изменений за этот период. Автоматизация решает эту проблему.

Базовый скрипт для ежедневного бэкапа с ротацией старых копий:

#!/bin/bash
BACKUP_DIR="/backup/etcd"
RETENTION_DAYS=7
SNAPSHOT_NAME="etcd-snapshot-$(date +%Y%m%d-%H%M%S).db"

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 "${BACKUP_DIR}/${SNAPSHOT_NAME}"

# Проверка статуса созданного снапшота
etcdctl snapshot status "${BACKUP_DIR}/${SNAPSHOT_NAME}"

# Удаление снапшотов старше RETENTION_DAYS
find ${BACKUP_DIR} -name "etcd-snapshot-*.db" -type f -mtime +${RETENTION_DAYS} -delete

Скрипт делает три вещи: создает снапшот с датированным именем, проверяет его целостность, удаляет копии старше 7 дней. Разместите его на одной из мастер-нод и добавьте в cron:

0 2 * * * /usr/local/bin/etcd-backup.sh >> /var/log/etcd-backup.log 2>&1

Запуск в 2 часа ночи снижает нагрузку на кластер в пиковые часы. Логирование позволит отследить проблемы, если бэкап перестанет создаваться.

Альтернативный подход - использование Kubernetes CronJob. Потребуется под с доступом к сертификатам etcd, смонтированным как hostPath. Этот метод сложнее в настройке, но удобнее для централизованного управления. Готовый пример такого подхода для резервного копирования данных приложений в TrueNAS SCALE разобран в руководстве по бэкапу Kubernetes-приложений - там же скрипты для автоматического копирования PVC и конфигураций Helm-чартов.

Экспорт снапшотов в облачное хранилище (S3)

Локальный бэкап на мастер-ноде не защищает от катастроф уровня ЦОД: пожар, затопление, массовый сбой оборудования. Для защиты от таких сценариев снапшоты необходимо реплицировать в географически удаленное хранилище.

S3-совместимое объектное хранилище - стандарт для этой задачи. Оно поддерживает версионирование, автоматические политики жизненного цикла и шифрование. Схема работы:

  1. Создается локальный снапшот описанным выше скриптом.
  2. Файл загружается в S3-бакет с помощью AWS CLI или rclone.
  3. Старые версии автоматически удаляются согласно настроенной политике.

Пример загрузки снапшота с помощью AWS CLI:

aws s3 cp /backup/etcd/etcd-snapshot-20260806-120000.db \
  s3://my-cluster-backups/etcd/etcd-snapshot-20260806-120000.db \
  --storage-class STANDARD_IA

Storage class STANDARD_IA снижает стоимость хранения для данных, к которым редко обращаются. Настройка политики жизненного цикла для автоматического удаления снапшотов старше 30 дней:

aws s3api put-bucket-lifecycle-configuration --bucket my-cluster-backups \
  --lifecycle-configuration '{
    "Rules": [{
      "Id": "expire-old-etcd-snapshots",
      "Prefix": "etcd/",
      "Status": "Enabled",
      "Expiration": { "Days": 30 }
    }]
  }'

Для тех, кто использует Timeweb Cloud или аналогичные облачные провайдеры, объектное хранилище часто доступно как встроенный сервис с посекундной тарификацией. Это избавляет от необходимости поднимать отдельный S3-совместимый сервер. Timeweb Cloud предоставляет облачную инфраструктуру, включая объектное хранилище и управляемые Kubernetes-кластеры - это решает задачу размещения бэкапов вне основного ЦОДа.

Для более сложных сценариев с шифрованием и дедупликацией используйте rclone. Он поддерживает десятки бэкендов, включая S3, Google Cloud Storage, Azure Blob. Подробная настройка автоматического резервного копирования с BorgBackup, rclone и rsync разобрана в стратегии резервного копирования сервера в 2026 - там же готовые скрипты для cron и systemd с тестами восстановления.

Восстановление etcd из снапшота: пошаговые сценарии

Бэкап бесполезен, если вы не знаете, как его восстановить. Разберем два основных сценария: восстановление на существующий кластер и миграцию на новый.

Общее требование для обоих сценариев: kube-apiserver должен быть остановлен на время восстановления etcd. API-сервер не умеет переподключаться к etcd «на лету» после смены данных. Если этого не сделать - кластер перейдет в несогласованное состояние.

Восстановление на существующий кластер

Этот сценарий применяется, когда нужно откатить состояние etcd до момента снапшота. Все изменения, сделанные после создания бэкапа, будут потеряны.

Пошаговый алгоритм:

  1. Остановите kube-apiserver на всех мастер-нодах. В kubeadm-кластере достаточно переместить манифест из директории static pod: mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/. Kubelet автоматически остановит под.
  2. Остановите etcd на всех узлах кластера etcd. Аналогично: mv /etc/kubernetes/manifests/etcd.yaml /tmp/.
  3. На каждой ноде etcd выполните восстановление снапшота в новую директорию данных: 
    ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot-20260806-120000.db \
  --name=master-0 \
  --initial-cluster=master-0=https://10.0.0.1:2380,master-1=https://10.0.0.2:2380,master-2=https://10.0.0.3:2380 \
  --initial-advertise-peer-urls=https://10.0.0.1:2380 \
  --data-dir=/var/lib/etcd-restored
    Параметр --name и адреса должны соответствовать конкретному узлу.
  4. Обновите манифест etcd, указав новый data-dir: /var/lib/etcd-restored.
  5. Верните манифест etcd на место: mv /tmp/etcd.yaml /etc/kubernetes/manifests/. Kubelet запустит etcd с восстановленными данными.
  6. После успешного запуска etcd на всех узлах верните манифест kube-apiserver.
  7. Проверьте состояние кластера: kubectl get nodes, kubectl get pods --all-namespaces.

Ключевой момент: флаг --initial-cluster должен содержать все узлы etcd с их peer-адресами. Если кластер etcd состоит из одного узла - укажите только его. Ошибка в этом параметре приведет к отказу etcd присоединиться к кластеру.

Восстановление на новый кластер (миграция)

Сценарий полного восстановления Kubernetes с нуля. Применяется при безвозвратной потере всех мастер-нод или миграции на новое оборудование.

Алгоритм:

  1. Подготовьте новые серверы с установленным kubeadm, kubelet и container runtime (containerd или CRI-O).
  2. Скопируйте снапшот etcd и сертификаты (/etc/kubernetes/pki/) со старого кластера на новый. Без оригинальных сертификатов восстановить кластер невозможно - все внутренние коммуникации завязаны на них.
  3. Выполните etcdctl snapshot restore с указанием нового кластера etcd.
  4. Запустите etcd на новых узлах.
  5. Инициализируйте control plane с помощью kubeadm, указав восстановленные сертификаты: 
    kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd \
  --cert-dir=/etc/kubernetes/pki
  6. Проверьте доступность всех ресурсов: поды, сервисы, ingress, конфигурации, PVC.

PVC и данные приложений не восстанавливаются из снапшота etcd - etcd хранит только метаданные Kubernetes. Для восстановления данных приложений нужен отдельный механизм, например, Velero. Детальный процесс полного аварийного восстановления - от etcd до данных приложений - разобран в руководстве по восстановлению кластера Kubernetes за 3 этапа с готовыми командами для Velero и Persistent Volumes.

Проверенные практики (best practices) для production-окружений

Отдельные команды и скрипты - это база. Надежная стратегия резервного копирования строится на процессах и регулярных проверках. Шесть правил, которые предотвращают фатальные ошибки в production.

1. Регулярное тестирование восстановления. Раз в месяц восстанавливайте последний снапшот в изолированное окружение. Это единственный способ убедиться, что бэкап рабочий. Автоматизируйте этот процесс - скрипт восстановления и проверки целостности должен отрабатывать без ручного вмешательства.

2. Хранение бэкапов вне кластера. Минимум одна копия снапшота должна находиться физически отдельно от кластера etcd. S3-бакет в другом регионе, удаленный сервер по SSH, холодное хранилище. Правило 3-2-1: три копии, на двух разных типах носителей, одна географически удалена.

3. Мониторинг состояния etcd. Настройте алерты на метрики etcd: задержка записи (wal_fsync_duration_seconds), размер БД (db_total_size_in_bytes), количество лидерных переходов. Рост задержек или частые смены лидера - ранние признаки деградации, которые требуют внепланового бэкапа до того, как кластер развалится.

4. Документирование процедуры. Восстановление etcd - редкая операция. В стрессовой ситуации никто не вспомнит точные пути к сертификатам и флаги команд. Держите актуальный runbook с пошаговым алгоритмом и проверенными командами для вашего конкретного окружения.

5. Версионирование снапшотов. Имя файла должно включать дату, время и версию etcd. Это упрощает поиск нужного бэкапа и исключает восстановление снапшота несовместимой версии.

6. Шифрование бэкапов. Снапшот etcd содержит все секреты Kubernetes в открытом виде. При хранении вне кластера обязательно шифруйте файлы - на уровне S3-бакета (server-side encryption) или на уровне инструмента (gpg, rclone crypt).

План отката при обновлении Kubernetes

Обновление пошло не по плану: API-сервер не стартует, поды в CrashLoopBackOff, CNI не поднимается. Паника - плохой советчик. Действуйте по заранее подготовленному алгоритму.

Шаги отката:

  1. Остановите процесс обновления. Не пытайтесь «допилить» сломанный кластер. Каждая дополнительная операция усложняет откат.
  2. Восстановите etcd из последнего снапшота, сделанного до обновления. Используйте сценарий «восстановление на существующий кластер» из раздела выше.
  3. Откатите версии компонентов control plane. Верните прежние версии kube-apiserver, kube-controller-manager, kube-scheduler и etcd. В kubeadm-кластере это делается через kubeadm upgrade apply с указанием предыдущей версии.
  4. Проверьте работоспособность приложений. Убедитесь, что все критичные сервисы отвечают, PVC доступны, сетевые политики применяются.

После успешного отката проанализируйте логи и метрики, чтобы понять причину сбоя. Следующую попытку обновления планируйте только после устранения корневой причины.

Если вы управляете кластером через Kubespray, процесс отката имеет свою специфику - детали разобраны в пошаговом руководстве по обновлению Kubernetes с Kubespray, включая типовые ошибки и методы их исправления.

Поделиться:
Сохранить гайд? В закладки браузера