Ліміти та квоти в AKS: Як не дати кластеру «лягти» у найвідповідальніший момент

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

У світі Kubernetes існують певні обмеження (limits) та квоти (quotas) в AKS, які можуть як врятувати ваше розгортання, так і стати причиною його краху. Сьогодні ми розберемося, на чому варто зосередитися і чому ці «невидимі бар’єри» насправді є критично важливими для стабільності системи.

В цьому матеріалі ми розберемо ключові налаштування ресурсів в Azure Kubernetes Service, які багато хто ігнорує, що згодом виливається у серйозні проблеми з ворклоадами.

1. Requests vs Limits: Бронювання vs Жорстка стеля

Найперше і найважливіше правило в управлінні ресурсами AKS: кожен контейнер повинен мати чітко прописані requests та limits. Без них планувальник (scheduler) Kubernetes працює «наосліп», намагаючись вгадати, куди запхнути ваш под.

1. Requests (Запити): Це мінімальний обсяг ресурсів, необхідний контейнеру для роботи. Уявіть це як резервацію столика в ресторані — планувальник шукає вузол (node), де є саме стільки вільного місця.
2. Limits (Ліміти): Це ваша «жорстка стеля». Перевищили ліміт по пам’яті (RAM) — под буде миттєво вбитий (OOMKilled). Перевищили ліміт по CPU — почнеться тротлінг (примусове уповільнення роботи).

Класи пріоритетності (QoS)

Те, як ви налаштуєте ці параметри, визначає «виживаність» вашого поду:

1. Guaranteed: Requests = Limits. Найвищий пріоритет. Kubernetes захищатиме такі поди до останнього.
2. Burstable: Requests менші за Limits. Поди можуть споживати більше ресурсів, якщо вони є, але їх виселять (evict) першими, якщо вузлу стане важко.
3. Best Effort: Жодних параметрів не вказано. Це перші кандидати на «виліт» при найменшому тиску на ресурси.

2. Квоти на рівні Namespace: Захист від «ненажерливих» розробників

Навіть ідеально налаштований под не врятує, якщо хтось задеплоїть кривий код з витоком пам’яті без лімітів. Один такий процес може «з’їсти» весь вузол, поклавши сусідні додатки.

Resource Quotas вирішують цю проблему, встановлюючи ліміти на весь Namespace (наприклад, не більше 10 CPU та 20 GB RAM на весь відділ розробки).

Порада від профі: Квоти не уповільнюють розробку, а навпаки — пришвидшують її. Якщо квоти увімкнено, Kubernetes просто не прийме деплой без вказаних лімітів. Це привчає команду до порядку з першого дня.

3. LimitRange: Страховка від людських помилок

Навіть з квотами один под може монополізувати всі ресурси неймспейсу. Об’єкт LimitRange дозволяє встановити значення за замовчуванням. Якщо розробник забув вказати ресурси, LimitRange автоматично підставить, скажімо, 500m CPU. Це ваш «захист від дурня».

4. Pod Disruption Budgets (PDB): Виживання під час обслуговування

Ваш додаток може бути ідеально налаштований, але все одно «впасти» під час планового оновлення кластера або обслуговування вузлів Azure.

Тут на сцену виходять Pod Disruption Budgets. Вони гарантують, що під час добровільних переривань (наприклад, дренажу вузла перед апгрейдом) у вас завжди буде запущена мінімальна кількість копій додатка (наприклад, minAvailable: 3 або maxUnavailable: 10%). Kubernetes просто не дозволить вимкнути вузол, поки не переконається, що додаток залишається доступним.

Підсумок: Головний секрет CPU та RAM

Запам’ятайте одну річ, на якій часто ловляться навіть Senior-інженери:

1. CPU Limits: Будьте щедрими. Тротлінг — це неприємно (додаток гальмує), але не фатально. Встановлюйте ліміти по пікових навантаженнях.
2. Memory Limits: Будьте точними. Перевищення ліміту пам’яті — це миттєва смерть процесу. Завжди моніторте реальне споживання і додавайте розумний буфер.

Ці чотири практики допоможуть уникнути 95% проблем із ресурсами в AKS. Коли ви наведете лад із квотами, наступним кроком буде оптимізація самих Docker-образів, щоб пришвидшити запуск подів та зменшити витрати на кластер.