Postgres-вторник №5: «PostgreSQL и Kubernetes. CI/CD. Автоматизация тестирования»

В конце минувшего года состоялся очередной прямой эфир российского PostgreSQL-сообщества #RuPostgres, в рамках которого его сооснователь Николай Самохвалов поговорил с техническим директором «Фланта» Дмитрием Столяровым про эту СУБД в контексте Kubernetes.

Мы публикуем стенограмму основной части этой дискуссии, а на YouTube-канале сообщества опубликована полная видеозапись:

Базы данных и Kubernetes

НС: Мы не будем сегодня про VACUUM и CHECKPOINT'ы. Хотим поговорить про Kubernetes. Я знаю, что у тебя уже много лет опыта. Смотрел твои видео и некоторые даже кусочками пересматривал… Давай сразу с места в карьер: зачем вообще Postgres или MySQL в K8s?

ДС: Однозначного ответа на этот вопрос нет и не может быть. Но вообще, это простота и удобство… потенциальные. Всем ведь хочется managed-сервисов.

НС: Чтобы как RDS, только у себя?

ДС: Да: чтобы как RDS, только где угодно.

НС: «Где угодно» — это хорошее замечание. В больших компаниях всё расположено в разных местах. А почему тогда, если это большая компания, не взять готовое решение? Например, есть у Nutanix свои разработки, у других компаний (VMware…) — тот же «RDS, только у себя».

ДС: Но это мы говорим про отдельно взятую реализацию, которая будет работать только в определённых условиях. А если речь про Kubernetes, то здесь огромное разнообразие инфраструктуры (которая может быть в K8s). По сути это стандарт для API к облаку…

НС: Ещё и бесплатно!

ДС: Это не так важно. Бесплатность важна не очень большому сегменту рынка. Важно другое… Ты, наверное, вспоминаешь доклад «Базы данных и Kubernetes»?

НС: Да.

ДС: Я понял, что его восприняли очень неоднозначно. Часть людей подумали, что я говорю: «Ребята, поехали всеми БД в Kubernetes!», — а другие решили, что это всё жуткие велосипеды. А я-то хотел сказать вообще о другом: «Смотрите, что происходит, какие есть проблемы и как их можно решать. Сейчас ехать базами в Kubernetes? Production'ом? Ну, только если вы любите… заниматься определёнными вещами. А вот для dev'а — могу сказать, что рекомендую. Для dev'а очень важна динамичность создания/удаления окружений».

НС: Под dev'ом ты имеешь в виду все окружения, которые не prod? Staging, QA…

ДС: Если говорим про perf-стенды, то уже, наверное, нет, потому что там требования специфичны. Если говорим про особые случаи, где на staging нужна очень большая БД, то тоже, наверное, нет… Если это статичное окружение, долгоживущее, то какая выгода от того, что база расположена в K8s?

НС: Никакой. Но где мы видим статичные окружения? Статичное окружение устарело уже завтра.

ДС: Staging может быть статичным. У нас есть клиенты…

НС: Да, у меня тоже есть. Большая проблема, если у тебя есть база на 10 Тб, а staging — 200 Гб…

ДС: У меня есть очень крутой кейс! На staging находится prod'овая база, в которую вносят изменения. И предусмотрена кнопка: «выкатить в production». Эти изменения — дельты — доливаются (кажется, просто по API'шке синхронизируются) в production. Это очень экзотичный вариант.

НС: Я видел стартапы в Долине, которые сидят в RDS'е или даже в Heroku ещё — это истории 2-3-летней давности, — и они скачивают дамп себе на лаптоп. Потому что база пока всего лишь 80 Гб, а на лаптопе есть место. Потом они докупают диски каждому, чтобы по 3 базы иметь, чтобы разные разработки вести. Вот так бывает тоже. Также видел, что не боятся prod копировать в staging — очень сильно зависит от компании. Но видел и что очень боятся, и что часто не хватает времени и рук. Но прежде, чем мы перейдём к этой теме, хочется услышать про Kubernetes. Я правильно понимаю, что в prod'е пока ни у кого?

