Как спроектировать стратегию disaster recovery для stateful-приложений, работающих в Kubernetes (включая etcd и персистентные тома), и какие здесь компромиссы?

Короткий ответ

Единого рецепта нет: полноценный DR-план должен отдельно покрывать резервное копирование etcd (состояние самого кластера Kubernetes) и резервное копирование/репликацию данных persistent-томов приложений (которые etcd не включает), с конкретными RTO/RPO, определяемыми бизнес-требованиями, а также регулярным тестированием восстановления — выбор между снапшотами тома, приложенческой репликацией и кросс-региональным резервированием зависит от характера данных и допустимого окна потери данных.

Как это работает подробнее

etcd хранит только описание состояния объектов Kubernetes (манифесты, статусы) — его снапшот (etcdctl snapshot save) позволяет восстановить конфигурацию кластера, но не содержит данные, физически находящиеся на персистентных томах (базы данных, файлы). Поэтому DR для stateful-приложений требует отдельного механизма резервного копирования самих данных — снапшотов облачных дисков, встроенной репликации СУБД, или инструментов уровня Kubernetes (Velero с интеграцией CSI snapshot) для согласованного бэкапа и PV, и сопутствующих манифестов одновременно.

• Компромисс. частота снапшотов и бэкапов напрямую определяет RPO (сколько данных потенциально потеряется), а сложность и стоимость инфраструктуры восстановления — RTO (как быстро можно восстановиться); более частые бэкапы и горячий резерв в другом регионе снижают оба показателя, но кратно увеличивают стоимость и сложность поддержки. План должен прямо обсуждаться с владельцами бизнеса в терминах конкретных цифр RTO/RPO для каждой системы, а не приниматься инженерами в одностороннем порядке, и обязательно проверяться регулярными учениями восстановления, а не только документироваться.

Пример кода

Команды и выводКопировать

etcdctl snapshot save /backup/etcd-snapshot-$(date +%F).db --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key
velero backup create nightly-prod --include-namespaces prod --snapshot-volumes

Что использовать на практике

• Практика. важно различать репликацию (защищает от отказа узла/зоны в реальном времени, но не от логической порчи данных — ошибочный DELETE реплицируется мгновенно) и бэкапы (защищают от логической порчи ценой задержки восстановления и потенциальной потери данных за период между бэкапами); DR-план stateful-системы должен включать оба механизма, а не полагаться на один из них. Для кросс-регионального DR нужно решить, насколько синхронной должна быть репликация данных между регионами, явно принимая компромисс между задержкой записи (при синхронной репликации) и риском потери данных при failover (при асинхронной).

Подводные камни

• Риски. частая ошибка — считать, что снапшот etcd восстанавливает и данные на персистентных томах; также кандидаты нередко путают репликацию с резервным копированием, ошибочно полагая, что репликация сама по себе защищает от логической порчи данных (например, ошибочного DELETE).