Myafq 31 окт 2019 в 06:11

Застрахуй ресурсы в Кубе

8 мин

5.4K

Системное администрирование*DevOps*Kubernetes*

Комментарии 8

Wesha 31 окт 2019 в 07:15

А как там, на Кубе, дела, как Кастро поживает?

angapov 31 окт 2019 в 08:06

«Бродячие» поды это зло в чистом виде. От них можно избавиться, если на каждый неймспейс наложить квоту с реквестами и лимитами. В кубере вроде бы нет возможности автоматически накладывать квоту на новые неймспейсы. В опеншифте можно указать темплейт для новых неймспейсов и указать в нем в том числе квоту. Это сильно помогает держать потребление ресурсов под контролем.

KIVagant 31 окт 2019 в 15:58

Статья как раз про это и сообщает и даже предлагает решение.

angapov 31 окт 2019 в 16:12

Статья про LimitRange, а я говорю про другую сущность — квоты. Помимо своего прямого назначения квоты также помогают решить проблему BestEffort подов. Если в квоте указаны лимиты, то каждый под в неймспейсе обязан указывать лимиты. Это также может считаться решением проблемы. А в опеншифте это можно применить автоматически ко всем создаваемым неймспейсам (проектам) без установки дополнительных операторов.

Поэтому предложенное мной решение отличается от описанного в статье.

KIVagant 31 окт 2019 в 17:00

Квоты хорошая штука, безусловно. Но с ними усложняется мониторинг. Если ReplicaSet не может создать под из-за квот, то под не виден в списке (возможно в более новых куберах уже улучшили это). В итоге нужно изобретать сложные проверки, чтобы заметить, что есть Replicasets, у которых ожидаемое количество подов не совпадает с желаемым. Тем не менее я также за их установку. Но вот беда в том, что сами resource requests и limits далеко не так просты, как хочется. Например, лимиты на CPU могут существенно снижать производительность кластера. А с лимитами на ephemeral storage вообще крайне сложно, так как невозможно получить реальное использование по этой метрике.
И дополнительной вишенкой является работа самого планировщика. По-умолчанию он планирует поды по limits, а не по requests. И если установить поду/контейнерам RAM request в 100Mb, а limit в 16Gb, то этот под «зарезервирует» ноду целиком.

Плюс есть какая-то странность в том, что поды в статусе Completed всё ещё учитываются в квотах по namespace (тут вероятно тоже могут быть отличия в более новых версиях). В итоге квоты приходится раздувать.

angapov 31 окт 2019 в 18:01

Про недостатки лимитов — да, они есть, но что поделаешь, остается лишь ждать пока починят. Альтернативы отсутствуют.

Про планировщик — он же вроде по реквестам планирует? Откуда информация про планирование по лимитам? Если поду выставить реквест в 100 МБ, а лимит в 16 ГБ, то поду выделится 100 метров. Если под начнет есть память дальше, то при нехватке памяти будет убит. Никакого резервирования 16 гигов я никогда не видел.

KIVagant 31 окт 2019 в 18:25

> Откуда информация про планирование по лимитам?

Это уже у меня смешались в кучу конелюди. Планирует он по requests, это я некорректно сформулировал свою мысль. Была какая-то проблема, с которой я боролся пару месяцев назад. Вспомню, вернусь.

Myafq 31 окт 2019 в 18:37

Дефолтный планировщик определенно использует реквесты, вот как раз фраза про это из документации:
PodFitsResources filter checks whether a candidate Node has enough available resource to meet a Pod’s specific resource requests
По-моему чтобы планировщик учитывал лимиты, его нужно кастомизировать.

Квоты в целом очень мощный инструмент, который остался за скоупом статьи как раз по причине своей мощности. Я думаю что применять их надо вместе — LimitRange и ResourceQuota отлично дополняют друг друга. С использованием первого мы позволяем работать любым подам, даже созданным на скорую руку, в рамках второй. Квоты это следующий шаг регулирования кластера после настройки ресурсов и стабилизации работы в целом.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время