ДС: У нас небольшие базы есть в prod'е. Речь про объемы в десятки гигабайт и некритичные сервисы, для которых лень было делать реплики (да и нет такой потребности). И при условии, что под Kubernetes'ом есть нормальное хранилище. Эта база работала в виртуальной машине — условно в VMware, поверх СХД. Мы её поместили в PV и теперь можем переносить её с машины на машину.

НС: Базы такого размера, до 100 Гб, на хороших дисках и при хорошей сети можно раскатать за несколько минут, правильно? Скорость в 1 Гб в секунду — это уже не экзотика.

ДС: Да, для линейной операции это не проблема.

НС: Окей, про prod мы должны только думать. А если мы рассматриваем Kubernetes для не-prod-окружений — как делать? Я вижу, что в Zalando делают оператор, в Crunchy пилят, есть ещё какие-то варианты. И есть OnGres — это наш хороший знакомый Alvaro из Испании: они делают по сути не просто оператор, а целый дистрибутив (StackGres), в который помимо самого Postgres'а ещё и бэкап решили запихать, прокси Envoy…

ДС: Envoy для чего? Балансировки именно трафика Postgres?

НС: Да. То есть они это видят как: если взять Linux-дистрибутив и ядро, то обычный PostgreSQL — это ядро, а они хотят сделать дистрибутив, который будет дружелюбен к облакам и крутиться в Kubernetes. Они стыкуют компоненты (бэкапы и т.п.) и отлаживают, чтобы они хорошо работали.

ДС: Очень круто! По сути это софт, чтобы сделать свой managed Postgres.

НС: У Linux-дистрибутивов вечные проблемы: как делать драйверы, чтобы всё железо поддерживалось. А у них идея, что они в Kubernetes будут работать. Я знаю, что в операторе Zalando мы недавно увидели завязку на AWS и это уже не очень хорошо. Не должно же быть завязки на конкретную инфраструктуру — в чём тогда смысл?

ДС: Не знаю, в какой ситуации конкретно Zalando завязался, но в Kubernetes сейчас storage сделан так, что нельзя generic-способом снять дисковый бэкап. Недавно в стандарте — в последней версии спецификации CSI — сделали возможность снапшотов, но где она реализована? Честно, всё ещё настолько сырое… Мы пробуем CSI поверх AWS, GCE, Azure, vSphere, но чуть начинаешь использовать, как видно, что оно ещё не готово.

НС: Поэтому и приходится иногда завязываться на инфраструктуру. Думаю, это ещё продолжается ранняя стадия — проблемы роста. Вопрос: что бы ты посоветовал новичкам, которые хотят попробовать PgSQL в K8s? Какой оператор, может быть?

ДС: Проблема в том, что Postgres для нас — это 3%. У нас есть ещё очень большой список разного софта в Kubernetes, не буду даже всё перечислять. Например, Elasticsearch. Операторов — куча: какие-то развиваются активно, другие — нет. Мы для себя составили требования, что должно быть в операторе, чтобы мы воспринимали его всерьёз. В операторе именно для Kubernetes — не в «операторе, чтобы делать что-то в условиях Amazon'а»… По факту мы достаточно массово (= почти у всех клиентов) используем единственный оператор — для Redis (скоро опубликуем статью и о нём).

НС: А для MySQL тоже нет? Я знаю, что Percona… так как они теперь занимаются и MySQL, и MongoDB, и Postgres, они должны будут какой-то универсальный запилить: для всех баз, для всех облачных провайдеров.

ДС: Мы не успели посмотреть на операторы для MySQL. Для нас это сейчас не главный фокус. MySQL нормально работает в standalone. Зачем оператор, если можешь просто запустить БД… Можно запустить Docker-контейнер с Postrges, а можно запустить его по-простому.

НС: Об этом тоже был вопрос. Вообще без оператора?

