Comments 20
А используя данные утилиты можно развернуть кластер не в k8s, а на простых виртуалках?
Хорошо бы в подробности тестов копнуть.
Мы долгое время сидим на заланде. Клауднатив мне понравился больше: он шустрее, подвижнее, но он хранит мету кластера прям в бд (в public схеме, если память не подводит) и при проблем с ней (рестор всей схемы например) кластер падает. В отличае от заланды, где есть оператор и его манифест. Пришлось научиться лучше готовить заланду.
Год релиза в первых двух заставил задуматься..
Спасибо за интересную статью. Подскажите, попадало ли в поле вашего зрения, такое решение, как https://github.com/bitnami/charts/blob/main/bitnami/postgresql-ha/README.md?ysclid=ltnbyn0d3p506481755 ?
Попадало, но уже когда реализовывали функционал. Поэтому глубоко не исследовали. Думаю, в ближайшее время посмотрим подробнее
Используем сейчас bitnami - в одном из последних релизов сломали настройку wal_level. В ходе поисков решения - нашли что они это делают 3 или 4 раз, меняя способ как оно должно настраиваться, не упоминая это в документации. Жить конечно можно и лечится просто фиксированием версии, но доверие к проекту немного подрывает подход и повторение инцидентов.
А в каких из этих операторах можно устанавливать свой пароль от базы? В столон знаю можно, но он не поддерживается уже долго. В zalando ковырял и не нашел такого, он всегда новый генерит. Нужно для связки с Vault
Спасибо за статью, вдохновили.
Хотел бы поинтересоваться, предоставляете ли вы доступе к БД для приложений вне кластера, если да, то каким образом? Через load balancer?
Очень интересно. Ищу как бы можно было на отдельный нод в кластере повесить базу с прямым доступом по порту без посредников. nodePort не подходит, потому что хочу один и тот же порт использовать для разных кластеров БД.
Вы никак не сможете средствами кубера балансировать на разные кластеры БД с одного порта. Вам нужно либо поставить какой-то пуллер и ему дать порт, либо вешать кластеры на разные порты.
Вот я тоже прихожу к такому выводу. Пока вижу решение так.
Выделить скажем 3 нода под PostgreSQL кластер.
Установить nodeSelector, чтобы выбирал только их.
Пробрасываю 5432 порт через сеть хоста.
Создаю DNS A запись 3 нодами (возможно посредством external-dns).
???
PROFIT
Просто интересно, какого профита вы хотите этим добиться? Постгря такая штука, которая гораздо лучше себя чувствует вне контекста контейнеров. Какая вообще польза от кубера для такого статического деплоя?
У меня более 70 кластеров. Управлять ими через Terraform / Ansible уже изрядно надоело. К тому же хочется чтобы все было декларативно. К тому же кубер даёт удобный интерфейс для просмотра текущего статуса и лёгкий доступ к логам.
Я многие годы был против контейнеров, когда кластеров было менее 10. Сначала перешёл на докер и контейнер. И все работало хорошо. Теперь думаю может пора в кубере опробовать.
Ну т.е. вы собираетесь развернуть кластер более 70 нод и на нём поднимать по контейнеру или как? Допустим вы реализуете через StatefulSet + host network. Какие преимущества поддержки, кроме статуса и логов вы получите?
Есть же гораздо легче варианты вроде Nomad, Docker Swarm, CoreOS, Portainer+Docker. Блин, да всё что угодно подходит на мой взляд гораздо лучше, чем костыляние кубера, который в первую очередь подразумевает работу с эфимерными контейнерами, которые можно легко заскейлить в любой момент. Если говорить за StatefulSet, он там максимально чужеродный, но сделал впервую очередь, чтоб внутри кластера создавать сервисы (ну т.е. вы создаёте БД, сервис с ClusterIP и всякая эфимерщина подключается внутри).
Я не осуждаю - у всех свои экзотические фантазии. Но мне правда интересно, чем лучше такая реализация.
Вот подскажите чем же они легче?
Чтобы сделать автоматическое переключение primary на standby - нужен Patroni, а для него нужен etcd. В том же etcd нужен менеджмент пользователей, мониторинг, бэкапы, обновления.
В том же кубере etcd - уже часть архитекторы k8s.
Ладно, отбросим Patroni. Чтобы сделать хотя бы простенький PostgreSQL кластер, без Terraform / Ansible уже никуда.
Ну для того же кубера без этого не обойтись, но намного проще установка, взять тот же RKE2 от Rancher.
Возьмём вопрос конфигурации. Вот она есть в репозитории, а что сейчас находиться на кластере? То ли это, или кто уже что-то задеплоил, и нужно копать в логах кто там что делал, или лезть на сервер и сравнивать. А тут запилил GitOps репозиторий, и если все зелёное, то значит конфиг в кластере соответсвует коду.
Та же оркестрация обновлений. Оператор все сделает в нужном порядке, а тебе останется откинуться на спинку табуретки и смотреть.
Это я ещё не говорю про бэкапы, восстановление, менеджмент пользователей. Для всего нужно писать скрипты рукам, если хочешь по уму.
Если хотя бы часть этих проблем сможет решить оператор, то почему бы не попробовать?
А какой у вас опыт? Сколько кластеров? Где крутятся, в какой обвязке работают?
В том же кубере etcd - уже часть архитекторы k8s.
И не вздумайте в него лезть напрямую. Это будет большой ошибкой.
Ну для того же кубера без этого не обойтись, но намного проще установка, взять тот же RKE2 от Rancher.
...
Это я ещё не говорю про бэкапы, восстановление, менеджмент пользователей. Для всего нужно писать скрипты рукам, если хочешь по уму.
Вы добавите просто ещё один уровень, а значит требования к поддержке, user management, бэкапам, резервированию, обновлениям...
Если хотя бы часть этих проблем сможет решить оператор, то почему бы не попробовать?
Будет простой обмен одних проблем на другие. Работает этот оператор на тех же принципах, что и Ansible, Terrafrom и т.п. Проблемы там те же.
Ладно, лично я логику понял. Не могу с ней согласиться, но как я уже сказал, это ваш опыт, ваши проблемы.
А какой у вас опыт? Сколько кластеров? Где крутятся, в какой обвязке работают?
Я вынужден работать с кубером с 1.6 версии. Я серёфил на хайпе кубера и openstack'а, потому что работал в консалтинге. При этом мне пришлось написать не один оператор. Поэтому я говорю исходя из опыта работы изнутри (как разработчик операторов) и снаружи (как тот, кто поддерживает кластеры).
К etcd конечно только через k8s API обращаться, это понятно.
По поводу менеджмента пользователей. Для сотрудников у нас Active Directory, и для него у меня в CI есть ежечасная задача, которая синхронизирует пользователей с БД посредством ldap2pg. Вот её можно повесить как cronJob прямо в кластере.
Я понимаю, что кубер операторы это не панацея и что они выполняют те же задачи, только в другой среде, и что одни проблемы заменяются на другие. Хай с ним, я достаточно работал с k8s чтобы уверенно поддерживать кластер.
Вы как-то обошли стороной GitOps, а я считаю, что это очень важный момент при поддержке сложных систем.
Меня больше беспокоит производительность PostgreSQL в контейнере, насколько она разная при прочих равных?
Пользовались ли вы CloudNativePG? Как оно?
Вы как-то обошли стороной GitOps, а я считаю, что это очень важный момент при поддержке сложных систем.
GitOps прекрасно живёт и без куба вместе CI/CD системами. Я не вижу здесь проблемы.
Меня больше беспокоит производительность PostgreSQL в контейнере, насколько она разная при прочих равных?
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Это ключевая проблема производительности. Как ни странно, но для меня это ключевая метрика, потому что напрямую влияет на затраты бизнеса.
Операторы PostgreSQL для Kubernetes. Как мы выбирали идеальный вариант для организации системы DBaaS