Замена StatefulSets на Custom Operator: опыт Timescale

Всем привет!

На протяжении некоторого времени команда Timescale использовала StatefulSets для того, чтобы управлять клиентскими database pods и их volumes.

Однако, у StatefulSets есть ряд неудобств, например: «неизменность» VolumeClaimTemplate; нюансы, связанные с изменением размера Volume; особенности работы Rolling Update и не только (больше информации можно найти в статье).

Из-за вышеописанных причин команда решила заменить «стандартные» StatefulSets на собственные, которые они назвали PatroniSets. И, конечно же, не обошлось без собственного Kubernetes Operator’a.

Ребята определили набор требований:
🍭 Новый ресурс должен быть прямой заменой StatefulSets с «бесшовной миграцией»
🍭 Он должен понимать контекст PostgreSQL/Patroni: кто есть «главный»
🍭 CR должен быть полностью декларативен
🍭 Любые действия должны быть направлены на сокращение времени простоя. Например, в HA варианте реплика обновляется первой
🍭 Он должен управлять всеми изменения Volumes и не только

После определения требований команда начала разработку собственного оператора. Логика его работы и подводные камни, с которыми столкнулись в Timescale при его разработке - все это можно найти в статье.

В результате PatroniSets начали использовать для новых сервисов в феврале 2024 года. Спустя некоторое время команда убедилась в работоспособности концепта и готова переводить на него существующие сервисы.