20 лютого 2026 р.
Після переходу з OpenStack на Kubernetes команди часто очікують кращої утилізації ресурсів. Але без чіткої моделі планування отримують протилежне: завищені requests, шаблонні limits і автоскейлінг без зв’язку з реальною бізнес-навантаженістю.
Наслідок типовий: витрати ростуть, а в пікові періоди з’являються просідання сервісу. Нижче — практичний підхід для операторів і cloud buyers, які ведуть змішаний контур OpenStack+Kubernetes на OneCloudPlanet.
1) Починайте з поведінки сервісів, а не з «ідеального» кластера
Найчастіша помилка — спочатку зафіксувати розмір node pool, а потім підганяти застосунки. Ефективніше навпаки: розкладіть сервіси за типом навантаження — стабільне, імпульсне, чутливе до затримок, критичне до вікон релізу.
Наприклад, внутрішній звітний сервіс і checkout під час маркетингової кампанії потребують різних запасів. Така сегментація дає реалістичні requests/limits і зменшує ризик дорогих помилок у production.
2) Формуйте подвійний baseline: платформа + workload
Беріть щонайменше 60–90 днів телеметрії та розділяйте платформні витрати від фактичного споживання сервісів. До платформи належать control plane, ingress, observability, CI/CD і security-інструменти. До workload — реальна бізнес-навантаженість.
Це робить розрахунки прозорими для керівників і прибирає ілюзії «миттєвої економії». Для суміжної фінансової моделі використовуйте підхід із матеріалу про витрати міграції OpenStack→Kubernetes.
3) Впровадьте щотижневий right-sizing
Планування руйнується, коли перегляд ресурсів відбувається раз на квартал. Практичніше — щотижневий цикл: сервіси з CPU нижче 35% та стабільною пам’яттю протягом 4 тижнів зменшуються на один крок із заздалегідь описаним rollback.
Для зростання навпаки зафіксуйте тригери: сталий throttling, OOM-тренд, ріст черг. Так апсайзинг стає плановим, а не аварійним.
4) Прив’яжіть автоскейлінг до бізнес-вікон
Автоскейлінг — це механізм, а не стратегія. Спочатку визначте бізнес-вікна: години кампаній, дедлайни звітності, регіональні піки, сервісні вікна. Далі налаштовуйте політики HPA/VPA.
Такий підхід знижує і недоскейл у піку, і простій «зайвих» ресурсів у тихі періоди. Якщо інфраструктура описана як код, зафіксуйте правила в Terraform.
5) Тримайте короткий KPI-набір для рішень
Надлишок метрик ускладнює рішення. Для щотижневої операційної роботи достатньо чотирьох: вартість транзакції сервісу, p95 latency у піку, швидкість реакції скейлінгу та частка перевиділених ресурсів.
Ці KPI зрозумілі і технічним, і комерційним ролям. Саме тому погодження бюджету та змін проходить значно швидше.
Висновок
Планування потужностей Kubernetes для OpenStack-команд має бути регулярним і прив’язаним до реальної поведінки сервісів. Подвійний baseline, щотижневий right-sizing і бізнес-орієнтований автоскейлінг дають передбачуваний результат без болісних переробок.
Більше практичних матеріалів — у блозі OneCloudPlanet.