Pull to refresh

Comments 21

Слушал вас лично в Ульяновске — очень понравилось. Крайне полезный доклад в качестве просветления мозгов на тему того, как работает планировщик в линуксе (а значит и в докере), и что же значат эти request и limits. Рекомендую :-D

Для расчёта остальных значений (burstable) есть формула, суть которой сводится к тому, что чем больше pod запросил ресурсов, тем меньше шансов, что его убьют.

Это только для меня звучит как минимум странно? Я думаю, что стоит дать комментарий почему так, а не наоборот — и к каким эффектам это может приводить

Здесь нет ничего странного. В requests мы резервируем больше места для пода. А значит, он имеет большую приоритет на жизнь, чем остальные контейнеры/процессы на хосте.
А значит, он имеет большую приоритет на жизнь, чем остальные контейнеры/процессы на хосте.

Объяснили так объяснили. :-( Жизненный опыт говорит, что все ровно наоборот должно быть, ну, да ладно.

Начнём с начала.
Перед запуском контейнеров в поде на ноде, под должен пройти через планировщик kube-scheduler. Он учитывает много вещей, включая requests по CPU и Memory. Чем больше запросы у пода, тем тяжелее подобрать для него машину со свободными ресурсами. Но когда она подобрана и под выехал, то ему назначается более высокий QoS класс, чем остальным. И приоритет на жизнь у него гораздо выше, чем у остальных. Потому что мы заранее обозначили его класс и подобрали большую и свободную ноду для него.

т.е. это не особенность цгрупп, а именно настройки, которые выставляются kube-scheduler.
Да, спасибо, так яснее.

Настройки CPU shares и oom_score_adj проставляет kubelet, если конкретно. Я попытался (как смог) более общую картину нарисовать.
Хорошо написано, понятно. А вот вопрос — можете привести реальные сценарии из реальной жизни, где нужно было задействовать автомасштабирование?
Облачный провайдер, у клиента непредсказуемая нагрузка в течение дня. Распродажа или livestream. Просто подключаем HPA и смотрим, как вся нагрузка аккуратно съедается.

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

Я бы сказал — не удобнее, а безопасными. А то автоскейлинг поставишь и он на все деньги понасоздает виртуалок. Во будет весело, да?

Нет не будет, автоскейл нод ограничен вашими предпочтениями и довольно гибко настраивается почти всегда. Не уверен даже, что у какого либо уважающего себя клауд-провайдера, есть опция в стиле «а пофиг, давай гульнем на все!», которая бы разрешила безгранично делать скейл-ап.
Выглядит как гипотетичный случай. Пусть так, но хотелось бы конкретики. Какие типы контейнеров (с каким ПО) есть в кластере, и какой конкретно тип будет масштабироваться? Что-то кеширующее?

Вы имеете в виду, что если речь про обработку HTTP запросов (ну, условный фласк или джанга), то все равно рано или поздно упрешься в БД, в которую этот бекенд будет ходить? И тогда нужно автоскейлить не один сервис, а их ансамбль?

Да, как-то так. Со статическим контентом смысл масштабирования понятен, но когда речь про чтение из БД — все не так очевидно.

Машстабирование серверов БД — задача не простая и не быстрая. В моем ограниченном понимании, конечно.

Не совсем по теме вопрос, но уже дней из головы не лезет.


Предположим есть две ноды и на них по поду с web сервером.
Соответственно, папка с общим (динамическим) контентом примаунчена. Как лучше всего сделать общую папку.
На ум приходит синхронизация локальных папок на нодах (например lsyncом), но неохото самому изобретать велосипедные скрипты.
Можно маунтить как nfs шару, но тогда скорость передачи данных не самая лучшая.
Есть вариант с распределенными фс типа ceph, но тогда затраты на инфраструктуру не оставляют ресурсов для самого приложения (в моем случае)
Ну и можно, конечно, следить чтобы все поды создавались на одной ноде с локальной папкой с контентом, но это совсем некрасиво и не по-кластерному.


Сейчас думаю делать через nfs, но может есть более изящные решения?

У коллег спросил советов, на поверхность самый лучший вариант всплыл. Хранить в S3 или другом object storage, который у вашего хостера имеется! Сразу ото всех проблем избавитесь.

поддержу. Причем для нас это решение лежит на поверхности. НО! Если разворачивать С3 самому, то это все равно нужно выделенные ноды и преимущество относительно какого-нибудь Цеф на тех же отдельных нодах становится не таким очевидным.

Спасибо за совет.
Ох если бы был доступ к AWS, то там есть с чем развернуться. И S3 и, даже лучше, EBS подмаунтить, там в (поза?)прошлом года запустили новый тип с возможностью доступа с нескольких инстансов.


Но весь проект на своем железе в серверной комнате. Поэтому, пока что, без облаков.

О. Интересная штука и поднимается внутри контейнера. Раньше не слышал. Спасибо.


Однако, доступ к информации, все же, осуществляется посредством командной строки, как я понял, что требует либо сильного изменения приложения либо промежуточного сервера/папки со скриптами. В отличие от того же S3, который можно примаунтить как volume к поду.


Пока что nfs самое "дешево и сердито".

Дмитрий, спасибо за интересный материал, но меня удивляет, что Вы совершенно не коснулись собственного механизма вытеснения (Eviction) в Кубере kubernetes.io/docs/tasks/administer-cluster/out-of-resource.

У Кубера есть собственная настройка порога памяти (по умолчанию 100мб), по которому он будет сам выбирать какие поды вытеснять с ноды, и только если этот механизм не отработает и память закончится окончательно, то ядро линукса запустит OOM Killer, который отстрелит поды с самым высоким oom_score_adj.

Итак, у кубера есть два порога: eviction-hard и eviction-soft, в которых можно задать пороги свободной памяти, если её на сервере будет меньше, чем задано, то кубер начнет выселять поды. Разница в том, что soft просит свалить и ждёт некоторое время (тоже задаётся в конфиге), затем убивает, если под не ушёл. А hard убивает сразу. Как кубер выбирает кого выселить? Очень просто — выселяются BestEffort и Burstable поды, которые превышают потребление памяти указаное в request. Чем больше превысил, тем быстрее тебя выселят с ноды.
А OOM Killer похорошему запускаться вообще не должен.

Sign up to leave a comment.