Прохожу очень полезный курс о Kubernetes от DataLine, долго вникал в тему управления ресурсами, вот краткий конспект словами, понятными мне. Возможно, пригодится и вам.

Знаменитый мем «Миграция контейнеров в облако»

Что вообще можно сделать для управления ресурсами

По умолчанию в k8s поды(контейнеры) могут потреблять столько ресурсов, сколько хотят (из физически доступных на ноде). Но можно активировать механизмы k8s, управляющие этим.

k8s здесь может действовать в двух ролях :

• во время работы системы k8s может следить за контейнерами (подами) и карать те, что потребляют ресурсов больше чем обещали максимально потреблять

• на запуске пода (контейнера) k8s может решать, запускать ли объект (и где именно его запускать), исходя из того сколько ресурсов он требует для работы в норме и сколько обещает потреблять в максимальном случае

Что для надо для управления ресурсами

• В правилах системы управления должны быть описаны принципы (политики), по которым системе эти требования и обещания контейнера проверяются на то, подходят они или нет k8s

• свойствах контейнера (пода) должны быть прописаны его потребности при работе в норме (requests), они же минимальные требования для старта. Также в свойствах контейнера (пода) должны быть прописаны его максимально допустимые аппетиты (limits): сколько он обещает пожирать в самом-самом плохом случае. Если контейнер не сообщает свои требования и обещания, но они нужны для работы политик — они будут назначены этими политиками принудительно сверху (сам виноват).

Не даем запущенному пожрать сверх договорённостей

Этот функционал реализуется на основе мониторинга процессов. Здесь необходимы значения максимально допустимых аппетитов (limits) объекта — они должны быть описаны в свойствах, либо должны быть заданы принудительно политиками Limit Ranges (про них чуть дальше).

Если контейнер (под) пережирает сверх обещанного, k8s может тротлить процессор (при нарушении лимитов CPU) или останавливать\перезапускать под, если идет перебор по памяти. Таким образом, гарантируется что контейнер будет во время работы есть от 0 до limits ресурсов процессора и памяти.

Не запускаем объекты, если нам это не подходит

Второй механизм управления работает в момент запуска объекта. В каждом namespace может быть использованы две политики, и при запуске пода(контейнера) будут проверяться его запросы (минимальные и максимальные), а также состояние системы после его запуска, на соответствие этим политикам. Если принято решение что в результате политика(и) не будет нарушена — старт разрешен. Далее соответствие политике не контролируется.

Политика Limit Range. Задает в namespace ограничения на запросы и лимиты подов(контейнеров). Если pod (контейнер) просит (requests) меньше, чем нижний лимит (min limits) политики, или обещает максимальное потребление (limits) больше, чем верхний лимит (max limits) политики — он запущен не будет. Здесь может возникнуть путаница из-за несогласованного использования термина limits, важно не запутаться.

Нюансы:

• Если под не сообщает свой лимит или запрос, они задаются принудительно значениями из политики по умолчанию (default [это шаблон для limits] и DefaultRequest [это шаблонное значение для requests]) — и в дальнейшем эти значения могут влиять на ограничения при работе pod, описанные ранее (с ними будет сравниваться его реальное потребление).

• Limit Range может быть задан для подов или контейнеров. В случае, если Limit Range задан на контейнеры, и хотя бы один контейнер в поде не подходит под значения политики, не стартанёт весь pod.

иллюстрация Limit Range от НИИ Быстрых Иллюстраций

• В отличие от мониторинга уже запущенных контейнеров, здесь принимается решение в том числе на базе минимально запрошенных требований (requests). Это дает k8s возможность распределять ресурсы равномерней а также не запускать объекты, которые уже точно не влазят в мощности инфраструктуры. Следует стараться задавать эти значения, чтобы не оказаться в ситуации когда контейнер запущен в среде с нехваткой ресурсов (не сказал сколько надо — получи минимальный минимум)

Политика Resource Quotas. Задает в namespace максимальный предел ресурсов, которые могут быть запрошены суммарно всеми подами или контейнерами этого namespace, на основании указанных в конфигурации подов(контейнеров) данных (важно, не фактически потребляемых, а именно запрашиваемых в манифесте). Политика не дает зарезервировать больше ресурсов или создать больше сущностей, чем админ готов потратить на все объекты namespace. Нюансы:

• для cpu и ram политика может задавать верхний предел для любых значений — и requests (что фактически значит «не позволить назапускать объектов которые захотят жрать все вместе как мимимум столько то»), и limits (что фактически значит «не позволить назапускать объектов, которые все вместе при фиговом раскладе в максимуме сожрут столько то»).

• также здесь могут быть заданы ограничения для суммарного количества других сущностей в namespace (секреты итп).

Ссылочки

Материалы по теме:
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
https://kubernetes.io/docs/concepts/policy/

Канал DataLine в телеге (где бывают в том числе анонсы их учебных программ) — https://t.me/unidataline