Продублирую тут для истории.
https://docs.percona.com/percona-monitoring-and-management/2/index.html
Всё же опишу наши боли про pmm и k8s.
Хоть и не пятница, но настрочу, настало время всратых стори.
Представьте себе такую ситуацию: у вас десяток кластеров Kubernetes, а в моем случае их ещё больше. В каждом из них несколько баз данных, которые разворачиваются с помощью оператора. У каждой базы данных есть свой FQDN, доступный только в приватной сети. Креденшалы хранятся в секретах, как всегда. Пока всё хорошо, как и у всех.
Теперь, мы хотим всё это мониторить и находим супер продукт - Percona PMM.
Потыкали мышкой, и кажется, что это то, что надо. Ну наконец-то, идеальное решение!
Далее, ставим PMM сервер в кластер, используя чарт, Terraform, Helm или Argo - выбирайте по вкусу
Затем нужно зарегистрировать базы данных через PMM клиент на PMM сервере. И тут перед нами два "великолепных" варианта:
- натыркать всё мышкой в UI.🤡
- поднять деплоймент для каждого агента через GitOps или другой любимый инструмент.
Оба варианта, конечно, идеально подходят для динамически меняющихся баз данных в кубере.
Думаем: «Ну ок, наверняка ребята из Перконы сделали автодискавери». И тут сюрприз!
Автодискавери и авторегистрации нет - ни по лейблу, ни по какому-либо другому признаку.
Решаем поднять сайдкар (через оператора), который будет регистрировать базу каждый раз, когда она добавляется, и при этом работает для существующих баз данных. Кажется, отличная идея. Создаём сайдкар, который говорит PMM серверу подключаться к БД через FQDN.
В итоге видим в админке PMM сервера попытку регистрации, но вместо FQDN клиент видит внутренний IP адрес в Kubernetes. 🤡
И регистрация не проходит.
Оказывается, проблема в gRPC и ингрессе(на двух контроллерах).
Какая-то бага, что в чарте, что без него (issue не открывали, лень, признаю, не прав).
Стоит заменить внешний адрес на адрес service - проблема с регистрацией уходит. То есть рега в кубере работает только с k8s service.
Это не очень удобно, так как визуально название в UI сервера будет некрасивым и многие девелоперы, кто подключатся к pmm не сразу матчат свою бд с не очень семантическим названием сервиса.
Это не самая большая проблема, можно закрыть глаза.
Если у вас нетворк полиси, запрещающий обращение к сервисами в других неймспейсах, то у вас новые проблемы(БД то в разных ns).
Стоит ли говорить про удобство, когда вы хотите один PMM сервер на сразу несколько кластеров из БД в разных неймспейсах, а не pmm на каждый из кластеров и решение через регистрацию по имени сервиса это не очень ок.
Так же остаётся проблема с самим IP. Адрес может поменяться быстрее, чем @gecube триггерится на сообщения в чате с кодом без бектиков.
И мониторинг накрывается женским половым органом, бежишь как сельский дурачок вручную делаешь перерегистрацию.
И ещё 2-3 бага в подарок нашли, но, справедливости ради. это не связано напрямую с кубером.
workaround solution - либо пилить своего оператора, который будет следить за svc и по лейблам добавлять авто регистрацию, авто обновление по IP и авто удаление БД, либо пока не переходить на PMM мониторинг в кластерах Kubernetes, либо, как мы, спиздить борды у PMM и перетащить их в свою графану, немного допилив и адаптировав. Так же надо научить сервис скрейпер/прометеус забирать метрики не только постгри, но ещё и патрони(в случае с постгрей). С кластерами mysql там вообще
Вывод: хочешь мониторить базы данных в Kubernetes с помощью Percona PMM? - готовьтесь к захватывающим приключениям и тратой времени по трекеру на таски с этим.
Или просто подождите, пока ребята из Перконы наконец-то добавят нужный функционал для вообще самой концепции "много бд, всё в кубере, много кластеров, хотим один пмм сервер".
Хочу отметить, что сам пмм мне нравится, он хорошо подходит для статик бд, например в ажуре или амазоне, но для БД с операторами в кубах - никак пока что.
#pmm #kubernetes