Год назад Kubernetes в банке оставался темой для пилотов. Сегодня мы выводим его в промышленную эксплуатацию: десятки команд разработки, сотни сервисов, требования ЦБ к непрерывности и аудиту. Релиз 1.7 в июле добавил то, чего не хватало для серьёзной нагрузки, – Network Policy в основной поставке, шифрование секретов в etcd, контроль доступа к kubelet. Но главный сдвиг не в самой платформе, а в подходе к эксплуатации stateful-нагрузок. Ручное администрирование баз и очередей в кластере не масштабируется. Ответ – оператор.

Зачем оператору stateful-сервисы

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

Оператор – это контроллер, который кодирует операционные знания о конкретном сервисе. Он расширяет API кластера собственным ресурсом (Custom Resource) и непрерывно сводит фактическое состояние к желаемому. Администратор описывает «кластер из трёх реплик с синхронной репликацией» – оператор сам создаёт поды в нужном порядке, настраивает репликацию, при отказе мастера проводит failover и переключает трафик. То, что раньше делал дежурный инженер по runbook ночью, теперь выполняет код за секунды и с предсказуемым результатом.

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

Что мы закрываем в банковском контуре

Технология – половина дела. В банке оператор обязан вписаться в требования информационной безопасности и регулятора. Мы решаем это так:

  • Изоляция. Каждая команда работает в своём namespace с квотами и Network Policy. Платёжный контур физически отделён от тестового – сетевые политики запрещают трафик между зонами по умолчанию.
  • Секреты. Пароли и ключи шифруются в etcd, выдаются подам через тома, ротируются оператором без простоя сервиса.
  • Аудит. Каждое действие оператора и каждый запрос к API кластера пишется в неизменяемый журнал. Для проверки ЦБ важно не только что система работает, но и кто, когда и что в ней менял.
  • Бэкап и восстановление. Оператор снимает согласованные резервные копии по расписанию и регулярно прогоняет тестовое восстановление в изолированном namespace.

Этот контур мы строим в логике, близкой к enterprise-блокчейну на Hyperledger: закрытый периметр, контроль участников, полная прослеживаемость операций. Разница в том, что Kubernetes – зрелая производственная платформа с понятной экономикой, а не ставка на технологию, ажиотаж вокруг которой нередко опережает реальную пользу.

Что это даёт банку

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

Вывод

Оператор переводит эксплуатацию stateful-сервисов из режима ручного труда в управляемый код. Для банка это означает предсказуемость, аудируемость и масштаб без раздувания штата администраторов. Если вы планируете промышленный Kubernetes под регуляторные требования, всё начинается с проектирования отказоустойчивой инфраструктуры под банковские нагрузки: кластер, операторы и эксплуатационный контур под конкретные сервисы.