Для кожного ресурсу Kubernetes є можливість налаштовувати два типи вимог – Requests та Limits. Перше описує мінімальні вимоги до наявності вільних ресурсів вузла, необхідні запуску контейнера чи пода, друге жорстко обмежує ресурси, доступні контейнеру.
Коли Kubernetes планує pod, дуже важливо, щоб контейнери мали достатньо ресурсів для нормальної роботи. Якщо ви плануєте розгорнути велику програму на вузлі з обмеженими ресурсами, цілком можливо, що вона не буде працювати через те, що у вузла закінчується пам'ять або йому не вистачає потужності процесора. У цій статті ми розглянемо, як можна вирішити проблеми нестачі комп'ютерних потужностей за допомогою запитів на ресурси та обмеження.
Запити Requests та обмеження Limits — це механізми, які Kubernetes використовує для керування такими ресурсами, як процесор і пам'ять. Requests - це те, в результаті чого контейнер гарантовано отримує запитуваний ресурс. Якщо контейнер запитує ресурс, то Kubernetes запланує його лише на тому вузлі, який здатний надати його. Обмеження Limits контролюють, що ресурси, які запитують контейнер, ніколи не перевищать певного значення.
Контейнер може збільшувати обчислювальні потужності лише до певної межі, після чого буде обмежений. Погляньмо, як це працює. Отже, існує два типи ресурсів – процесор та пам'ять. Планувальник Kubernetes використовує дані про ці ресурси, щоб з'ясувати, де запускати ваші поди. Типова специфікація ресурсів для пода виглядає так.
Кожен контейнер в під може встановлювати свої власні запити та обмеження, все це адитивно. Ресурси процесора визначаються у мілікорах. Якщо ваш контейнер для запуску потребує двох повних ядра, ви встановлюєте значення 2000m. Якщо контейнеру потрібна потужність лише 1/4 ядра, значення становитиме 250m. Майте на увазі, що якщо ви призначите значення ресурсів процесора більше, ніж кількість ядер найбільшого вузла, запуск вашого пода взагалі не буде запланований. Аналогічна ситуація станеться, якщо у вас є під, який потребує чотирьох ядрах, а кластер Kubernetes складається лише з двох основних віртуальних машин.
Якщо тільки ваш додаток не розроблений спеціально для використання переваг декількох ядер (при цьому на думку спадають такі програми, як складні наукові обчислення та операції з базами даних), то найкращою практикою є встановлення CPU Requests на 1 або нижче з наступним запуском більшої кількості реплік для масштабованості. Таке рішення надасть системі більшої гнучкості та надійності.
Коли справа доходить до обмежень процесора, все стає цікавішим, оскільки він вважається стисливим ресурсом. Якщо ваша програма починає наближатися до ліміту процесорної потужності, Kubernetes почне пригальмовувати ваш контейнер, використовуючи CPU Throttling – зниження частоти процесора. Це означає, що процесор буде штучно обмежений, надаючи додатку потенційно гіршу продуктивність, проте процес не буде припинено або винесено.
Ресурси пам'яті визначаються байтах. Зазвичай значення в налаштуваннях вимірюється в мебібайтах Mib, але ви можете встановити будь-яке значення, від байтів до петабайтів. Тут має місце та сама ситуація, що й з CPU — якщо ви розмістите запит на кількість пам'яті, що перевищує обсяг пам'яті на ваших вузлах, виконання цього під не буде заплановано. Але, на відміну від ресурсів процесора, пам'ять не стискається, тому що немає жодного способу обмежити її використання. Тому виконання контейнера буде зупинено, як тільки він вийде за межі виділеної пам'яті.
Важливо пам'ятати, що ви не можете налаштувати запити, що перевищують розмір ресурсів, які можуть надати ваші сайти. Характеристики загальних ресурсів для віртуальних машин GKE можна знайти за посиланнями, розміщеними під відео.
В ідеальному світі налаштувань контейнера за умовчанням буде достатньо, щоб робочі процеси проходили гладко. Але реальний світ не такий, люди легко можуть забути налаштувати використання ресурсів або хакери встановлять запити та обмеження, що перевищують реальні можливості інфраструктури. Щоб запобігти розвитку таких сценаріїв, можна налаштувати квоти ресурсів ResourceQuota та діапазони обмежень LimitRange.
Після створення простору імен можна заблокувати їх за допомогою квот. Наприклад, якщо у вас є простори імен prod і dev, використовується шаблон, при якому квоти на продакшн відсутні взагалі, а квоти на девелопмент є дуже строгими. Це дозволяє prod у разі різкого стрибка трафіку забрати собі весь наявний ресурс, повністю заблокувавши dev.
Квота ресурсів може бути таким чином. У цьому прикладі є 4 розділи – це 4 нижні рядки коду.
Давайте розглянемо кожен із них. Requests.cpu – це максимальна кількість комбінованих запитів процесорної потужності, які можуть надходити від усіх контейнерів простору імен. У даному прикладі у вас можуть бути 50 контейнерів із запитами по 10m, п'ять контейнерів із запитами по 100m або просто один контейнер із запитом 500m. Доки загальна кількість requests.cpu даного простору імен буде менше 500m, все буде в порядку.
Запитувана пам'ять requests.memory – це максимальна величина комбінованих запитів пам'яті, яку можуть мати всі контейнери у просторі імен. Як і в попередньому випадку, ви може мати 50 контейнерів по 2 mib, п'ять контейнерів по 20 Mib або єдиний контейнер з 100 Mib до тих пір, поки загальна кількість пам'яті, що запитується, в просторі імен буде менше, ніж 100 мебібайт.
Limits.cpu – це максимальне комбіноване значення процесорної потужності, яку можуть використовувати всі контейнери простору імен. Можна вважати, що це межа запитів процесорної потужності.
Нарешті limits.memory – максимальний обсяг загальної пам'яті, який можуть використовувати всі контейнери у просторі імен. Це обмеження сумарних запитів пам'яті.
Отже, за замовчуванням контейнери в кластері Kubernetes працюють із необмеженими обчислювальними ресурсами. За допомогою квот ресурсів адміністратори кластера можуть обмежити споживання ресурсів та їх створення на основі простору імен. У просторі імен модуль pod або контейнер може споживати стільки потужності CPU та пам'яті, скільки визначено квотою ресурсів просторів імен. Однак існує побоювання, що один під контейнер може монополізувати всі наявні ресурси. Для запобігання такій ситуації використовується граничний діапазон limit Range – політика обмеження розподілу ресурсів (для подів чи контейнерів) у просторі імен.
Граничний діапазон надає обмеження, які можуть:
- забезпечувати мінімальне та максимальне використання обчислювальних ресурсів для кожного модуля чи контейнера у просторі імен;
- примусово виконувати мінімальний та максимальний запит сховища Starage Request для кожного PersistentVolumeClaim у просторі імен;
- примусово встановлювати співвідношення між запитом Request та обмеженням Limit для ресурсу у просторі імен;
- встановлювати Requests/Limits за умовчанням для обчислювальних ресурсів у просторі імен та автоматично вводити їх у контейнери під час виконання.
Таким чином, можна створити граничний діапазон у своєму просторі імен. На відміну від квоти, яка розповсюджується на весь простір імен, Limit Range використовується для окремих контейнерів. Це може запобігти створенню користувачами зовсім крихітних або, навпаки, гігантських контейнерів усередині простору імен. Граничний діапазон Limit Range може мати такий вигляд.
Як і в попередньому випадку, тут можна виділити 4 розділи. Давайте розглянемо кожен.
У розділі default встановлюються стандартні обмеження для контейнера в поді. Якщо ви встановите ці значення в граничному діапазоні, будь-які контейнери, для яких ці значення не були явно встановлені, керуватимуться значеннями за промовчанням.
У розділі запит за промовчанням defaultRequest налаштовано запити за промовчанням для контейнера в поді. Знову ж таки, якщо ви встановите ці значення в граничному діапазоні, будь-які контейнери, для яких ці параметри явно не задані, будуть використовувати ці значення за замовчуванням.
У розділі max наведено максимальні обмеження, які можуть бути встановлені для контейнера в поді. Значення у розділі default та обмеження для контейнера не можуть бути встановлені вище цієї межі. Важливо, якщо встановлено значення max, а розділ default відсутня, то максимальне значення стає значенням за промовчанням.
У розділі min вказані мінімальні запити, які можуть бути встановлені для контейнера в поді. При цьому значення у розділі default та запити для контейнера не можуть бути встановлені нижче цієї межі.
Знову ж таки, важливо відзначити, що якщо це значення встановлено, значення default – ні, то мінімальне значення стає запитом за замовчуванням.
У результаті ці запити ресурсів використовуються планувальником Kubernetes для виконання ваших робочих навантажень. Для того щоб ви могли правильно налаштувати свої контейнери, дуже важливо зрозуміти, як це працює. Припустимо, ви хочете запустити кілька модулів у своєму кластері. Припускаючи, що специфікації пода дійсні, у розкладі Kubernetes використовуватиметься циклічне балансування для вибору вузла для виконання робочого навантаження.
Kubernetes перевірить, чи достатньо ресурсів біля вузла Node 1 для виконання запитів контейнерів пода, і якщо це не так, то перейде до наступного вузла. Якщо ж жоден із вузлів у системі не здатний задовольнити запити, піди перейдуть у стан очікування Pending state. За допомогою таких функцій Google Kubernetes engine, як автомасштабування вузлів, GKE може автоматично визначити стан очікування та створити ще кілька додаткових вузлів.
Якщо згодом виникне надмірна ємність вузлів, функція автомасштабування зменшить їх кількість, щоб заощадити гроші. Ось чому Kubernetes планує поди на основі запитів. Однак ліміт може вищим, ніж запити, і в деяких випадках вузол може фактично вичерпати ресурси. Ми називаємо такий стан overcommitment state.
Як я вже сказав, якщо йдеться про процесор, Kubernetes почне обмежувати поди. Кожен pod отримає стільки, скільки він просив, але якщо при цьому не досягне ліміту, то почне застосовуватися троттлінг.
Що стосується ресурсів пам'яті, то тут Kubernetes змушений приймати рішення про те, які піди видаляти, а які зберігати, доки ви не звільните системні ресурси, інакше вся система впаде.
Уявімо собі сценарій, в якому у вас є машина, що вичерпала ліміт пам'яті - як при цьому надійде Kubernetes?
Kubernetes шукатиме поди, які використовують більше ресурсів, ніж запитували. Так що якщо ваші контейнери взагалі не мають запитів Requests, це означає, що за замовчуванням вони використовують більше, ніж просили, просто тому, що вони не просили взагалі нічого! Такі контейнери стають головними кандидатами відключення. Наступними кандидатами є контейнери, які задовольнили всі свої запити, але все ще знаходяться нижче за максимальний ліміт.
Так що якщо Kubernetes знайде кілька подів, які перевищили параметри своїх запитів, то відсортує їх за пріоритетом, а потім видалить найнижчі пріоритетні модулі. Якщо всі модулі мають однаковий пріоритет, Kubernetes припинить роботу тих подів, які перевищили свої запити більше, ніж інші поди.
У дуже поодиноких випадках Kubernetes може перервати роботу подів, які все ще знаходяться в рамках своїх запитів. Це може статися, коли такі критичні компоненти системи як агент Kubelet або Docker почнуть споживати більше ресурсів, ніж було для них зарезервовано.
Отже, на початкових етапах роботи невеликих компаній кластер Kubernetes може чудово працювати без встановлення запитів ресурсів та обмежень, але в міру того, як ваші команди та проекти починають зростати в розмірах, ви ризикуєте зіткнутися з проблемами в цій галузі. Додавання запитів і обмежень у ваші модулі та простору імен вимагає зовсім небагато додаткових зусиль і може позбавити багатьох клопотів.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com