Главная рекомендация - отказаться от лимитов!
А теперь подробнее.
Когда у вас много пользователей используют один кластер Kubernetes, возникает вопрос - как задать квоты, чтобы и приложениям хватало ресурса, и не случилось ситуации, когда из-за одного прожорливого соседа страдают все поды на ноде?
Начну с того, что самым распространенным способом является задание request и limit по CPU и RAM. С оперативной памятью все достаточно просто - при превышении потребления, OMM-Killer остановит процесс. А вот с CPU есть целый ряд нюансов и возможностей наступить на грабли.
Это происходит из-за того, что ресурс процессора делится не долями, а по времени.
Это можно представить так
Kubernetes использует ядро Linux, и если у вас лимит равен 0,4 CPU (400 m) и в ноде 1 ядро, то каждые 100 мл.сек (0,1 сек) на решение ваших задач система выделит 40 мл.сек. Если вашему приложению нужно больше тактов вычислений, то когда закончится выделенная квота, будет троттлинг (пропуск тактов процессора). Важно отметить, что пару лет назад ситуация была хуже, но ряд фиксов ядра Linux существенно улучшили ситуацию. При этом проблема все равно осталась.
Проблема в том, что если ресурса не хватает, то приложению придется ждать начала следующей эпохи (100 мл. сек) чтобы завершить вычисление.
Но редко когда в ноде по 1 vCPU. Что будет, если ядер - 4?
Тогда при лимите в 400m(0,4 vCPU) будет представлена квота всего по 10 мл.сек на ядро. Но в совокупности - 40 мл.сек.
Примечательно, что чем больше ядер в ноде, тем хуже будет становиться ситуация. Детальный эксперимент по деградации отклика приложения при увеличении мощности подробно описан в данной статье.
Приведем лишь одну таблицу, согласно которой увеличение количества ядер в 48 раз дало ухудшение работы в 95 процентиле в 10 раз.
И подобная деградация приводит к увеличению времени отклика приложения, потере сетевой связности и другим неприятным явлениям.
Самое неприятное то, что проблема “скрыта”. У вас нода по мониторингу стоит почти “пустая”, при этом приложения тормозят.
Возможные решения
Отказаться от лимитов.
Самым напрашивающимся решением является ручной подбор оптимального значения лимитов. Но давайте будем честны, предсказать будущее даже для стабильных нагрузок проблематично. А если даже мы можем это сделать руками, то встает вопрос - а нужен ли нам Kubernetes?
Более продвинутой альтернативой является использование динамического выделения ресурсов при фиксировании троттлинга. Но, во-первых, это сложно, во-вторых, это требует перезагрузки подов, что не всегда приемлемо.
При этом вы можете использовать только Request, отказавшись от Limit. Request отвечает за планирование Kubernetes подов на ноды. А именно, вне зависимости от фактического потребления (даже если его почти нет), если реквестами занято 100% CPU, новые поды на данную ноду планироваться не будут.
Но нас интересует другая особенность. При отсутствии лимитов, в случае конкуренции за ресурс, Kubernetes будет учитывать доли реквестов конкретных подов относительно всех подов, для выделения им вычислительного ресурса. Конечно, это не гарантирует, что не случится ситуации с процессорным голоданием, но в большинстве случаев может существенно улучшить производительность.
Подробнее это описано в документации kubernetes по ссылке.
Но прежде чем бить тревогу, лучше понять - есть ли у вас данная проблема.
Измерить троттлинг можно используя следующую команду
cat /sys/fs/cgroup/cpu/cpu.stat
В работе Amvera Cloud, облака для развертывания IT-приложений через push в Git, мы столкнулись с данной проблемой. Она приводила к эпизодическим затруднениям, которые проявлялись либо как проблемы сети для некоторых проектов, либо как замедленная работа приложений. Для ее решения мы отказались от лимитов там, где это можно (но не везде), а в остальных случаях решаем задачу комбинацией автоскейлинга, мониторинга и ручного администрирования.
Об Amvera
Если у вас несколько микросервисов и вы не хотите тратить время на настройку CI/CD, мониторинга и эксплуатации Kubernetes, попробуйте наше облако - Amvera Cloud. Amvera — альтернатива managed Kubernetes. У нас вы сможете обновлять ваши сервисы через простые коммиты в Git и получите почти все преимущества Kubernetes, не задумываясь об администрировании, настройки CI/CD, мониторинга, алертинга и сопутствующих сервисов. Это выйдет намного дешевле, чем классический managed k8s. Kubernetes у нас внутри, но вы полностью абстрагированы от его администрирования, достаточно просто привязать к сервису ваш Git-репозиторий и обновлять приложения командой “git push amvera master”.
А если у вас сложный проект и вам нужна помощь в построении инфраструктуры на основе Kubernetes, или просто консультация, пишите мне в телеграм (Кирилл Косолапов), либо оставьте контакт для связи на странице нашей DevOps-команды. За спрос денег не берем, если это небольшая консультация или что-то простое, поможем бесплатно. А если сложное - договоримся.
Но если вы можете полностью отказаться от лимитов в Kubernetes, рекомендуем это сделать! Это убережет от множества, на первый взгляд, абсолютно неочевидных проблем.
И если вы хотите подробнее ознакомиться с темой троттлинга в Kubernetes, рекомендуем прочитать следующие статьи 1, 2, 3, 4.