- PVSM.RU - https://www.pvsm.ru -
Для полного освоения Kubernetes нужно знать различные способы масштабирования кластерных ресурсов: по словам разработчиков системы [1], это одна из главных задач Kubernetes. Мы подготовили высокоуровневый обзор механизмов горизонтального и вертикального автомасштабирования и изменения размера кластеров, а также рекомендации, как их эффективно использовать.
Статью Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler, and Vertical Pod Autoscaler [2] перевела команда, которая строит Kubernetes aaS от Mail.ru [3].
Kubernetes [4] — инструмент для управления ресурсами и оркестровки. Конечно, неплохо повозиться с классными функциями развертывания, мониторинга и управления подами (модуль pod — группа контейнеров, запускаемых в ответ на запрос).
Однако следует подумать и о таких вопросах:
Настройка кластеров Kubernetes для балансировки ресурсов и производительности может быть сложной задачей, она требует экспертных знаний о внутренней работе Kubernetes. Рабочая нагрузка на ваше приложение или сервисы может колебаться в течение дня или даже одного часа, поэтому балансировку лучше представлять как непрерывный процесс.
Эффективное автомасштабирование требует координации между двумя уровнями:
Как следует из названия, HPA масштабирует количество реплик pod'ов. В качестве триггеров для изменения количества реплик большинство девопсов используют нагрузку на процессор и память. Однако можно масштабировать систему на основе пользовательских метрик [5], их сочетания [6] или даже внешних метрик [7].
Высокоуровневая схема работы HPA:
HPA запускает процесс развертывания модулей при достижении порогового значения метрик
При использовании HPA учитывайте следующее:
Вертикальное автомасштабирование (VPA) выделяет больше (или меньше) времени процессора или памяти для существующих pod'ов. Подходит для pod'ов с сохранением состояния (stateful) или без него (stateless), но в основном предназначено для stateful-сервисов. Впрочем, вы можете применить VPA и для модулей без сохранения состояния, если нужно автоматически скорректировать объем изначально выделенных ресурсов.
VPA также реагирует на события OOM (out of memory, недостаточно памяти). Для изменения процессорного времени и объема памяти требуется перезапуск pod'ов. При перезапуске VPA соблюдает бюджет распределения (pods distribution budget, PDB [8]), чтобы гарантировать минимально необходимое количество модулей.
Вы можете установить минимальный и максимальный объем ресурсов для каждого модуля. Так, можно ограничить максимальный объем выделяемой памяти пределом в 8 ГБ. Это полезно, если текущие узлы точно не могут выделить более 8 ГБ памяти на контейнер. Подробные спецификации и механизм работы описаны в официальном вики VPA [9].
Кроме того, у VPA есть интересная функция рекомендаций (VPA Recommender). Она отслеживает использование ресурсов и события OOM всех модулей, чтобы предложить новые значения памяти и процессорного времени на основе интеллектуального алгоритма с учетом исторических метрик. Также есть API-интерфейс, который принимает дескриптор pod и отдает предлагаемые значения ресурсов.
Стоит отметить, что VPA Recommender не отслеживает «лимит» ресурсов. Это может привести к тому, что модуль монополизирует ресурсы внутри узлов. Лучше установить предельное значение на уровне пространства имен, чтобы избежать огромного расхода памяти или процессорного времени.
Высокоуровневая схема работы VPA:
VPA добавляет необходимое количество ресурсов
Учитывайте следующие моменты при использовании VPA:
Автомасштабирование кластера (Cluster Autoscaler, CA) изменяет количество узлов, исходя из количества ожидающих модулей pod. Система периодически проверяет наличие ожидающих модулей — и увеличивает размер кластера, если требуется больше ресурсов и если кластер не выходит за пределы установленных лимитов. CA взаимодействует с поставщиком облачных услуг, запрашивает у него дополнительные узлы или освобождает бездействующие. Первая общедоступная версия CA была представлена в Kubernetes 1.8.
Высокоуровневая схема работы СA:
Автоматическое выделение узлов кластера в облаке
Учитывайте следующее при использовании СA:
Для идеальной гармонии следует применить автомасштабирование и на уровне pod'ов (HPA/VPA), и на уровне кластера. Они относительно просто взаимодействуют между собой:
Совместная система систем масштабирования Kubernetes
Существует несколько типичных проблем, с которыми девопсы сталкиваются, когда пытаются применить автомасштабирование.
HPA и VPA зависят от метрик и некоторых исторических данных. Если выделено недостаточно ресурсов, модули будут свернуты и не смогут генерировать метрики. В этом случае автомасштабирование никогда не состоится.
Сама операция масштабирования чувствительна ко времени. Нам хочется, чтобы модули и кластер масштабировались быстро — до того, как пользователи заметят какие-то проблемы и сбои. Поэтому следует учитывать среднее время масштабирования pod'ов и кластера.
Идеальный сценарий — 4 минуты:
Худший (более реалистичный) сценарий — 12 минут:
Не путайте механизмы масштабирования облачных провайдеров с нашей CA. Последняя работает внутри кластера Kubernetes, в то время как механизм облачного провайдера работает на основе распределения узлов. Он не знает, что происходит с вашими pod'ами или приложением. Эти системы работают параллельно.
Автор: pxeno
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/344246
Ссылки в тексте:
[1] словам разработчиков системы: https://speakerdeck.com/thockin/everything-you-ever-wanted-to-know-about-resource-scheduling-dot-dot-dot-almost
[2] Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler, and Vertical Pod Autoscaler: https://www.magalix.com/blog/kubernetes-autoscaling-101
[3] Kubernetes aaS от Mail.ru: https://mcs.mail.ru/containers/
[4] Kubernetes: https://mcs.mail.ru/blog/kubernetes-for-much-stuff
[5] пользовательских метрик: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics
[6] сочетания: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-multiple-metrics
[7] внешних метрик: https://cloud.google.com/kubernetes-engine/docs/tutorials/external-metrics-autoscaling
[8] pods distribution budget, PDB: https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
[9] официальном вики VPA: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/vertical-pod-autoscaler.md
[10] известных ограничениях: https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#known-limitations-of-the-alpha-version
[11] планах разработки: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/vertical-pod-autoscaler.md#future-work
[12] Источник: https://habr.com/ru/post/484344/?utm_campaign=484344&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.