Kubernetes Autoscaling English: VPA, HPA, KEDA, and Scaling Policy Vocabulary (англійською)

Обговорення автомасштабування Kubernetes щільні з акронімами, точним технічним термінами і тонкими відмінностями, які мають велике значення у виробництві. Незалежно від того, чи ви презентуєте план обсягу вашій команді, переглядаєте налаштування HPA у запиті на звантаження або розв’ язуєте проблеми з масштабуванням KEDA у виклику інциденту, англійська мова потребує високої точності. Ця стаття містить словниковий запас і фрази, які вам потрібні для таких розмов.

Горизонтальний проти вертикального Вертикальні лінії

**HPA (Horizontal Pod Autoscaler) ** — контролер Kubernetes, який автоматично коригує кількість реплік піду в розгортанні або наборі станів на основі спостережуваних показників, таких як використання процесора або нетипових показників.

«Наша HPA налаштована на підтримку 60% використання цільового процесора, масштабування між 3 і 50 репліками залежно від трафіку»

VPA (Vertical Pod Autoscaler) — контролер Kubernetes, який автоматично регулює запити і обмеження процесора і пам’ яті запущених підсистем, роблячи кожну підсистему більшою або меншою, а не додаючи більше підсистем.

«Ми використовуємо VPA в режимі рекомендацій для наших пакетних завдань — він говорить нам, які запити ресурсів ми повинні встановити, але не застосовує зміни автоматично в виробництві»

** Скалірованість до нуля ** — можливість зменшення навантаження до нуля запущених екземплярів, коли немає потоку, що виключає витрати на простої обчислень. Не підтримується HPA (що вимагає мінімум 1), але підтримується KEDA і Knative.

«З KEDA, що обробляє наші споживачі, які керуються подією, ми нарешті досягли масштабу до нуля на наших процесорах повідомлень — вони тільки крутяться, коли є повідомлення в черзі»

** Використання цілі ** — порогове значення метрики, яке автоматичний масштабувач намагається підтримувати у всіх підсистемах. Для CPU-заснованого HPA, це зазвичай виражається як відсоток запитаного CPU.

«Ми знизили цільове використання з 80% до 60% після інциденту з Чорною п’ятницею — масштабер реагував занадто повільно, тому що піддони вже були насичені, перш ніж з’явилися нові»

KEDA і розширені терміни автоматичного масштабування

KEDA (Kubernetes Event-Driven Autoscaling) — проект CNCF, який розширює Kubernetes HPA для підтримки масштабування на основі зовнішніх джерел подій: черги, бази даних, метрики Prometheus, розклади cron і багато іншого.

«KEDA дозволяє нам масштабувати наші робочі піддони на основі кількості очікуваних завдань в нашій черзі RabbitMQ, а не тільки процесора — це набагато більш чутливий до реального навантаження»

** Правила масштабування ** — набір правил, які визначають, наскільки швидко і наскільки масштабування може додавати або вилучати підрозділи. Правила керують швидкістю масштабування вгору і вниз окремо.

«Ми маємо агресивну політику збільшення масштабу — до 100% більше піддонів за 30 секунд — але консервативну політику зменшення масштабу, щоб уникнути перевантаження під час піків трафіку»

** Період очікування ** — період очікування після події масштабування, під час якого автоскалер не викликає іншого масштабування. Це запобігає швидкому, небезпечному циклуванні піддонів.

“Типовий період відновлення становить 5 хвилин для зменшення масштабу. Ми продовжили його до 10 хвилин, тому що наш трафік має різкий характер і ми занадто швидко втрачали піддони»

** Вікно стабілізації ** — часове вікно, протягом якого автоскалер збирає показники метрики перед прийняттям рішення щодо масштабування. Використання мінімального (для масштабування вгору) або максимального (для масштабування вниз) значення у цьому вікні запобігає реакції на короткі піки.

«Ми встановлюємо 2-хвилинне стабілізаційне вікно для рішень щодо зменшення масштабу, тому один вибух низького трафіку не відразу зменшує кількість наших підів»

** Сервер метрик ** — компонент агрегування метрик на рівні кластера, який збирає дані про використання ресурсів (ЦП і пам’ яті) з кубелетів і показує їх у HPA. Потрібно для автоматичного масштабування за ресурсами.

«Після оновлення кластера, сервер метрик не був перевстановлений — HPA перейшов в «невідомий» стан, тому що не міг отримати метрики процесора»

** Нетипові метричні дані ** — нетипові метричні дані (не стосуються процесора або пам’ яті), які використовуються для прийняття рішень щодо автоматичного масштабування. Доступ за допомогою нетипового API метрики, часто підтримуваного адаптером Prometheus або масштабувальниками KEDA.

«Ми написали адаптер нетипових метрик, який виставляє нашу глибину черги запитів як метрику Kubernetes, яку HPA потім використовує як свою ціль масштабування»

Контекстно-орієнтовані мови

Ці фрази з’ являються у документах планування обсягу, звітах про інциденти і переглядах запитів на звантаження, пов’ язаних з Kubernetes:

