какие настроишь у себя - такие и будут

Они автоматом ставятся из хелма kube-prometheus

Ну что нет то, если да, но я не об этом, называйте как хотите, я говорю как есть.

Но есть траблы именно с этими тремя

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

"траблы" undefined

Джобы нигде не фигурируют в гуе прома, называйте их как нравится... В конфиге да есть, но я ориентировался на гую... Не знаешь же кому как понятней

чо, даже в конфиге нет?

Они вообще присутствуют у кого

вопрос-то в чём?

Вопрос к тем кто ставил через хелм, где есть уже набор экспортеров

траблы-то в чём?

ты может спросишь всетаки что тебе нужно? =))

неа

продолбал :)

ну и потому что легаси долбаное

Суть: етсд только через https, соответственно для сбора метрик нужны сертификаты етсд, они есть на мастер ноде в /etc/kubernetes, и для сбора их нужно положить в секрет прома, насколько это правильно вообще, или есть другие варианты для этого?

не гуглил можно ли экспорт метрик вытащить отдельно? размазывать серты по секретам каких то сервисов левых не комильфо

Суть: етсд только через https, соответственно для сбора метрик нужны сертификаты етсд, они есть на мастер ноде в /etc/kubernetes, и для сбора их нужно положить в секрет прома, насколько это правильно вообще, или есть другие варианты для этого?

а в чём проблема-то выдать прометею клиентский серт?

День добрый! Проект kubedb никто не использовал?

но выдаётся он вроде не всем подряд?

Мы его сейчас тотально перепиливаем. В прод тащить крайне не советую. Говорю конкретно про postgresql.

Мы его сейчас тотально перепиливаем. В прод тащить крайне не советую. Говорю конкретно про postgresql.

Вкратце можете рассказать что не так с текущей версией? Какие уроки вынесли

Да, меня тоже немного смутило 9 индусов в разработчиках )) Есть задача предоставить слепок БД из прода в стэйджинг для проверки миграций и всякого такого. С kubedb вроде это решается просто, но есть ощущение что не продакшен реди ))

У нас тоже такая задача есть и концептуально kubedb выглядит достаточно удобно, но нифига это не "production grade" (как гордо написано в ридми)

В чем косячит? И насколько сильно? Вплоть до потери данных?

Косячит при фейловере, потери данных мы на оригинальной версии не раз успешно добивались. Я щас накатаю пост подробный.

Там ещё есть --listen-metrics-urls если там другой порт указать может и не будет входящей аутентификации

1) https://github.com/kubedb/project/issues/330 эту багу мы нашли за месяц до создания этого issue где-то через полчаса тестирования. Там сочетание несколько оптимистичного восприятия гарантий, которые дает функционал выбора лидера в client-go и кучи башнянки, которая запихивается в образ, дергается из обвязки на go и имеет свойство ни на что не реагировать. Повторный перезапуск всего, кстати, при отсутствии в объявлении postgres-кластера источников для восстановления из бэкапа с высокой долей вероятности приведет к снова рабочей схеме "мастер + слейвы", но с идеально пустыми базами. Мы решили это радикально, переписав башнянку на го с использованием контекстов для своевременной отмены одного сценария, чтобы начать другой и вынесли логику из коллбэков лидер-электора в отдельный event loop, а коллбэки теперь просто отсылают сообщения в каналы. 2) Не умеет в pg_rewind, поэтому бывший мастер восстанавливается из бэкапа полностью 3) Не хватает альтернативы proxy из stolon, там просто перевешиваются лейблы на поды при смене лидера, но kube-proxy соединения-то не рвет. 4) С точки зрения кодовой базы: отвратительное управление зависимостями через glide с кучей форкнутых апстримовых либ, включая kubernetes/apiserver(!) c пустячными изменениями типа "а вот тут побольше логов, пожалуйста", которые в большинстве своем находятся в github.com/kmodules, но импортятся через kmodules.xyz/<package_name>, для чего используется алиасомагия glide'а. Зачем - непонятно. Плюс еще куча подобных подвохов. Теперь мы мучаемся, отдирая все это гвоздодером. 5) Никаких апгрейдов постгреса на новую мажорную версию, да

