Прежде всего, мне очень жаль длинное описание моей установки. Но я действительно хочу объяснить причину вопроса.
Построение набора реплик kubernetes mon go db.
На данный момент это N mon go узлов, один из них с более высоким приоритетом, чем другие, имеет мастер.
Каждый узел mon go (член репликации) реализован как StatefulSet с точной репликой 1 в нем. Не планирую делать автоматическое c масштабирование вверх или вниз, потому что я понимаю, что добавление одного узла в набор реплик на самом деле довольно тяжелая операция - mon go должен синхронизировать c все данные в нем, прежде чем он сможет принять некоторую нагрузку. Таким образом, автоматическое масштабирование c при большем спросе теряет весь смысл - поскольку на самом деле оно будет увеличивать нагрузку на существующие узлы, чтобы какое-то время заполнять новые.
Поэтому моя идея состоит в том, чтобы исправить SatefulSets, чтобы я мог контролировать все, что мне нужно, и я всегда могу добавить других, если мне нужно.
Выполнение инициализации репликационного набора вручную путем запуска команды на запущенном модуле pod после его первого запуска. И добавить все члены к нему. Сделать это так же просто, как запустить этот rs.initiate({....})
Все работает отлично, пока kubernetes не решит переместить одного члена из одного узла k8s в другой узел k8s (возможно, потому, что на нем начинают происходить какие-то тяжелые вещи узел kubernetes или по какой-либо другой причине).
После перемещения члена репликации mon go он становится недоступным с точки зрения репликации. Что вполне логично, потому что система k8s снова и снова включала. и mon go удаляет его из реплики.
Чтобы исправить это, я должен перенастроить свой репликационный набор, включив в него элемент реплики back mon go, который был перемещен системой k8s. Это довольно просто rs.reconfig({....}, {force: true}). Но в моем случае это должно было быть выполнено вручную - как только я заметил недоступный элемент mon go. Что совсем не круто.
Так что моя идея заключалась в том, чтобы создать простой модуль k8s mongo replicaset monitoring, который бы запускал rs.status() против mon go replicaset и отслеживал присутствие всех присутствующих. , Или запустите rs.reconfig(...), как только у кого-то закончилась реплика. Также было бы легко добавить некоторые уведомления в этот модуль мониторинга - так что я вижу где-то эхо. Этот модуль, вероятно, будет реализован в виде простого Ubuntu с бесконечным l oop сценарием оболочки с задержкой и python сценарием, который будет выполнять все маги c с mon go и уведомлением.
Не мне действительно нравится идея коляски для каждого мон go, потому что это дополнительный модуль для каждого мон go модуля из того, что я понимаю. Так что иметь один модуль мониторинга звучит намного лучше, чем для меня. кроме того, я использую mon go 3.2, чтобы существующий материал коляски действительно не работал.
и, наконец, мой вопрос - есть ли что-то вроде light mongo monitoring docker image где-то уже существует? не смог найти ничего подобного ...
ОБНОВЛЕНИЕ , так как не было ответов, чтобы создать свой собственный образ для мониторинга - работает просто отлично.