Всё Ready, а ничего не работает: как мы учили Kubernetes переживать потерю датацентра

23.10.2026 09:33:55 | Хабр

Хабы: Блог компании Ænix, Kubernetes, DevOps, Разработка публичных облаков, Высоконагруженные системы

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

Многие знают нас как разработчиков Cozystack. Но помимо него в Ænix мы разрабатываем платформу для запуска публичного облака под ключ: с биллингом, проектами, self-service, поддержкой разных бэкендов, включая тот же Cozystack, и интеграциями с внешними системами.

Эта платформа целиком построена на Kubernetes, причём в самом буквальном смысле. Её бэкенд реализован на Kubernetes API Aggregation Layer и controller-runtime, собственные ресурсы хранятся в etcd-кластерах под управлением нашего etcd-operator, а единственная реляционная база данных — Postgres для Keycloak — работает под управлением CNPG-оператора (CloudNativePG). Своего хранилища состояния, своего механизма выбора лидера и своей репликации у платформы нет: всё это она получает от Kubernetes.

Архитектура Kubernetes позволила нам достичь элегантной схемы, где нам не требуется даже реплицируемое хранилище. Никакого DRBD, Ceph или синхронизации дисков между площадками: каждый член etcd и каждая реплика Postgres живут на своём локальном томе, а данные между площадками переносят сами etcd и Postgres своими механизмами репликации. Им в любом случае приходится договариваться о том, какая копия главная, и делать то же самое ещё раз уровнем ниже было бы лишним. К тому же блочная репликация между городами добавляла бы задержку к каждой записи и ещё один слой, который пришлось бы отдельно учить переживать разрыв связи.

Такой дизайн мы выбрали не случайно. Kubernetes с самого начала проектировался с расчётом на отказоустойчивость: декларативное состояние хранится в etcd с кворумом, контроллеры приводят систему к нему после любого сбоя, всё, что должно работать в одном экземпляре, использует leader election, а пробы убирают трафик с больных подов. Если построить весь бэкенд на этих механизмах, отказоустойчивость платформы в теории достаётся почти бесплатно.

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

Подробнее

Читайте также