Перестаньте использовать CPU Limits в k8s (перевод)

 Публичный пост для комнаты «Тех»

Многие люди думают, что вам нужны ограничения по использованию ЦПУ на Kubernetes, но это не так. В большинстве случаев, ограничения по использованию ЦПУ на Kubernetes только вредят. Фактически, они являются одной из главных причин ограничения использования ЦПУ на Kubernetes.

Мой перевод статьи о том, почему использование CPU Limits в Kubernetes - не всегда хорошо.

Возможно у вас другое мнение - давайте обсудим. :)

9 комментариев 👇

Ох уж эти кликбейтные заголовки.

Перестаньте использовать CPU Limits в k8s

манипуляция, преувеличение и ложный посыл

использование CPU Limits в Kubernetes - не всегда хорошо

вот это уже больше похоже на правду, действительно есть кейсы, когда CPU Limits могут навредить

  Развернуть 1 комментарий

Если у вас идеальный продукт в идеальном мире - не используйте лимиты.

  Развернуть 1 комментарий

@momai, если идеальный продукт, то и мониторинг нахрен не нужен, чего его мониторить, если он никогда не деградирует и не ломается.

  Развернуть 1 комментарий

Спасибо за перевод и приглашение к дискуссии.
На мой взгляд тема изначально холиварная, а выводы в статье не могут быть однозначны для всех случаев (при этом для узких кейсов справедливы)

Поды всегда получают CPU, указанный в их запросах CPU! (Они также могут использовать избыточный CPU, если у них нет лимита.)

Да, получают, потому что requests используются scheduler'ом для понимания на какой ноде запустить под с таким запросом. Scheduler проводит скоринг нод и если реквест подходит под доступные ресурсы на ноде он может быть на нее назначен. При этом получается что механизм реквестов никак не ограничивает под и гарантия получения CPU исходит из того что в теории для всех подов на ноде определены реквесты достаточные для предполагаемой нагрузки. Такой случай (не использовать лимиты) вполне реален когда целая нода предназначена для 1-2-3 жирных подов которым позволено утилизировать все на этой ноде их юзкейсом, при этом вероятность одновременных пиковых нагрузок на всех разом сведена к минимуму. Но если ноду делят десятки подов, это становится весьма рискованным мероприятием.

  • в случае неидельного кода который может течь какой механизм будет ограничением? Кажется что универсальной практикой является определять реквесты по планируемой нормальной нагрузке, а лимиты делать х2, ну или если пики нагрузки это ок, то лимит - типичный пик, а все что выше - аномалия, которую нужно ограничивать во избежания влияния на работу остального кластера.

Отключите лимиты CPU! Если вы укажете точные запросы CPU для всех ваших подов в Kubernetes, то никто не сможет ограничивать их, потому что CPU будет зарезервирован для них, если им это нужно. Это не имеет ничего общего с лимитами.

Зарезервирован только теоретически scheduler'ом при планировании, а после старта на ноде если другой такой же под без лимитов решить сожрать весь CPU кто гарантирует запрашиваемый нами CPU? Отсюда получается есть другой бест практис: сумма лимитов <= сумме ресурсов на ноде?
Да, общего с лимитами ничего нет. Реквесты - инструмент планирования, лимиты - инструмент ограничения.

Кажется что этот бестпрактис

Не используйте лимиты CPU.

должен звучать как: ИСПОЛЬЗУЙТЕ лимиты так, чтобы под их не достигал. А если произошел троттлинг, то это аномалия с которой нужно разбираться и искать причину.

А по памяти тоже очень спорный бест практис. Получается что для памяти все-таки лимиты необходимы, а для CPU можем их скипнуть (???)

Всегда устанавливать запросы памяти равными лимитам

Как и с CPU: реквесты - механизм планирования, лимиты - механизм ограничения после которых приходит OOM killer.

  Развернуть 1 комментарий

@dmitry_shomrin,

А по памяти тоже очень спорный бест практис. Получается что для памяти все-таки лимиты необходимы, а для CPU можем их скипнуть (???)

Ну по идее да. Если не брать в учет эджкейсы. Я бы делал так:

Для бизнес процессов - не ставить лимиты
Для всего остального - ставить разумные лимиты, типа х2 от реквестов.

Это я все про ЦПУ. По памяти - там отдельная история.

  Развернуть 1 комментарий
Dmitriy Lialiuiev DevOps, Servers abuse автор 7 сентября 2023

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

CPU лимиты это как минимум еще важный механизм ограничения в случае запуска недоверенной нагрузки\внешних сервисов.

Доверяете ли вы настолько поставщикам софта (или зависимостям в вашем софте), чтобы дать теоретическую возможность использовать все доступные ресурсы ЦП на ноде и заафектить тем самым другую нагрузку.

Второй вопрос, как вы будете реагировать если под это сделает, вот сожрал он все доступные ему ресурсы по той или иной причине пойдете убивать его руками?

Ну и третий вопрос, это утилизация ресурсов - высокие реквесты, без лимитов в случае если поды ведут себя прилично, будет приводить к тому что условных 4 пода с реквестом в 2CPU будут полностью занимать ноду на 8 ядер, при этом реальная утилизация может быть и меньше одного. Но это вопрос паттернов нагрузки в вашей среде, где-то может и не так критично.

  Развернуть 1 комментарий

@captaincacao,

  1. Нагрузка наша, приложения наши. Не берем сейчас проблему сжирания ЦПУ сторонними приложениями типа Traefik/Nginx/etc. Там все оттестировано. Ну и на сторонние приложения лимиты можно и выставить. Это тот самый эджкейс.

  2. Мониторинг на это есть. Можно там реакции накрутить. Не проблема. Если уж руками не хочется.

  3. Там ссылка есть на тулзу, которая рекомендует сколько реквестов выставлять. Да и самому без тулзы можно стату посмотреть.

  Развернуть 1 комментарий

@silvergh0st,

  1. Свои приложения не используют внешние зависимости или вы им тоже безусловно доверяете? Как и самому коду приложения в случае если речь про баги, а не злонамеренное поведение?
  2. Т.е. мы реализуем механизм лимитов сторонним сервисом, вместо использования дефолтного?
  3. Для хорошо предсказуемых по нагрузке систем, или приложений с ровной кривой потребления без пиков - этот пункт действительно может быть неактуален.
  Развернуть 1 комментарий

@captaincacao,

  1. Для тестов всего этого дела есть бета, которая живет отдельно. И там все это и отлавливается.

  2. Мы реализуем мониторинг всего этого. И в случае прям явных проблем только пристреливаем. Иногда руками, иногда автоматизацией. (Не, это только теория, у меня везде лимиты стоят. Но подумать в эту сторону - не самая плохая разминка для мозга)

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб