Для повного освоєння Kubernetes потрібно знати різні способи масштабування кластерних ресурсів: Це одне з головних завдань Kubernetes. Ми підготували високорівневий огляд механізмів горизонтального та вертикального автомасштабування та зміни розміру кластерів, а також рекомендації щодо їх ефективного використання.
Статтю перевела команда, яка реалізувала автомасштабування в .
Чому важливо подумати про масштабування
- Інструмент для управління ресурсами та оркестрування. Звичайно, непогано повозитися з класними функціями розгортання, моніторингу та керування подами (модуль pod - група контейнерів, що запускаються у відповідь на запит).
Однак слід подумати і про такі питання:
- Як масштабувати модулі та програми?
- Як підтримувати контейнери у робочому та ефективному стані?
- Як реагувати на постійні зміни в коді та робочих навантаженнях від користувачів?
Налаштування кластерів Kubernetes для балансування ресурсів та продуктивності може бути складним завданням, воно потребує експертних знань про внутрішню роботу Kubernetes. Робоче навантаження на вашу програму або сервіси може коливатися протягом дня або навіть однієї години, тому балансування краще представляти як безперервний процес.
Рівні автомасштабування Kubernetes
Ефективне автомасштабування вимагає координації між двома рівнями:
- Рівень pod'ів, що включає горизонтальне (Horizontal Pod Autoscaler, HPA) та вертикальне автомасштабування (Vertical Pod Autoscaler, VPA). Це масштабування наявних ресурсів для контейнерів.
- Рівень кластера, яким керує система автомасштабування кластера (Cluster Autoscaler, CA), збільшує або зменшує кількість вузлів усередині кластера.
Модуль горизонтального автомасштабування (HPA)
Як випливає із назви, HPA масштабує кількість реплік pod'ів. Як тригер для зміни кількості реплік більшість девопсов використовують навантаження на процесор і пам'ять. Однак можна масштабувати систему на основі , їх або навіть .
Високорівнева схема роботи HPA:
- HPA безперервно перевіряє значення метрик, вказані при установці, за промовчанням за промовчанням 30 секунд.
- HPA намагається збільшити кількість модулів, якщо досягнутий заданий поріг.
- HPA оновлює кількість реплік усередині контролера розгортання/реплікації.
- Контролер розгортання/реплікації розгортає всі необхідні додаткові модулі.
HPA запускає процес розгортання модулів під час досягнення порогового значення метрик
Під час використання HPA враховуйте наступне:
- Інтервал HPA за промовчанням становить 30 секунд. Він встановлюється прапором horizontal-pod-autoscaler-sync-period у диспетчері контролера.
- Відносна похибка за промовчанням становить 10%.
- Після останнього збільшення кількості модулів HPA очікує стабілізації метрик протягом трьох хвилин. Цей інтервал встановлюється прапором horizontal-pod-autoscaler-upscale-delay.
- Після останнього зменшення кількості модулів HPA очікує стабілізації протягом п'яти хвилин. Цей інтервал встановлюється прапором horizontal-pod-autoscaler-downscale-delay.
- HPA найкраще працює з об'єктами розгортання, а не з контролерами реплікації. Горизонтальне автомасштабування несумісне з послідовним оновленням (rolling update), яке маніпулює безпосередньо контролерами реплікації. При деплой кількості реплік залежить безпосередньо від об'єктів розгортання.
Вертикальне автомасштабування pod'ів
Вертикальне автомасштабування (VPA) виділяє більше (або менше) часу процесора чи пам'яті для існуючих pod'ів. Підходить для pod'ів із збереженням стану (stateful) або без нього (stateless), але здебільшого призначено для stateful-сервісів. Втім, ви можете застосувати VPA і для модулів без збереження стану, якщо потрібно автоматично скоригувати обсяг виділених ресурсів.
VPA також реагує на події OOM (out of memory, недостатньо пам'яті). Для зміни процесорного часу та обсягу пам'яті потрібен перезапуск pod'ів. При перезапуску VPA дотримується бюджету розподілу (), щоб гарантувати мінімально необхідну кількість модулів.
Ви можете встановити мінімальний та максимальний обсяг ресурсів для кожного модуля. Так, можна обмежити максимальний обсяг пам'яті, що виділяється межею в 8 ГБ. Це корисно, якщо поточні вузли не можуть виділити більше 8 ГБ пам'яті на контейнер. Детальні специфікації та механізм роботи описані в .
Крім того, VPA має цікаву функцію рекомендацій (VPA Recommender). Вона відстежує використання ресурсів та події OOM всіх модулів, щоб запропонувати нові значення пам'яті та процесорного часу на основі інтелектуального алгоритму з урахуванням історичних метрик. Також є API-інтерфейс, який приймає дескриптор pod та віддає пропоновані значення ресурсів.
Варто зазначити, що VPA Recommender не відстежує "ліміт" ресурсів. Це може призвести до того, що модуль монополізує ресурси усередині вузлів. Краще встановити граничне значення на рівні простору імен, щоб уникнути величезних витрат пам'яті або процесорного часу.
Високорівнева схема роботи VPA:
- VPA безперервно перевіряє значення метрик, вказані при установці, з інтервалом за промовчанням 10 секунд.
- Якщо досягнутий заданий поріг, VPA намагається змінити виділену кількість ресурсів.
- VPA оновлює кількість ресурсів усередині контролера розгортання/реплікації.
- При перезапуску модулів нові ресурси застосовуються до створених інстансів.
VPA додає необхідну кількість ресурсів
Враховуйте такі моменти під час використання VPA:
- Масштабування потребує обов'язкового перезапуску pod'у. Це потрібно, щоб уникнути нестабільної роботи після внесення змін. Для надійності модулі перезапускають та розподіляють по вузлах на основі нових виділених ресурсів.
- VPA та HPA поки що несумісні один з одним і не можуть працювати на одних і тих же pod'ах. Якщо ви використовуєте в одному кластері обидва механізми масштабування, переконайтеся, що налаштування не дозволять їм активуватися на тих самих об'єктах.
- VPA налаштовує запити контейнерів на ресурси, виходячи лише з минулого та поточного їх використання. Він не встановлює ліміти використання ресурсів. Можуть виникнути проблеми з некоректною роботою додатків, які почнуть захоплювати все більше ресурсів, це призведе до того, що Kubernetes вимкне цей pod.
- VPA поки що на ранній стадії розробки. Будьте готові, що найближчим часом система може зазнати деяких змін. Можна почитати про и . Так, у планах реалізувати спільну роботу VPA та HPA, а також розгортання модулів разом із політикою вертикального автомасштабування для них (наприклад, спеціальна позначка 'requires VPA').
Автомаштабування кластера Kubernetes
Автомаштабування кластера (Cluster Autoscaler, CA) змінює кількість вузлів, виходячи з кількості модулів pod. Система періодично перевіряє наявність модулів, що очікують, — і збільшує розмір кластера, якщо потрібно більше ресурсів і якщо кластер не виходить за межі встановлених лімітів. CA взаємодіє з постачальником хмарних послуг, запитує у нього додаткові вузли або звільняє бездіяльні. Першу загальнодоступну версію CA було представлено в Kubernetes 1.8.
Високоврівнева схема роботи СA:
- CA перевіряє наявність модулів у стані очікування з інтервалом за промовчанням 10 секунд.
- Якщо один або кілька модулів знаходяться в стані очікування через те, що в кластері недостатньо доступних ресурсів для їхнього розподілу, він намагається підготувати один або кілька додаткових вузлів.
- Коли постачальник хмарних послуг виділяє необхідний вузол, приєднується до кластера і готовий обслуговувати модулі pod.
- Планувальник Kubernetes розподіляє модулі, що очікують, на новий вузол. Якщо після цього деякі модулі все одно залишаються в стані очікування, процес повторюється і в кластер додаються нові вузли.
Автоматичне виділення вузлів кластера у хмарі
Враховуйте таке при використанні СA:
- CA гарантує, що всі модулі в кластері мають місце для запуску, незалежно від рівня навантаження на процесор. Крім того, він намагається гарантувати, що у кластері немає непотрібних вузлів.
- CA реєструє необхідність масштабування приблизно за 30 секунд.
- Після того, як вузол стає непотрібним, CA за замовчуванням чекає 10 хвилин, перш ніж масштабувати систему.
- У системі автомасштабування є поняття розширювачів (expanders). Це різні стратегії для вибору групи вузлів, до якої будуть додані нові.
- Відповідально застосовуйте опцію cluster-autoscaler.kubernetes.io/safe-to-evict (true). Якщо встановити багато pod'ів або якщо багато хто з них буде розкиданий по всіх вузлах, ви значною мірою втратите можливість зменшувати масштаб кластера.
- Використовуйте , щоб запобігти видаленню pod'ів, через що частина вашої програми може повністю вийти з ладу.
Як системи автомасштабування Kubernetes взаємодіють між собою
Для ідеальної гармонії слід застосувати автомасштабування і на рівні pod'ів (HPA/VPA), і на рівні кластера. Вони щодо просто взаємодіють між собою:
- HPA або VPA оновлюють репліки pod'ів або ресурси, виділені для існуючих pod'ів.
- Якщо для запланованого масштабування не вистачає вузлів, CA помічає наявність під'єктів у стані очікування.
- CA виділяє нові вузли.
- Модулі розподіляються за новими вузлами.
Спільна система систем масштабування Kubernetes
Типові помилки в автомасштабуванні Kubernetes
Існує кілька типових проблем, з якими девопси стикаються, коли намагаються застосувати автомасштабування.
HPA та VPA залежать від метрик та деяких історичних даних. Якщо виділено недостатньо ресурсів, модулі будуть згорнуті та не зможуть генерувати метрики. У цьому випадку автомасштабування ніколи не відбудеться.
Сама операція масштабування чутлива до часу. Нам хочеться, щоб модулі та кластер масштабувалися швидко – до того, як користувачі помітять якісь проблеми та збої. Тому слід враховувати середній час масштабування pod'ів та кластера.
Ідеальний сценарій - 4 хвилини:
- 30 секунд. Оновлення цільових метрик: 30-60 секунд.
- 30 секунд. HPA перевіряє значення метрик: 30 секунд.
- Менш 2 секунд. Модулі pod створені та переходять у стан очікування: 1 секунда.
- Менш 2 секунд. CA бачить очікувані модулі та надсилає виклики на підготовку вузлів: 1 секунда.
- 3 хвилини. Хмарний провайдер виділяє вузли. K8s чекає, доки вони не будуть готові: до 10 хвилин (залежить від кількох факторів).
Найгірший (реалістичніший) сценарій — 12 хвилин:
- 30 секунд. Оновлення цільових метриків.
- 30 секунд. HPA перевіряє значення метрики.
- Менш 2 секунд. Модулі pod створені і переходять у стан очікування.
- Менш 2 секунд. CA бачить очікувані модулі та надсилає виклики на підготовку вузлів.
- 10 хвилин. Хмарний провайдер виділяє вузли. K8s чекає, доки вони не будуть готові. Час очікування залежить від кількох факторів, таких як затримка постачальника, затримка операційної системи, робота допоміжних інструментів.
Чи не плутайте механізми масштабування хмарних провайдерів з нашої CA. Остання працює всередині кластера Kubernetes, тоді як механізм хмарного провайдера працює на основі розподілу вузлів. Він не знає, що відбувається з вашими pod'ами чи додатком. Ці системи працюють паралельно.
Як керувати масштабуванням у Kubernetes
- Kubernetes - інструмент управління ресурсами та оркестрування. Операції з управління pod'ами та ресурсами кластера — ключова віха в освоєнні Kubernetes.
- Засвойте логіку масштабування pod'ів з урахуванням HPA та VPA.
- CA варто використовувати тільки якщо ви добре розумієте потреби своїх pod'ів і контейнерів.
- Для оптимального настроювання кластера потрібно зрозуміти, як різні системи масштабування працюють разом.
- При оцінці часу масштабування майте на увазі найгірший та кращий сценарії.
Джерело: habr.com