• “HPA тремтить - він збільшився і зменшився чотири рази за 20 хвилин.” - спостереження інциденту, відноситься до нестабільної поведінки масштабування
• ** « Нам потрібно налаштувати вікно стабілізації, щоб запобігти такому збиванню ». ** — рекомендована поправка під час постмортему
• “Давайте встановимо масштаб до нуля тільки для некритичних працівників, а не для API-подів.” — рішення планування обсягів у перегляді дизайну
• ** « Скалер не реагує, оскільки сервер метрики ще не зібрав достатню кількість вибірок. » ** — пояснення щодо усунення несправностей під час виклику інциденту
• “Наші рекомендації VPA показують, що обмеження пам’яті в 4 рази вище, ніж фактичне використання - ми значно перевикористовуємо.” - виявлення оптимізації витрат в квартальному огляді

Ключові слова

Collocation	Example
trigger autoscaling	”High queue depth triggers autoscaling on the consumer deployment.”
tune the HPA	”Let’s tune the HPA stabilization window before the next load test.”
provision pods	”KEDA provisions pods proactively before the morning traffic peak.”
scale down aggressively	”Scaling down too aggressively causes connection-reset errors for in-flight requests.”
set resource requests	”VPA recommendations help us set resource requests more accurately.”
hit the replica limit	”We hit the replica limit at 50 pods — we need to raise the max or optimize the service.”
drain a node	”Before scaling down the node pool, the cluster drains each node to reschedule pods gracefully.”

Practice

Знайдіть найчастіше масштабоване навантаження Kubernetes вашої команди. Напишіть коротку записку щодо планування пропускної здатності англійською мовою (один абзац, 6- 8 речень), у якій описайте: які метричні дані є причиною масштабування, на що спрямовано поточну конфігурацію HPA або KEDA, який спостерігався режим невдачі під час піків навантаження, і яку зміну конфігурації ви б запропонували. Використовуйте принаймні п’ ять слів з цього повідомлення. Це безпосередньо відображає формат розділу планування потужності в квартальному документі огляду інфраструктури.

Націоналізація: перспективи розвитку

Будьмо чесними - “політика збільшення” звучить неймовірно сухою. Нет, не так. У ній описано складну розмову щодо потреб у ресурсах, цілей швидкодії і потенційних проблем у вашій програмі. Часто, це не просто про сліпе збільшення процесора або пам’яті; це про розуміння * чому * масштабування відбувається і забезпечення того, що основна система може насправді обробляти збільшене навантаження. Це місце, де точна англійська мова стає вирішальною - уникаючи неоднозначності і ефективно спілкуючись з розробниками, операційними командами і зацікавленими сторонами. Поширена фраза, яку ви почуєте, це «досягнення оптимального використання ресурсів», що є не тільки технічним терміном, але відображає ширшу бізнес-ціль: мінімізація витрат при збереженні продуктивності. Крім того, обговорення часто переміщується між теоретичним плануванням обсягу і * фактичною * спостереженою поведінкою вашого застосування - що призводить до дебатів про те, чи є політика масштабування дійсно ефективною або просто реагує на піки, яких можна було б уникнути з кращим дизайном. Ключовим є перейти від простого затвердження «збільшення процесора» до вираження скільки, чому і за яких умов. Наприклад, замість того, щоб сказати « масштабувати », більш інформаційним буде твердження: « Збільшити мету HPA для підрозділу « моя- програма » на 20% під час годин пік (визначено як 9 ранку — 12 вечора) для врахування очікуваного збільшення трафіку на основі останніх даних моніторингу ». Цей рівень деталізації є необхідним для забезпечення того, щоб рішення щодо масштабування були вирівняні з бізнес- потребами і технічними обмеженнями. Нарешті, пам’ятайте, що ефективне спілкування не тільки залежить від правильних слів; воно залежить від активного слухання і спільного розуміння проблеми, яку потрібно вирішити.

Давайте розглянемо приклад з використанням налаштування Kubernetes Horizontal Pod Autoscaler (HPA). Коментар коду може бути таким: «Ця корекція HPA здається надто агресивною. Чи можете ви надати більш докладні метричні дані, щоб обґрунтувати збільшення кількості підрозділів на 50%? Чи ми стежимо за довжиною черги, затримкою запитів, чи за чимось іншим?» Це підкреслює критичний момент – основний для масштабування рішень має величезне значення. Без розуміння того, що призводить до навантаження, масштабування стає реактивною мірою, а не проактивною. Цей коментар не є критикою; він спонукає до глибшого розслідування і прояснює логіку, що стоїть за цією зміною. Для встановлення цілі HPA скористайтеся цією командою:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70 #This is the key - setting a target for CPU utilization

Параметр averageUtilization, в цьому випадку націлений на 70%, демонструє, як ви не просто реагуєте на запити, а встановлюєте базові очікування. Більш складний підхід може поєднувати ресурсні метрики з нетиповими метриками, що показують шаблони навантаження, специфічні для програми. Врешті-решт, освоєння словникового запасу щодо масштабування політики полягає в переході від опису чого до дій – збільшення підрозділів – до пояснення чому і забезпечення того, щоб ці дії були вирівняні з вимірюваними результатами.