ДС: Да, в 100% у нас PostgreSQL запущен без оператора. Пока что так. Мы активно используем оператор для Prometheus, для Redis. У нас есть в планах найти оператор для Elasticsearch — он больше всего «горит», потому что хотим его в 100% случаях ставить в Kubernetes. Так же, как мы хотим прийти к тому, чтобы MongoDB тоже всегда ставить в Kubernetes. Тут появляются определённые хотелки — есть ощущение, что в этих случаях можно что-то сделать. А про Postgres мы даже не смотрели. Конечно, знаем про существование разных вариантов, но по факту у нас standalone.

БД для тестирования в Kubernetes

НС: Давай перейдём к теме тестирования. Как раскатывать изменения в базе — с точки зрения DevOps-перспективы. Есть микросервисы, много баз, всё время где-то что-то меняется. Как обеспечить нормальный CI/CD, чтобы с позиции СУБД всё было в порядке. Какой у тебя подход?

ДС: Не может быть одного ответа. Есть несколько параметров. Первый — это размер базы, которую мы хотим раскатать. Ты сам упомянул, что в компаниях по-разному относятся к тому, чтобы копия prod-базы была на dev и stage.

НС: А в условиях GDPR, я думаю, они относятся всё более и более аккуратно… Могу сказать, что в Европе уже начали штрафовать.

ДС: Но зачастую можно написать софт, который делает дамп с production'а и его обфусцирует. Получаются prod'овые данные (снапшот, дамп, бинарная копия…), но они анонимизированные. Вместо этого могут быть и скрипты генерации: это могут быть фикстуры или просто скрипт, который генерирует большую базу. Проблема-то какая: сколько времени создаётся базовый образ? И сколько времени развернуть его на нужном окружении?

Мы пришли к схеме: если у клиента есть фикстурный набор данных (минимальная версия базы), то по умолчанию используем их. Если речь идёт о review-окружениях, когда мы создали branch, у нас развернулся экземпляр приложения ­— мы туда раскатываем маленькую базу. Но хорошо получился и вариант, когда с production'а раз в сутки (ночью) снимаем дамп и собираем на его основании Docker-контейнер с PostgreSQL и MySQL с этими загруженными данными. Если из этого образа надо 50 раз развернуть базу, это делается достаточно просто и быстро.

НС: Простым копированием?

ДС: Данные хранятся прямо в Docker-образе. Т.е. у нас есть готовый образ, пусть на 100 Гб. Благодаря слоям в Docker мы можем быстро разворачивать этот образ нужное количество раз. Способ тупой, но работает неплохо.

НС: Дальше, когда тестируете, оно прямо внутри Docker'а меняется, да? Copy-on-write внутри Docker'а — выбрасываем и заново поехали, всё хорошо. Класс! И вы это уже используете вовсю?

ДС: Давно.

НС: Мы очень похожими вещами занимаемся. Только мы не Docker'овский copy-on-write используем, а какой-нибудь ещё.

ДС: Он не generic. А Docker'ный работает повсеместно.

НС: По идее, да. Но у нас тоже там есть модули, можно разные модули сделать и работать с разными файловыми системами. Здесь какой момент. Мы со стороны Postgres'а на всё это по-другому смотрим. Теперь я посмотрел со стороны Docker'а и увидел, что у вас всё работает. Но если база — огромная, например, 1 Тб, то это уже всё долго: и операции ночью, и запихивать всё в Docker… А если 5 Тб запихивать в Docker… Или всё нормально?

ДС: Какая разница: это же блобы, просто биты и байты.

НС: Разница такая: вы это через dump и restore делаете?

ДС: Совсем необязательно. Способы генерации этого образа могут быть разные.

НС: Для некоторых клиентов мы сделали так, что вместо регулярной генерации базового образа мы его постоянно поддерживаем в актуальном состоянии. Он по сути является репликой, но данные получает не с мастера напрямую, а через архив. Бинарный архив, куда WAL'ы накатываются каждый день, там же бэкапы снимаются… Эти WAL'ы потом долетают — с небольшой задержкой (буквально 1-2 секунды) — до базового образа. С него мы любым способом клонируем — сейчас по умолчанию у нас ZFS.

