Администраторы Kubernetes могут динамически масштабировать реплики модулей для адаптации к изменяющимся рабочим нагрузкам, обеспечивая эффективное использование ресурсов, снижение затрат и надёжную работу приложений.
Kubernetes превосходно упрощает масштабирование рабочей нагрузки, позволяя приложениям, обычно размещаемым в подах, базовом ресурсе Kubernetes, динамически адаптироваться к меняющимся требованиям. Эта возможность крайне важна для поддержания производительности и экономической эффективности при меняющихся рабочих нагрузках.
Масштабирование пода подразумевает корректировку количества реплик пода (по сути, идентичных копий пода), работающих в любой момент времени. При развёртывании рабочей нагрузки в Kubernetes администраторы могут указать начальное количество реплик пода для запуска. По мере изменения требований они могут увеличивать или уменьшать количество реплик без необходимости повторного развёртывания пода с нуля. Такая гибкость гарантирует, что приложения смогут справляться с возросшими требованиями за счёт добавления реплик для распределения нагрузки, а масштабирование в периоды низкого спроса предотвращает ненужное расходование ресурсов и снижает затраты.
Однако масштабирование модулей — задача не из простых. По умолчанию Kubernetes требует от администраторов:
-
Масштабируйте модули вручную с помощью команды kubectl scale или
-
Настройте механизмы автоматического масштабирования, такие как горизонтальное автоматическое масштабирование Pod (HPA).
Два способа масштабирования Pod в Kubernetes
Как уже отмечалось, Kubernetes предлагает два основных метода масштабирования модулей: ручное масштабирование и автоматизированное масштабирование.
1. Ручное масштабирование Pod
Для ручного масштабирования администраторы используют команду kubectl scale, чтобы настроить количество реплик, назначенных модулю.
Например, чтобы установить количество реплик равным четырем, выполните следующую команду:
развёртывание масштаба kubectl my-deployment —replicas=4
2. Автоматизированное масштабирование Pod
Управление десятками, а то и сотнями модулей вручную быстро становится сложной задачей. Kubernetes упрощает этот процесс с помощью функции горизонтального автоматического масштабирования модулей, которая автоматически корректирует количество реплик модулей в зависимости от потребностей приложения.
Чтобы настроить HPA, выполните следующие действия:
1. Установите сервер метрик
HPA использует Metrics Server для мониторинга использования ресурсов модуля и определения необходимости масштабирования. Настройте Metrics Server с помощью следующей команды:
kubectl apply -f https://github com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
2. Настройте автомасштабирование
Используйте команду kubectl autoscale для определения условий масштабирования. Например, следующая команда настраивает Kubernetes для поддержания загрузки ЦП на уровне 60% для развёртывания с именем my-deployment и количеством реплик от 2 до 10:
развёртывание kubectl autoscale my-deployment —cpu-percent=60 —min=2 —max=10
При такой конфигурации HPA будет автоматически изменять количество реплик (в диапазоне от 2 до 10 реплик) в зависимости от изменений в загрузке ЦП.
Хотя HPA является мощным инструментом для балансировки производительности модуля с нагрузкой приложений, он не гарантирует, что желаемые условия будут всегда поддерживаться.
В примере выше:
-
Если загрузка ЦП резко возрастет, Kubernetes может оказаться не в состоянии добавлять реплики достаточно быстро, чтобы поддерживать уровень загрузки вблизи целевого значения (например, 60%).
-
Аналогичным образом загрузка ЦП может превысить желаемый порог, если максимальное количество реплик недостаточно для удовлетворения спроса.
Несмотря на эти ограничения, автоматическое масштабирование подов остаётся ценным способом балансировки производительности подов с нагрузкой без необходимости частого ручного масштабирования. Однако внедрение инструментов мониторинга и наблюдения Kubernetes крайне важно для выявления и устранения проблем с производительностью подов, которые могут возникнуть даже при использовании автоматического масштабирования.
Бессменный главный редактор, в незапамятные времена работал в издании РБК
