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

Habr ·

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

Привет, Хабр! В этой статье хочу рассказать, как мы добивались настоящей отказоустойчивости для платформы, растянутой на несколько датацентров, с какими проблемами столкнулись по дороге и какие инструменты нам пришлось для этого написать. Многие знают нас как разработчиков 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 оказался готов к этому куда меньше, чем принято считать, и многое нам пришлось достраивать самим. Читать далее

Источник: Habr