Стоит ли устанавливать лимиты ЦП Kubernetes?

resources:
  requests:
    cpu: 500m
  limits:
    cpu: 1000m

Почему ограничения ЦП опасны

Чтобы понять, почему ограничения ЦП являются проблематичными, рассмотрим, что произойдет, если под с параметрами ресурсов, показанными выше (запрос 500 м, ограничение 1000 м), будет развернут на четырехъядерном узле с общей мощностью ЦП 4000 м. Для простоты на узле нет других запущенных подов.

$ kubectl get pods -o wide
NAME            READY       STATUS      RESTARTS    AGE     IP              NODE
demo-pod        1/1         Running     0           1m      10.244.0.185    quad-core-node

Pod сразу же подключается к узлу, потому что запрос на 500 м немедленно удовлетворяется. Pod переходит в состояние Running. Нагрузка может быть низкой, если ЦП использует около нескольких сотен миллиядер.

Затем происходит внезапный всплеск трафика: поток запросов и эффективная загрузка ЦП подскакивают до 2000 м. Из-за ограничения ЦП это значение снижено до 1000 м. Однако на узле не работают никакие другие модули, поэтому он мог бы обеспечить полные 2000 м, если бы модуль не был ограничен своим лимитом.

Емкость узла была потрачена впустую, а производительность пода снизилась без необходимости. Отказ от ограничения ЦП позволит поду использовать полные 4000 м, потенциально выполняя все запросы в четыре раза быстрее.

No Limit по-прежнему предотвращает перерасход ресурсов пода

Отсутствие ограничений ЦП не ставит под угрозу стабильность, если вы установили соответствующие запросы для каждого модуля. При развертывании нескольких подов доля процессорного времени каждого пода масштабируется пропорционально его запросу.

Вот пример того, что происходит с двумя модулями без ограничений, когда они развернуты на 8-ядерном (8000 м) узле, и каждый из них одновременно требует 100% загрузки ЦП:

Если Pod 1 находится в более спокойном периоде, тогда Pod 2 может использовать еще больше циклов ЦП:

Запросы ЦП по-прежнему имеют значение

Эти примеры демонстрируют, почему запросы ЦП имеют значение. Установка соответствующих запросов предотвращает конкуренцию, гарантируя, что поды планируются только к узлам, которые могут их поддерживать. Это также гарантирует взвешенное распределение доступных циклов ЦП, когда несколько подов испытывают повышенный спрос.

Ограничения ЦП не дают этих преимуществ. Они полезны только в тех случаях, когда вы хотите снизить производительность Pod выше определенного порога. Это почти всегда нежелательное поведение; вы утверждаете, что другие ваши поды всегда будут заняты, тогда как они могут бездействовать и создавать запасные циклы ЦП в кластере.

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

Что насчет памяти?

Память управляется в Kubernetes с использованием тех же концепций запроса и ограничения. Однако память — это физически другой ресурс по сравнению с использованием ЦП, который требует собственного метода распределения. Память не сжимаема: ее нельзя отозвать после того, как она была выделена процессу-контейнеру. Процессы совместно используют ЦП по мере его доступности, но им выделяются отдельные части памяти.

Установка одинаковых запросов и лимитов — лучший подход к управлению памятью в Kubernetes. Это позволяет вам надежно прогнозировать общее потребление памяти всеми подами в вашем кластере.

Может показаться логичным установить относительно низкий запрос с гораздо более высоким лимитом. Однако использование этого метода для многих подов может иметь дестабилизирующий эффект: если несколько подов превысят свои запросы, емкость памяти вашего кластера может быть исчерпана. Убийца OOM вмешается, чтобы завершить процессы контейнера, что может привести к нарушению ваших рабочих нагрузок. Выселение может быть направлено на любой из ваших модулей, а не только на тот, из-за которого исчерпана память.

Использование равных запросов и ограничений не позволяет поду планировать, если узел не может предоставить требуемую ему память. Это также гарантирует, что под не может использовать больше памяти, чем его явное выделение, что устраняет риск чрезмерного использования, когда несколько подов превышают свои запросы. Чрезмерное использование станет очевидным, когда вы попытаетесь запланировать Pod, и ни один Node не сможет удовлетворить запрос памяти. Ошибка возникает раньше и более предсказуемо, не затрагивая другие модули.

Краткое содержание

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

Установка лимитов ЦП не позволяет вашим процессам использовать свободную мощность ЦП, когда она становится доступной. Это излишне снижает производительность, когда под может временно использовать циклы, которые не требуются ни одному соседу.

Используйте разумный запрос ЦП, чтобы предотвратить планирование подов на узлах, которые уже слишком заняты, чтобы обеспечить хорошую производительность. Оставьте поле ограничения неустановленным, чтобы поды могли получать доступ к дополнительным ресурсам при выполнении ресурсоемких задач в то время, когда ресурсы доступны. Наконец, назначьте каждому поду запрос памяти и ограничение, убедившись, что вы используете одно и то же значение для обоих полей. Это предотвратит исчерпание памяти, создав более стабильную и предсказуемую кластерную среду.