Vault на Raft: HA и DR со снапшотами в Kubernetes

5 августа 2026 г.

#disaster-recovery#hashicorp#high-availability#kubernetes#raft#secrets-management#vault

Как мы переработали архитектуру Vault с помощью Raft, снапшотов и DR

Автор: Моше Левин (Moshe Levine), руководитель DevOps-команды, BioCatch. Профиль на Medium: medium.com/@moshlevine.

Управление секретами в масштабе — это не только вопрос безопасности, но и доступности, отказоустойчивости и экономичности. В BioCatch мы используем HashiCorp Vault для управления секретами в среде Kubernetes, однако первоначальная конфигурация оставляла желать лучшего.

Рассказываем, как мы переработали архитектуру Vault, задействовав хранилище Raft, автоматизацию на базе Kubernetes и аварийное восстановление (disaster recovery, DR) на основе снапшотов — и получили систему с высокой доступностью, разумными затратами и готовностью к продакшену.

Проблемы исходной конфигурации

Наш первоначальный деплой Vault был достаточно прямолинейным:

  • развёрнут как единственный pod в кластере K8S;

  • использует Azure Storage Account в качестве бэкенда хранилища;

  • механизмы высокой доступности и аварийного восстановления отсутствовали.

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

1. Высокие операционные затраты

Каждое чтение или запись в Vault инициирует операцию ввода-вывода в Azure Storage. Частые транзакции оборачивались значительными расходами — особенно по мере роста нагрузки и числа секретов.

2. Отсутствие высокой доступности (HA)

Единственный экземпляр Vault означал, что любой сбой — падение pod, неудачное обновление или ошибочная конфигурация — мог нарушить управление секретами во всех средах.

3. Восстановление вручную и его ненадёжность

Если Vault становился недоступен или повреждался, восстановление выполнялось вручную: нужно было повторно загрузить данные из Azure Storage, заново инициализировать Vault и переприменить конфигурации. Для системы, которая должна быть доступна всегда, это занимало слишком много времени.

Цели новой архитектуры

Мы сформулировали новый набор требований:

  • снижение операционных затрат;

  • встроенная высокая доступность с возможностью прозрачного переключения при отказе;

  • простое создание снапшотов и восстановление данных Vault;

  • работоспособная DR-среда с минимальной сложностью;

  • мониторинг и алертинг системы.

Vault с Raft: более простой, дешёвый и мощный бэкенд хранилища

Вместо внешнего бэкенда — Azure Storage или Consul — мы перешли на встроенное хранилище Raft (Raft Integrated Storage), которое является частью самого Vault.

Что такое Raft?

Raft — это алгоритм консенсуса, предназначенный для управления реплицированным журналом в распределённой системе. Он гарантирует согласованность состояния данных на всех узлах даже при отключении части из них.

Реализация Raft в Vault:

  • хранит все секреты и метаданные непосредственно внутри Vault;

  • поддерживает выборы лидера (leader election) и репликацию журнала между узлами;

  • готова к продакшену и не требует внешних зависимостей.

Схема архитектуры Raft-кластера Vault

Как Raft обеспечивает высокую доступность

В режиме Raft Vault работает как многоузловой кластер, в котором один узел избирается лидером. Лидер обрабатывает все операции записи и реплицирует изменения на узлы-последователи (follower). При отказе лидера кластер автоматически выбирает нового, не прерывая доступность.

По сути, каждый узел Vault с хранилищем Raft держит у себя локальную реплицированную копию данных Vault.

В нашей продакшен-среде работают три pod Vault, каждый на отдельном узле K8S — для обеспечения избыточности.