ДС: Но с ZFS вы ограничены одним узлом.

НС: Да. Но у ZFS есть ещё волшебный send: с ним можно послать снапшот и даже (я это еще не очень тестировал, но…) можно досылать дельту между двумя PGDATA. На самом деле, у нас ещё один инструмент, который мы не особо рассматривали для таких задач. В PostgreSQL есть pg_rewind, работающий как «умный» rsync, пропускающий многое из того, что можно не смотреть, потому что там точно ничего не менялось. Мы можем между двумя серверами сделать быструю синхронизацию и отмотать назад точно так же.

Так вот, мы стараемся с этой, более DBA'ной, стороны сделать инструмент, который позволяет сделать то же самое, о чём ты говорил: у нас есть одна база, но мы хотим 50 раз что-то протестировать, чуть ли не одновременно.

ДС: 50 раз означает, что вам нужно заказать 50 Spot'овых инстансов.

НС: Нет, на одной машине всё делаем.

ДС: Но как вы развернёте 50 раз, если эта одна база, скажем, терабайтовая. Скорее всего ей нужно условно 256 Гб RAM?

НС: Да, памяти иногда нужно много — это нормально. Но такой пример из жизни. На production-машине 96 ядер и 600 Гб. При этом для БД используются 32 ядра (даже 16 ядер сейчас иногда) и памяти 100-120 Гб.

ДС: И туда влезает 50 копий?

