Comments 21
Слушал вас лично в Ульяновске — очень понравилось. Крайне полезный доклад в качестве просветления мозгов на тему того, как работает планировщик в линуксе (а значит и в докере), и что же значат эти request и limits. Рекомендую :-D
Для расчёта остальных значений (burstable) есть формула, суть которой сводится к тому, что чем больше pod запросил ресурсов, тем меньше шансов, что его убьют.
Это только для меня звучит как минимум странно? Я думаю, что стоит дать комментарий почему так, а не наоборот — и к каким эффектам это может приводить
А значит, он имеет большую приоритет на жизнь, чем остальные контейнеры/процессы на хосте.
Объяснили так объяснили. :-( Жизненный опыт говорит, что все ровно наоборот должно быть, ну, да ладно.
Перед запуском контейнеров в поде на ноде, под должен пройти через планировщик kube-scheduler. Он учитывает много вещей, включая requests по CPU и Memory. Чем больше запросы у пода, тем тяжелее подобрать для него машину со свободными ресурсами. Но когда она подобрана и под выехал, то ему назначается более высокий QoS класс, чем остальным. И приоритет на жизнь у него гораздо выше, чем у остальных. Потому что мы заранее обозначили его класс и подобрали большую и свободную ноду для него.
В реальной жизни она везде не помешает. Вопрос лишь в том, как сделать системы автомасштабирования удобнее, более интегрированными в нашу работу.
Я бы сказал — не удобнее, а безопасными. А то автоскейлинг поставишь и он на все деньги понасоздает виртуалок. Во будет весело, да?
Не совсем по теме вопрос, но уже дней из головы не лезет.
Предположим есть две ноды и на них по поду с web сервером.
Соответственно, папка с общим (динамическим) контентом примаунчена. Как лучше всего сделать общую папку.
На ум приходит синхронизация локальных папок на нодах (например lsyncом), но неохото самому изобретать велосипедные скрипты.
Можно маунтить как nfs шару, но тогда скорость передачи данных не самая лучшая.
Есть вариант с распределенными фс типа ceph, но тогда затраты на инфраструктуру не оставляют ресурсов для самого приложения (в моем случае)
Ну и можно, конечно, следить чтобы все поды создавались на одной ноде с локальной папкой с контентом, но это совсем некрасиво и не по-кластерному.
Сейчас думаю делать через nfs, но может есть более изящные решения?
поддержу. Причем для нас это решение лежит на поверхности. НО! Если разворачивать С3 самому, то это все равно нужно выделенные ноды и преимущество относительно какого-нибудь Цеф на тех же отдельных нодах становится не таким очевидным.
Спасибо за совет.
Ох если бы был доступ к AWS, то там есть с чем развернуться. И S3 и, даже лучше, EBS подмаунтить, там в (поза?)прошлом года запустили новый тип с возможностью доступа с нескольких инстансов.
Но весь проект на своем железе в серверной комнате. Поэтому, пока что, без облаков.
Minio!
О. Интересная штука и поднимается внутри контейнера. Раньше не слышал. Спасибо.
Однако, доступ к информации, все же, осуществляется посредством командной строки, как я понял, что требует либо сильного изменения приложения либо промежуточного сервера/папки со скриптами. В отличие от того же S3, который можно примаунтить как volume к поду.
Пока что nfs самое "дешево и сердито".
У Кубера есть собственная настройка порога памяти (по умолчанию 100мб), по которому он будет сам выбирать какие поды вытеснять с ноды, и только если этот механизм не отработает и память закончится окончательно, то ядро линукса запустит OOM Killer, который отстрелит поды с самым высоким oom_score_adj.
Итак, у кубера есть два порога: eviction-hard и eviction-soft, в которых можно задать пороги свободной памяти, если её на сервере будет меньше, чем задано, то кубер начнет выселять поды. Разница в том, что soft просит свалить и ждёт некоторое время (тоже задаётся в конфиге), затем убивает, если под не ушёл. А hard убивает сразу. Как кубер выбирает кого выселить? Очень просто — выселяются BestEffort и Burstable поды, которые превышают потребление памяти указаное в request. Чем больше превысил, тем быстрее тебя выселят с ноды.
А OOM Killer похорошему запускаться вообще не должен.
Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)