С Raft высокая доступность Vault управляется самостоятельно. Преимущества использования Raft:

  • Упрощённый деплой: не требуются внешние зависимости вроде Consul или сторонних баз данных, что снижает сложность и операционные издержки.

  • Высокая доступность: надёжная отказоустойчивость и автоматические выборы лидера гарантируют работу Vault даже при отказе узлов.

  • Строгая согласованность: архитектура Raft обеспечивает строгую согласованность данных, исключая их потерю или рассогласование.

  • Снапшоты и восстановление: простое создание снапшотов для резервного копирования и понятный процесс восстановления.

  • Официальная поддержка HashiCorp: решение официально поддерживается и развивается HashiCorp, что гарантирует совместимость и актуальность.

Дизайн новой архитектуры

Вот как работает новая конфигурация Vault от начала до конца.

1. Два окружения: продакшен и аварийное восстановление (DR)

Теперь у нас два изолированных кластера Vault:

  • Продакшен-кластер Vault — основная система, обрабатывает весь трафик приложений.

  • DR-кластер Vault — развёрнут в отдельном кластере K8S (другой регион), используется только при переключении при отказе.

Оба кластера используют одинаковую конфигурацию, хранилище Raft и методы аутентификации.

2. Автоматизированные снапшоты из продакшена

CronJob в продакшен-кластере выполняется раз в сутки и:

  1. Использует vault operator raft snapshot save для экспорта полного состояния Raft.

  2. Загружает снапшот в защищённый контейнер Azure Blob Storage.

Мы храним снапшоты за последние 30 дней для надёжности и возможности отката. Каждый снапшот включает:

  • все секреты;

  • политики Vault и методы аутентификации;

  • внутренние метаданные Raft и состояние кластера.

3. Асинхронное восстановление в DR

В DR-кластере ещё один CronJob работает ежедневно и:

  1. Скачивает последний снапшот из Azure Blob Storage.

  2. Использует vault operator raft snapshot restore для перезаписи состояния DR-Vault.

Это обеспечивает непрерывную синхронизацию DR-Vault с продакшеном. Поскольку восстановление выполняется из снапшота лидера продакшен-кластера, состояние является согласованным и полным.

Схема процессов снапшотирования и восстановления между продакшен- и DR-кластерами

4. Ingress и DNS для прозрачного переключения при отказе

Для надёжной высокой доступности оба кластера — основной и DR — доступны через идентичные конфигурации Ingress под единым DNS-именем (например, vault.mycompany.com).

В штатном режиме DNS-запись указывает на IP-адрес Ingress продакшен-кластера. При сбое мы оперативно обновляем DNS, переключая трафик на IP-адрес балансировщика нагрузки DR-кластера.

Такое практически мгновенное переключение — одно из ключевых преимуществ подхода: приложения не нужно перенастраивать, а для конечных пользователей всё остаётся прозрачным. Кроме того, поскольку конфигурация и состояние Vault точно восстанавливаются из снапшотов, критически важные потоки аутентификации — OIDC, AppRole или K8S JWT — продолжают работать после переключения без каких-либо сбоев.

Операционный мониторинг: уверенность в автоматизации

Мы выстроили слой наблюдаемости (observability) вокруг этой системы:

  • Логирование: все операции создания снапшотов и восстановления централизованно логируются.

  • Алерты: настроены правила оповещения, которые уведомляют DevOps-команду, если:

    • снапшот не был создан;

    • восстановление на стороне DR завершилось с ошибкой;

    • Vault перешёл в нездоровое состояние (например, проблемы с seal-статусом или выборами лидера).

Эти меры дают нам уверенность в том, что DR-среда готова к работе в любой момент.

Итоги

Vault — система критической важности. Переход на Raft Integrated Storage и построение механизма DR на основе снапшотов позволили нам упростить архитектуру, одновременно повысив её отказоустойчивость.

Этот подход не требует Vault Enterprise, внешних баз данных или сложной автоматизации — только инструменты с открытым исходным кодом, CronJob в K8S и грамотные DevOps-практики.

Если вы используете Vault с внешними бэкендами хранилища и испытываете трудности с затратами, производительностью или сложностью DR — рассмотрите миграцию на Raft. Возможно, именно этого не хватало вашей архитектуре.

Похожее

© 2026 meganuke