1) https://github.com/kubedb/project/issues/330 эту багу мы нашли за месяц до создания этого issue где-то через полчаса тестирования. Там сочетание несколько оптимистичного восприятия гарантий, которые дает функционал выбора лидера в client-go и кучи башнянки, которая запихивается в образ, дергается из обвязки на go и имеет свойство ни на что не реагировать. Повторный перезапуск всего, кстати, при отсутствии в объявлении postgres-кластера источников для восстановления из бэкапа с высокой долей вероятности приведет к снова рабочей схеме "мастер + слейвы", но с идеально пустыми базами. Мы решили это радикально, переписав башнянку на го с использованием контекстов для своевременной отмены одного сценария, чтобы начать другой и вынесли логику из коллбэков лидер-электора в отдельный event loop, а коллбэки теперь просто отсылают сообщения в каналы. 2) Не умеет в pg_rewind, поэтому бывший мастер восстанавливается из бэкапа полностью 3) Не хватает альтернативы proxy из stolon, там просто перевешиваются лейблы на поды при смене лидера, но kube-proxy соединения-то не рвет. 4) С точки зрения кодовой базы: отвратительное управление зависимостями через glide с кучей форкнутых апстримовых либ, включая kubernetes/apiserver(!) c пустячными изменениями типа "а вот тут побольше логов, пожалуйста", которые в большинстве своем находятся в github.com/kmodules, но импортятся через kmodules.xyz/<package_name>, для чего используется алиасомагия glide'а. Зачем - непонятно. Плюс еще куча подобных подвохов. Теперь мы мучаемся, отдирая все это гвоздодером. 5) Никаких апгрейдов постгреса на новую мажорную версию, да

Блин, и как, надо его заставить отдать метрики без https

1) https://github.com/kubedb/project/issues/330 эту багу мы нашли за месяц до создания этого issue где-то через полчаса тестирования. Там сочетание несколько оптимистичного восприятия гарантий, которые дает функционал выбора лидера в client-go и кучи башнянки, которая запихивается в образ, дергается из обвязки на go и имеет свойство ни на что не реагировать. Повторный перезапуск всего, кстати, при отсутствии в объявлении postgres-кластера источников для восстановления из бэкапа с высокой долей вероятности приведет к снова рабочей схеме "мастер + слейвы", но с идеально пустыми базами. Мы решили это радикально, переписав башнянку на го с использованием контекстов для своевременной отмены одного сценария, чтобы начать другой и вынесли логику из коллбэков лидер-электора в отдельный event loop, а коллбэки теперь просто отсылают сообщения в каналы. 2) Не умеет в pg_rewind, поэтому бывший мастер восстанавливается из бэкапа полностью 3) Не хватает альтернативы proxy из stolon, там просто перевешиваются лейблы на поды при смене лидера, но kube-proxy соединения-то не рвет. 4) С точки зрения кодовой базы: отвратительное управление зависимостями через glide с кучей форкнутых апстримовых либ, включая kubernetes/apiserver(!) c пустячными изменениями типа "а вот тут побольше логов, пожалуйста", которые в большинстве своем находятся в github.com/kmodules, но импортятся через kmodules.xyz/<package_name>, для чего используется алиасомагия glide'а. Зачем - непонятно. Плюс еще куча подобных подвохов. Теперь мы мучаемся, отдирая все это гвоздодером. 5) Никаких апгрейдов постгреса на новую мажорную версию, да

Индусокод )) Форкать apiserver это сильно. Выглядит, действительно, таким образом, что лучше переписать, чем победить ) Спасибо за информацию, она помогла сэкономить кучу времени

А у тебя задача девелоперам стейджинг замутить, я так понимаю?

Да, есть такое. Пока что это обеспечивается башем, через пайплайн, но надо что то поэлегантней.

А каков размер базы?

Не я лично делал но мы вроде настроили етсд экспортер, в который можно серт подложить или запустить на мастерах, а етцд запустить неаутенц интерфейс на локалхосте

Проект новый, база маленькая. Что то в районе 150 Мб. Пока не сильно паримся и делаем pg_dump | pg_restore

Я бы замутил бэкап с wal-g, а в кубенях бы использовал стейтфулсет с постгресом и инит-контейнером, который бы дергал у wal-g backup-fetch и менял бы что-нибудь в базе, если это нужно.

Концептуально, это вполне прокатит. Однако, было бы крайне удобно юзать CRD и оператор и прям в проекте указывать, что при развертывании в стэйдже дать данные с прода )

https://metacontroller.app

Переносим все все базы в кубер. production ready

Все спасибо победил, но у меня была версия etcd 3.2.24, в которой не было ещё такого, вот обновил его и все завелось)

Да, есть такое. Пока что это обеспечивается башем, через пайплайн, но надо что то поэлегантней.

Ребят Подскажите может у кого то есть под рукой, мини сервис для тестов реплики k8s, которая при курле опеределенного порта отдавала информацию о поде или ноде ?

Зачем? Баш работает при том в кластере никаких живых процессов которые могут сойти с ума и все поломать

Ну типа берем, пихаем в проект yaml, который через helm скармливаем k8s, и уже готовая БД для стэйджа. Декаларативность и все, что мы любим в k8s ))

он же закрыт аутенцификацией

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