Как работает автомасштабирование Kubernetes? Это вопрос, который нам часто задают в последнее время.
Итак, в этой статье объясняется, как работает функция автоматического масштабирования Kubernetes и какие преимущества она может дать при масштабировании кластера.
Что такое автомасштабирование
Представьте, что вы наполняете 2 ведра с помощью крана. Мы хотим убедиться, что вода начинает заполнять второе ведро, когда первое ведро заполнено на 80%. Решение простое, просто установите трубное соединение между двумя ковшами в соответствующем месте. И когда мы хотим увеличить количество воды, нам нужно только увеличить таким образом ведро.
То же самое относится и к нашим приложениям или услугам: функция эластичного масштабирования облачных вычислений освобождает нас от ручной настройки физических серверов/виртуальных машин. Тогда сравните "воду в ведрах" с "потреблением вычислительных ресурсов приложениями" -
- Buckets - единицы масштабирования - проблема объяснения того, что мы масштабируем
- Отметка 80% — метрики и триггеры для масштабирования — объясняет, когда мы масштабируемся
- Конвейер — Реализация операций масштабирования — Объяснение того, как мы масштабируем проблему
Что масштабируем?
В кластерной среде Kubernetes мы, как пользователи, обычно масштабируем две вещи:
Pods — допустим, для приложения мы запускаем реплики X. Когда запросы превышают вычислительную мощность X Pod, нам необходимо масштабировать приложение. И чтобы этот процесс работал бесперебойно, наши узлы должны иметь достаточно ресурсов для успешного планирования и выполнения этих дополнительных площадок;
Узлы — общая емкость всех узлов представляет собой емкость нашего кластера. Если потребность в рабочей нагрузке превышает эту емкость, нам необходимо добавить узлы в кластер, чтобы обеспечить эффективное планирование и выполнение рабочей нагрузки. Если поды продолжают расширяться, может возникнуть ситуация, когда доступные ресурсы узла будут исчерпаны, и нам придется добавить больше узлов, чтобы увеличить общие ресурсы, доступные на уровне кластера;
Когда масштабировать?
Как правило, мы непрерывно измеряем метрику, и когда метрика превышает пороговое значение, воздействуем на нее путем масштабирования ресурса. Например, нам может потребоваться измерить среднее потребление ЦП пода, а затем запустить операцию масштабирования, когда потребление ЦП превысит 80%.
Но одна метрика не подходит для всех вариантов использования, и метрика может различаться для разных типов приложений — для очередей сообщений в качестве метрики может использоваться количество сообщений в состоянии ожидания, для ресурсоемких приложений может использоваться потребление памяти. быть более подходящим в качестве метрики. Если бы у нас было бизнес-приложение, которое могло бы обрабатывать около 1000 транзакций в секунду для модуля заданной емкости, то мы, вероятно, выбрали бы этот показатель и масштабировали его, когда количество модулей превысило бы 850.
Выше мы рассмотрели только часть масштабирования, но когда использование рабочей нагрузки падает, должен быть способ скромно уменьшить масштаб, не нарушая обработку существующих запросов.
Как увеличить?
Для подов просто измените количество реплик в репликации; для узлов нам нужен способ вызвать API поставщика услуг облачных вычислений, чтобы создать новый экземпляр и сделать его частью кластера.
Kubernetes Autoscaling
Основываясь на вышеизложенном, давайте взглянем на конкретную реализацию и технологию автомасштабирования Kubernetes.
Cluster Autoscaler
Автомасштабирование кластера используется для динамического масштабирования кластера (узлов). Его функция заключается в постоянном мониторинге модулей. Если модули не могут быть запланированы, он будет основан наPodConditoinрасширять. Этот метод намного эффективнее, чем просмотр процентного соотношения ЦП в кластере. Поскольку для создания узлов требуется минута или больше (в зависимости от таких факторов, как поставщики услуг облачных вычислений), планирование модулей может занять некоторое время.
Внутри кластера у нас может быть несколько пулов узлов, например, пул узлов для биллинговых приложений и другой пул узлов для рабочих нагрузок машинного обучения. Cluster Autoscaler предоставляет различные флаги и методы для настройки масштабирования узлов. Дополнительные сведения см. на странице https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md.
Для уменьшения масштаба средство автомасштабирования кластера смотрит на среднее использование узлов и учитывает другие соответствующие факторы, например, если на узле, который нельзя перепланировать, работают поды (бюджет разрушения пода), то этот узел нельзя удалить из кластера. Custer Autoscaler позволяет корректно завершать работу узлов, обычно перемещая модули в течение 10 минут.
Горизонтальное автомасштабирование Pod (HPA)
HPA — это цикл управления, который отслеживает и масштабирует модули в развертывании. Это можно сделать, создав объект HPA, который ссылается на контроллер развертывания/релокации. Мы можем определить пороговые значения, а также верхние и нижние пределы для масштабирования развертывания. Самая ранняя версия HPA, GA (autoscaling/v1), поддерживает только ЦП в качестве отслеживаемой метрики. Текущая версия HPA находится в стадии бета-тестирования (autoscaling/v2beta1) для поддержки памяти и других пользовательских показателей. Как только объект HPA создан и он может запрашивать метрики модуля, вы можете видеть, что он сообщает подробности:
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
helloetst-ownay28d Deployment/helloetst-ownay28d 8% / 60% 1 4 1 23h
Мы можем внести некоторые коррективы в автомасштабирование горизонтального пода, добавив флаги в диспетчер контроллеров:
- Используйте флаги
-horizontal-pod-autoscaler-sync-periodОпределяет, как часто hPa отслеживается для показателей группы Pods. Период по умолчанию составляет 30 секунд. - Интервал по умолчанию между двумя операциями расширения составляет 3 минуты, который можно контролировать с помощью флагов.
-horizontal-pod-autoscaler-upscale-delay - Интервал по умолчанию между двумя операциями уменьшения составляет 5 минут, что также можно контролировать с помощью флагов.
-horizontal-pod-autoscaler-downscale-delay
Метрики и облачные провайдеры
Для измерения метрик сервер должен включить Heapster или включить агрегацию API вместе с пользовательскими метриками Kubernetes (https://github.com/kubernetes/metrics). Сервер метрик API является предпочтительным методом для Kubernetes версии 1.9 и выше. Для настройки узлов мы должны включить и настроить соответствующего облачного провайдера в кластере, см. https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/ для получения дополнительной информации.
некоторые плагины
Есть также несколько очень хороших плагинов, таких как -
- Vertical pod autoscaler https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
- addon-resizer https://github.com/kubernetes/autoscaler/tree/master/addon-resizer
В общем, в следующий раз, когда кто-нибудь спросит «как работает автомасштабирование Kubernetes»? Надеюсь, эта короткая статья поможет вам объяснить.
Снова время рекламы
Ряд концептуальных абстракций, предложенных Kubernetes, очень согласуется с идеальной распределенной системой планирования. Однако большое количество сложных технических концепций также сформировало крутую кривую обучения, что напрямую повысило порог использования Kubernetes.
Rainbond, PaaS с открытым исходным кодом Nimbus Cloud, упаковывает эти технические концепции в приложения «Production-Ready», которые можно использовать в качестве панели Kubernetes, и разработчики могут использовать ее без специального обучения. Включая эластичное масштабирование в этой статье, Rainbond поддерживает пользователей для горизонтального и вертикального масштабирования :)
Кроме того, сам Kubernetes является инструментом оркестрации контейнеров и не предоставляет процессов управления, в то время как Rainbond предоставляет готовые процессы управления, включая DevOps, автоматизированную эксплуатацию и обслуживание, микросервисную архитектуру и рынок приложений, которые можно использовать «из коробки».
Узнайте больше: https://www.goodrain.com/scene/k8s-docker
Рейнбонд Гитхаб: https://github.com/goodrain/rainbond