НС: Так копия-то одна, дальше работает copy-on-write (ZFS'ный)… Расскажу подробнее.

У нас, например, база на 10 Тб. Диск для неё сделали, ZFS ещё сжал её размер процентов на 30-40. Поскольку мы не делаем нагрузочное тестирование, нам точное время отклика не важно: пусть будет до 2 раз тормознее — это окей.

Мы даем возможность программистам, QA, DBA и т.п. выполнять тестирование в 1-2 потока. Например, они могут запустить какую-то миграцию. Она не требует сразу 10 ядер — ей нужен 1 бэкенд Postgres'а, 1 ядро. Миграция запустится — может, autovacuum ещё запустится, тогда второе ядро задействуется. У нас выделено 16-32 ядер, так что 10 человек могут одновременно работать, никаких проблем нет.

Поскольку физически PGDATA одинаковая, получается так, что мы обманываем Postgres на самом деле. Фишка в чем: запускается, например, 10 Postgres'ов одновременно. Проблема обычно какая? Ставят shared_buffers, допустим, в 25%. Соответственно, это 200 Гб. Больше трёх таких уже не запустишь, потому что память кончится.

Но мы в какой-то момент поняли, что это не нужно: мы ставим shared_buffers в 2 Гб. у PostgreSQL есть effective_cache_size, и в реальности только он влияет на планы. Его мы и ставим в 0,5 Тб. И даже не важно, что их на самом деле нет: он строит планы, как будто они есть.

Соответственно, когда мы тестируем какую-то миграцию, можно собрать все планы — мы увидим, как оно будет происходить на production. Секунды там будут другие (тормознее), но данные, которые мы реально считываем, и сами планы (какие там JOIN'ы и т.п.) получаются точно такими же, как на production. И параллельно можно запускать множество таких проверок на одной машине.

ДС: Ты не считаешь, что здесь есть несколько проблем? Первая — это решение, которое работает только на PostgreSQL. Такой подход — очень частный, он не generic. Вторая — Kubernetes (и всё, куда сейчас идут облачные технологии) предполагает множество узлов, и эти узлы — эфемерные. А в твоём случае это stateful, персистентный узел. Эти вещи у меня вызывают противоречия.

НС: Первое — согласен, это чисто Postgres'овая история. Думаю, если у нас есть какой-нибудь direct IO и буферный пул почти под всю память, такой подход не подойдет — планы будут другие. Но мы пока только с Postgres'ом и работаем, про других не думаем.

Про Kubernetes. Ты же сам везде рассказываешь, что у нас база персистентная. Если инстанс упал, главное — сохранить диск. Вот у нас тоже вся платформа в Kubernetes, а компонент с Postgres — отдельно (хотя и он там однажды будет). Поэтому всё так: инстанс упал, но мы сохранили его PV и просто подключили к другому (новому) инстансу, как будто бы ничего не случилось.

ДС: С моей точки зрения, мы создаём pod'ы в Kubernetes. K8s — эластичный: узлы заказываются сами по мере необходимости. Задача — просто создать pod и сказать, что ему нужно X ресурсов, а дальше K8s сам разберётся. Но поддержка хранилищ в Kubernetes по-прежнему нестабильна: в 1.16, в 1.17 (этот релиз вышел недели назад) эти фичи становятся только бетой.

Пройдет полгода-год — оно станет более-менее стабильным, или хотя бы будет заявлено таковым. Тогда возможность снапшотов и resize'а уже решает вашу задачу полностью. Потому что у вас есть база. Да, она может быть не очень быстрой, но скорость зависит от того, что «под капотом», потому что некоторые реализации умеют копирование и copy-on-write на уровне дисковой подсистемы.

НС: Тут же надо ещё, чтобы все движки (Amazon, Google…) успели начать поддерживать эту версию — это ведь тоже какое-то время занимает.

ДС: Пока мы их не используем. Мы используем своё.

Локальная разработка под Kubernetes

НС: Сталкивался ли ты с такой хотелкой, когда нужно на одной машине поднять все pod'ы и сделать такое маленькое тестирование. Чтобы по-быстрому получить proof of concept, посмотреть, что приложение работает в Kubernetes, не выделяя под это кучу машин. Есть Minikube, да?

ДС: Мне кажется, этот кейс — на одном узле развернуть — про локальную разработку исключительно. Или какие-то проявления такого паттерна. Есть Minikube, есть k3s, KIND. Мы идём к тому, что будем Kubernetes IN Docker использовать. Сейчас начали с ним работать для тестов.

НС: Я раньше думал, что это попытка завернуть все pod'ы в один Docker-образ. Но оказалось, что это совсем о другом. Всё равно там отдельные контейнеры, отдельные pod'ы — просто в Docker'е.

ДС: Да. И там достаточно забавная имитация сделана, но смысл такой… У нас есть утилита для деплоя — werf. Мы хотим в ней сделать режим ­— условно werf up: «Подними мне локальный Kubernetes». И далее запустить там условный werf follow. Тогда разработчик сможет править в IDE, а в системе запущен процесс, который видит изменения и пересобирает образы, передеплоивает их в локальный K8s. Так мы хотим попытаться решить проблему локальной разработки.

Снапшоты и клонирование БД в реалиях K8s

НС: Если вернуться к copy-on-write. Я заметил, что у облаков тоже есть снапшоты. Они работают по-разному. Например, в GCP: у тебя на восточном побережье США есть многотерабайтный инстанс. Делаешь периодически снапшоты. Поднимаешь из снапшота копию диска на западном побережье — через несколько минут уже всё готово, работает очень быстро, только кэш надо заполнить в памяти. Но эти клоны (снапшоты) — для того, чтобы за'provision'ить новый том. Это круто, когда нужно много инстансов создать.

А вот для тестов, мне кажется, снапшоты, про которые ты рассказываешь в Docker'е или я рассказываю в ZFS, btrfs и даже LVM… — они позволяют как раз на одной машине не делать реально новые данные. В облаке ты ещё платить за них каждый раз будешь и ждать уже не секунды, а минуты (а в случае lazy load'а, возможно, и часы).

Вместо этого можно за секунду-две получить эти данные, погонять тест и выбросить. Эти снапшоты решают разные задачи. В первом случае — чтобы отмасштабироваться и новые реплики получить, а во втором — для тестов.

ДС: Не соглашусь. Сделать нормально клонирование томов — это задача облака. Я не смотрел их реализацию, но знаю, как это делаем мы на железе. У нас есть Ceph, в нём можно любому физическому тому (RBD) сказать clone и получить за десятки миллисекунд второй том с такими же характеристиками, IOPS'ами и т.п. Надо понимать, что там внутри хитрый copy-on-write. Почему облаку не делать так же? Уверен, что они так или иначе стараются это сделать.

НС: Но у них всё равно уйдут секунды, десятки секунд, чтобы поднять инстанс, привести туда Docker и т.д.

ДС: Почему обязательно целый инстанс поднимать? У нас же есть инстанс на 32 ядра, на 16… и в него сколько-то влезает — например, четыре. Когда мы пятый заказываем, уже поднимется инстанс, а потом он удалится.

НС: Да, интересно, в Kubernetes получается другая история. У нас БД не в K8s, и один инстанс. Зато на клонирование многотерабайтной базы уходит не более двух секунд.

ДС: Это круто. Но мой изначальный посыл в том, что это не generic-решение. Да, оно классное, но подходит только Postgres и только на одном узле.

НС: Оно подходит не только для Postgres: это планы, как я описывал, будут так работать только в нём. Но если не заморачиваться по поводу планов, а нам просто нужны все данные для функционального тестирования, тогда это подойдет для любой СУБД.

ДС: Много лет назад мы делали подобное на LVM-снапшотах. Это классика. Такой подход очень активно использовался. Просто stateful-узлы — это боль. Потому что их нужно не ронять, всегда о них помнить…

НС: Не видишь ли ты здесь какой-то возможности гибрида? Допустим, stateful — это pod какой-то, он работает на нескольких людей (много тестировщиков). Том у нас один, но благодаря файловой системе клоны — локальные. Если pod упал, диск остался — поднимется pod, информацию обо всех клонах считает, всё обратно поднимет и скажет: «Вот ваши клоны на этих портах запущены, работайте с ними дальше».

ДС: Технически это означает, что в рамках Kubernetes это один pod, внутри которого мы запускаем много Postgres'ов.

НС: Да. У него есть лимит: допустим, одновременно с ним работают не более 10 человек. Если нужно 20 — запустим второй такой pod. Полностью реально склонируем его, получив второй полный том, на нём будут такие же 10 «тонких» клонов. Не видишь такой возможности?

ДС: Надо добавить сюда вопросы безопасности. Такой вариант организации подразумевает, что у этого pod'а высокие привилегии (capabilities), потому что он может выполнять нестандартные операции над файловой системой… Но повторюсь: я считаю, что в среднесрочной перспективе в Kubernetes починят storage, в облаках починят всю историю с томами ­— всё будет «просто работать». Будет resize, клонирование… Есть том — мы говорим: «Создай новый на основе того», — и через полторы секунды получаем что надо.

НС: Не верю в полторы секунды для многих терабайт. На Ceph ты делаешь сам, а говоришь про облака. Пойди в облако, на EC2 сделай клон тома EBS многих терабайт и посмотри, какая производительность будет. Это не займет несколько секунд. Мне очень интересно, когда они дойдут до такого показателя. Понимаю, о чем ты говоришь, но позволю себе не согласиться.

ДС: Ок, но я сказал, что в среднесрочной перспективе, не краткосрочной. В течение нескольких лет.

Про оператор для PostgreSQL от Zalando

В середине этой встречи к ней также подключился Алексей Клюкин, бывший разработчик из компании Zalando, который рассказал про историю оператора PostgreSQL:

Здорово, что вообще эта тема затронута: и Postgres, и Kubernetes. Когда мы начинали её делать в Zalando в 2017-м году, это была такая тема, которой все хотели заниматься, но никто не делал. У всех уже появлялся Kubernetes, но когда спрашивали, как быть с базами данных, то даже такие люди, как Kelsey Hightower, проповедовавшие K8s, говорили примерно следующее:

«Идите в managed-сервисы и используйте их, не запускайте БД в Kubernetes. Иначе ваш K8s решит, например, сделать апгрейд, потушит все узлы, и ваши данные улетят далеко-далеко».

Мы решили сделать оператор, который будет, вопреки этому совету, запускать БД Postgres в Kubernetes. И у нас было хорошее основание — Patroni. Это автоматический failover для PostgreSQL, сделанный правильно, т.е. использующий etcd, consul или ZooKeeper в качестве хранилища информации о кластере. Такого хранилища, которое будет отдавать всем, кто спрашивает, например, какой сейчас лидер, одну и ту же информацию — несмотря на то, что у нас всё распределённое, — чтобы не было split brain'а. Плюс, у нас был Docker-образ для него.

Вообще, потребность в auto failover у компании появилась после миграции из внутреннего железного дата-центра в облако. Облако было основано на собственном решении PaaS (Platform-as-a-Service). Оно Open Source'ное, но чтобы его поднять, надо было сильно потрудиться. Называлось STUPS.

Изначально никакого Kubernetes'а не было. Точнее, когда разворачивалось собственное решение, K8s уже был, но настолько сырым, что для production не годился. Это был, по-моему, 2015 или 2016 год. К 2017-му году Kubernetes стал более-менее зрелым — появилась необходимость миграции туда.

И у нас уже был Docker-контейнер. Была PaaS, которая использовала Docker. Почему бы не попробовать K8s? Почему бы не написать свой оператор? Мурат Кабилов, который пришел к нам из Авито, начал это как проект по собственной инициативе — «поиграть», — и проект «взлетел».

Но вообще я хотел рассказать про AWS. Почему там был исторически код, связанный с AWS…

Когда вы запускаете что-либо в Kubernetes, надо понимать, что K8s — это такой work in progress. Он постоянно развивается, улучшается и периодически даже ломается. Нужно следить внимательно за всеми изменениями в Kubernetes, нужно быть готовым в случае чего погрузиться в него и узнать, как работает в деталях — возможно, больше, чем вам бы хотелось. Это, в принципе, у любой платформы, на которой вы запускаете свои БД…

Итак, когда мы делали оператор, у нас был Postgres, который работал с внешним томом (в данном случае — EBS, поскольку мы работали в AWS). База данных росла, в какой-то момент потребовалось сделать resize: например, изначальный размер EBS — 100 Тб, база доросла до него, теперь хотим сделать EBS в 200 Тб. Как? Допустим, можно сделать dump/restore на новый инстанс, но это долго и с простоем.

Поэтому хотелось такой resize, который будет увеличивать раздел EBS'а и потом говорить файловой системе системе использовать новое пространство. И мы это сделали, но в то время у Kubernetes'а не было никакого API для операции resize'а. Поскольку мы работали на AWS, написали код для его API.

Никто не мешает сделать то же самое для других платформ. В операторе нет завязки, что его можно запустить только на AWS, а на всём остальном он работать не будет. В общем, это Open Source-проект: если кто-нибудь хочет ускорить появление использования нового API — милости просим. Есть GitHub, pull-запросы — команда Zalando старается довольно оперативно на них реагировать и продвигать оператор. Насколько знаю, проект участвовал в Google Summer of Code и каких-то других похожих инициативах. Zalando над ним очень активно работает.

P.S. Бонус!

Если вас интересует тема PostgreSQL и Kubernetes, то обращаем также внимание, что на прошлой неделе состоялся следующий Postgres-вторник, где с Николаем общался Александр Кукушкин из Zalando. Видео с него доступно здесь.

P.P.S.

Читайте также в нашем блоге:

• «Базы данных и Kubernetes (обзор и видео доклада)»;
• «Миграция Cassandra в Kubernetes: особенности и решения»;
• «Беспростойная миграция MongoDB в Kubernetes»;
• «Беспростойная миграция RabbitMQ в Kubernetes».