Мы исползовали Pushgateway, когда для мониторинга на платформе стоял Prometheus. С переходом на VictoriaMetrics оставили и pushgateway как альтернативу для короткоживущих метрик.
Добрый день! Сложность перехода - один из ключевых моментов выбора. Мы рассматривали все доступные варианты ОС и по совокупности факторов выбрали наиболее подходящую для наших целей (указали в статье).
"Как балансировщики нагрузок узнают IP пода куда направлять трафик"? - По лейблам
"Более интересен overcommit по памяти. Видел сценарий, когда обычная команда grep убивала все поды на ноде посредством OOM killer. При memory overcommit = 0 такого не происходит". - По памяти: overcommit практически не используем, в редких случаях на тестовых средах это допустимо.
"Уточню по ресурсы подов. Допускаете ли разные request и limits по памяти или по процессору? Видел рекомендации, что по памяти request и limit должны быть одинаковые, а по процессору нужно иметь request (желательно целочисленный),а limit опустить". - Аналогично предыдущему ответу: допускаются все возможные варианты и их комбинации в зависимости от поставленной задачи - надежность vs экономия ресурсов.
"Используете ли Rancher?" - Нет, наша платформа лучше:)
В кластере более 600 нод, они разделены на роли и сконфигурированы под конкретные задачи, например, есть ноды с GPU. У нод до 2Тб оперативной памяти и 256 потоков.
Для мастеров выделено от 3 до 9 нод, при этом часть из их выполняет и другие роли, например, мониторы Ceph. Все ноды имеют как минимум тейнты с ролями сервера.
На больших продакшен кластерах квоты неймспейсов не используем, но надо учесть, что там никто ничего не создает без участия CI/CD пайплайнов, которые предварительно проходят все стадии тестирования на других окружениях.
Подробнее о системах мониторинга и логирования можно почитать в статьях блога dBrain.cloud (тут и тут). У нас есть собственные контроллеры, проставляющие необходимые аннотации в определенные ресурсы, о чем мы также уже рассказывали.
Как правило, для больших кластеров балансировка осуществляется либо через сервисы типа ClusterIP (внутри кластера), либо через LoadBalancer / Ingress для входящего трафика. IP подов используются только для работы механизмов cluster discovery и только в составе headless сервисов. NodePort вообще не используем, т.к. это не очень хорошая практика. Но клиенты при желании могут использовать сервисы типа NodePort.
SWAP везде отключен, overcommit, особенно по CPU, допускается использовать, если пики нагрузки на различные типы микросервисов разнесены во времени.
Что касается рекомендаций: необходимо следить за своим приложением и выставлять согласно результатам нагрузочного тестирования.
Мы смотрели в сторону kine, но есть много нюансов. В общем случае из-за выбора баз получалось медленнее, чем на etcd, а ресурсов при тех же значениях rps потребляется больше. Да и реализовывать key-value логику на реалиционной базе не лучшая затея. Сейчас в разработке решение по типу kine только для redis, но результаты пока что требуют доработок.
Добрый день!
Мы исползовали Pushgateway, когда для мониторинга на платформе стоял Prometheus. С переходом на VictoriaMetrics оставили и pushgateway как альтернативу для короткоживущих метрик.
Добрый день! Мы предоставили наиболее релевантные для нас скриншоты, к сожалению, не имеем возможности показать все нюансы.
Добрый день! Сложность перехода - один из ключевых моментов выбора. Мы рассматривали все доступные варианты ОС и по совокупности факторов выбрали наиболее подходящую для наших целей (указали в статье).
Добрый день! Примеры тестов - это наши наработки, которые в общий доступ мы не даем. Увидеть примеры тестов можно при эксплуатации платформы dBrain.
Спасибо, что вниматели прочитали статью. Уточнили формулировку.
Спасибо!
"Как балансировщики нагрузок узнают IP пода куда направлять трафик"?
- По лейблам
"Более интересен overcommit по памяти. Видел сценарий, когда обычная команда grep убивала все поды на ноде посредством OOM killer. При memory overcommit = 0 такого не происходит".
- По памяти: overcommit практически не используем, в редких случаях на тестовых средах это допустимо.
"Уточню по ресурсы подов. Допускаете ли разные request и limits по памяти или по процессору? Видел рекомендации, что по памяти request и limit должны быть одинаковые, а по процессору нужно иметь request (желательно целочисленный),а limit опустить".
- Аналогично предыдущему ответу: допускаются все возможные варианты и их комбинации в зависимости от поставленной задачи - надежность vs экономия ресурсов.
"Используете ли Rancher?"
- Нет, наша платформа лучше:)
В кластере более 600 нод, они разделены на роли и сконфигурированы под конкретные задачи, например, есть ноды с GPU. У нод до 2Тб оперативной памяти и 256 потоков.
Для мастеров выделено от 3 до 9 нод, при этом часть из их выполняет и другие роли, например, мониторы Ceph. Все ноды имеют как минимум тейнты с ролями сервера.
На больших продакшен кластерах квоты неймспейсов не используем, но надо учесть, что там никто ничего не создает без участия CI/CD пайплайнов, которые предварительно проходят все стадии тестирования на других окружениях.
Подробнее о системах мониторинга и логирования можно почитать в статьях блога dBrain.cloud (тут и тут). У нас есть собственные контроллеры, проставляющие необходимые аннотации в определенные ресурсы, о чем мы также уже рассказывали.
Как правило, для больших кластеров балансировка осуществляется либо через сервисы типа ClusterIP (внутри кластера), либо через LoadBalancer / Ingress для входящего трафика. IP подов используются только для работы механизмов cluster discovery и только в составе headless сервисов. NodePort вообще не используем, т.к. это не очень хорошая практика. Но клиенты при желании могут использовать сервисы типа NodePort.
SWAP везде отключен, overcommit, особенно по CPU, допускается использовать, если пики нагрузки на различные типы микросервисов разнесены во времени.
Что касается рекомендаций: необходимо следить за своим приложением и выставлять согласно результатам нагрузочного тестирования.
Это только пример. Приведенные данные не означают, что мы используем такой объем. Но на их месте могут быть конфигмапы, репликасеты или ивенты.
Мы смотрели в сторону kine, но есть много нюансов. В общем случае из-за выбора баз получалось медленнее, чем на etcd, а ресурсов при тех же значениях rps потребляется больше. Да и реализовывать key-value логику на реалиционной базе не лучшая затея. Сейчас в разработке решение по типу kine только для redis, но результаты пока что требуют доработок.
Спасибо за обратную связь. Вы можете протестировать нашу консоль, отправив заявку на сайте официального дистрибьютора платформы.
Спасибо за обратную связь. Каких деталей не хватило? О чем рассказать в следующих публикациях?
Спасибо, уточнили формулировку.