Автоматическое масштабирование для рабочих нагрузок Kubernetes
Автоматическое масштабирование Kubernetes автоматически регулирует ваши рабочие нагрузки для удовлетворения спроса, экономя затраты и повышая производительность. Оно использует две основные стратегии:
- Горизонтальное автомасштабирование Pod (HPA): Добавляет или удаляет реплики модулей для приложений без сохранения состояния, таких как веб-сервисы.
- Вертикальное автоматическое масштабирование Pod (VPA): Настраивает ЦП/память для существующих модулей, идеально подходит для приложений с отслеживанием состояния, таких как базы данных.
Продвинутые методы, такие как КЕДА масштабировать на основе внешних событий и Кластерный пропорциональный автомасштабатор (CPA) масштабируется с размером кластера. Объединение этих стратегий обеспечивает эффективное использование ресурсов и стабильную производительность.
Краткий обзор
- HPA: Лучше всего подходит для нестабильных объемов трафика, масштабирует модули.
- ВПА: Оптимизирует использование ресурсов, масштабирует ресурсы на модуль.
- КЕДА: Масштабирование на основе событий, поддерживает масштабирование до нуля.
- CPA: Масштабирование инфраструктурных услуг по мере роста кластера.
Выбирайте на основе архитектуры вашего приложения и потребностей в масштабировании для лучшего управления расходами и надежности.
Объяснение горизонтального автомасштабирования Pod (HPA)
Как работает горизонтальное автомасштабирование Pod
Горизонтальное автомасштабирование Pod (HPA) работает через контур управления, который постоянно отслеживает метрики и соответствующим образом корректирует количество реплик Pod. Контроллер HPA регулярно проверяет метрики, такие как использование ЦП, потребление памяти, скорость запросов или даже внешние сигналы, чтобы определить, требуется ли масштабирование. Если используется несколько метрик, HPA оценивает их все и масштабирует на основе метрики, которая указывает на самый высокий спрос. По умолчанию он допускает вариацию метрик 10%, но это можно настроить с помощью --горизонтальный-pod-автомасштабирование-допуск аргумент в kube-controller-manager.
HPA также интегрируется с агрегированными API, такими как metrics.k8s.io (обычно предоставляется Metrics Server), custom.metrics.k8s.io, и внешние.метрики.k8s.ioЭти источники данных позволяют HPA динамически реагировать на изменения рабочей нагрузки, гарантируя соответствие ресурсов спросу.
Лучшие варианты использования HPA
HPA отлично работает в ситуациях, когда распределение рабочих нагрузок по нескольким экземплярам повышает производительность. Например, в архитектурах микросервисов каждый сервис может масштабироваться независимо в зависимости от своих шаблонов трафика. Веб-приложения, которые испытывают колебания трафика, могут использовать HPA для динамического масштабирования внутренних сервисов, обеспечивая плавный пользовательский опыт в часы пик.
Он также хорошо подходит для пакетной обработки заданий, где модули могут масштабироваться для обработки больших пакетов данных, а затем уменьшаться после завершения работы. Другие идеальные сценарии включают конвейеры CI/CD, приложения IoT и системы потоковой передачи данных, где скорость приема данных может значительно различаться. Во всех этих случаях HPA помогает поддерживать постоянную производительность без избыточного выделения ресурсов.
Настройка HPA в Kubernetes

Чтобы максимально использовать HPA, необходима правильная настройка. Начните с установки Kubernetes Metrics Server, чтобы обеспечить точные данные в реальном времени об использовании ЦП и памяти. Определите запросы и ограничения ресурсов pod, чтобы установить четкие базовые показатели использования, и удалите спец.реплики поле из манифестов модуля, чтобы избежать конфликтов с HPA.
Установите реалистичные минимальные и максимальные значения количества реплик, чтобы соблюсти баланс между производительностью и эффективностью ресурсов. Если ваш кластер использует кластерный автомасштабатор, убедитесь, что он может обрабатывать дополнительные модули во время масштабирования. Стабилизационные окна могут помочь предотвратить быстрые, ненужные колебания масштабирования.
Для более точного масштабирования рассмотрите возможность использования пользовательских метрик, таких как частота запросов или длина очереди. Регулярно отслеживайте производительность и корректируйте пороговые значения на основе фактического поведения рабочей нагрузки. Такие инструменты, как Kubernetes Event-Driven Autoscaling (KEDA), также могут дополнять HPA, обеспечивая масштабирование на основе событий для более сложных сценариев.
Объяснение вертикального автомасштабирования Pod (VPA)
Как работает вертикальное автомасштабирование Pod
Vertical Pod Autoscaling (VPA) точно настраивает ресурсы ЦП и памяти, выделенные отдельным контейнерам в pod, а не увеличивает или уменьшает количество реплик pod. Анализируя как исторические, так и реальные метрики, VPA динамически корректирует запросы ресурсов и ограничения для лучшего соответствия фактическому использованию.
Система VPA состоит из трех основных компонентов:
- Рекомендатель: этот компонент отслеживает показатели, сохраняя исторические данные за период до восьми дней для определения закономерностей использования и формирования рекомендаций по ресурсам.
- Обновление: Он оценивает, требуют ли модули корректировки ресурсов, и при необходимости инициирует изменения.
- Контролер приема: Это применяет обновленные настройки ресурсов каждый раз при создании или перезапуске модуля.
VPA работает в трех режимах:
- Выключенный: Предоставляет рекомендации без внесения каких-либо изменений.
- Исходный: Устанавливает запросы ресурсов и ограничения только при запуске модуля.
- Авто: Постоянно корректирует ресурсы, требуя перезапуска модуля для вступления изменений в силу.
Например, если контейнер настроен на запрос 64 Мбайт памяти и 250 Мбайт ЦП, но регулярно использует 120 Мбайт и 450 Мбайт ЦП, VPA может настроить память на 128 Мбайт/256 Мбайт, а ЦП — на 500 Мбайт/1 ЦП, чтобы лучше соответствовать фактическим потребностям.
Когда использовать VPA
VPA отлично подходит для ситуаций, когда масштабирование (добавление реплик) нецелесообразно. Например, приложения с отслеживанием состояния как базы данных часто сталкиваются с проблемами горизонтального масштабирования из-за требований к согласованности данных и синхронизации. VPA гарантирует, что эти приложения получат необходимое количество ресурсов без ручной настройки.
Он также отлично подходит для приложения с одним экземпляром которые из-за архитектурных ограничений или ограничений лицензирования должны работать как единый модуль. VPA упрощает управление ресурсами, избегая рисков избыточного или недостаточного выделения ресурсов.
Для пакетная обработка заданий или же рабочие нагрузки анализа данных, где потребности в ресурсах могут значительно различаться в зависимости от сложности задач или размера данных, VPA динамически регулирует ресурсы. Это означает, что вам не придется выделять слишком много ресурсов для пиковых сценариев, что приводит к повышению эффективности кластера.
Приложения с непредсказуемые потребности в ресурсах, например, задания по обучению машинному обучению, также выигрывают от VPA. Адаптируясь к изменяющимся требованиям на разных этапах рабочей нагрузки, VPA помогает поддерживать постоянную производительность без ручного вмешательства.
Проблемы и ограничения VPA
Хотя VPA предлагает множество преимуществ, у него есть и свои проблемы. Одним из основных ограничений является его несовместимость с Horizontal Pod Autoscaling (HPA), когда оба настроены на управление ЦП или памятью. Если оба используются одновременно, они могут принимать противоречивые решения, что может дестабилизировать рабочую нагрузку.
Другим недостатком является то, что в автоматическом режиме VPA требует перезапуска модулей для вступления в силу изменений ресурсов. Это может привести к временным перебоям в обслуживании, что делает его менее подходящим для приложений, требующих бесперебойной доступности или имеющих длительное время запуска.
Метрики VPA сосредоточены исключительно на ЦП и памяти. Они не учитывают другие факторы, такие как сетевой ввод-вывод, использование диска или пользовательские метрики приложений. Кроме того, его восьмидневного окна исторических данных может быть недостаточно для рабочих нагрузок с долгосрочными или сезонными закономерностями.
Определение минимальных и максимальных пределов ресурсов имеет решающее значение. Без этих границ VPA может выделять избыточные ресурсы во время краткосрочных пиков или не обеспечивать их в достаточном объеме во время устойчивого роста спроса.
Для достижения наилучших результатов начинайте осторожно. Используйте Выключенный или же Исходный режим сначала, чтобы оценить рекомендации VPA. Как только вы будете уверены в его корректировках, рассмотрите возможность перехода в режим Auto. Всегда внимательно следите за производительностью после изменений и согласовывайте обновления с графиком развертывания, чтобы свести к минимуму сбои.
Расширенные методы автоматического масштабирования для Kubernetes
Пропорциональный автомасштабатор кластера
The Кластерный пропорциональный автомасштабатор (CPA) настраивает реплики pod на основе размера кластера, а не использования ресурсов. Этот метод особенно полезен для инфраструктурных служб, которые необходимо расширять по мере роста кластера.
В отличие от других автомасштабаторов, которые полагаются на Metrics API или Metrics Server, CPA использует простой цикл управления. Он отслеживает размер кластера и корректирует реплики в соответствии с конфигурацией, заданной в ConfigMap. Типичным примером является масштабирование CoreDNS. Например, если ваш кластер вырастает с 2 до 5 узлов, CPA пропорционально увеличивает количество реплик CoreDNS, чтобы справиться с возросшим спросом на разрешение DNS.
CPA может масштабировать реплики либо линейно, либо по предопределенным пороговым значениям, проверяя каждые 10 секунд, чтобы обеспечить быструю корректировку по мере изменения кластера. Это делает его особенно эффективным для таких приложений, как агенты мониторинга или сборщики журналов, которым требуется единообразное покрытие по всем узлам.
В то время как CPA фокусируется на масштабировании за счет размера кластера, есть еще один метод, который успешно реагирует на внешние триггеры.
Масштабирование на основе событий с помощью KEDA

The Управляемое событиями автомасштабирование Kubernetes (KEDA) использует другой подход, масштабируя рабочие нагрузки на основе внешних событий, а не традиционных показателей ЦП или памяти. Это обеспечивает точное масштабирование для задач, управляемых событиями, включая возможность масштабирования до нуля во время периодов простоя, что экономит ресурсы.
KEDA легко интегрируется с Kubernetes, передавая внешние данные о событиях в систему и дополняя Horizontal Pod Autoscaler (HPA). Он не заменяет HPA, но расширяет его возможности.
KEDA поддерживает более 70 встроенных масштабаторов, которые подключаются к различным облачным платформам, базам данных, системам обмена сообщениями и инструментам CI/CD. Например, компания по обработке данных, использующая KEDA, может масштабировать свои модули веб-приложений на основе глубины очереди AWS SQS. Аналогично, StatefulSet, обрабатывающий потоки Kafka, может масштабироваться для обработки возросших объемов сообщений. Пакетные задания, генерирующие отчеты, могут использовать метрики Prometheus для масштабирования на основе ожидающих оценок. Способность KEDA к масштабированию до нуля особенно полезна для спорадических рабочих нагрузок, таких как обработчики веб-перехватчиков или запланированные задачи.
КЕДА использует Определения пользовательских ресурсов (CRD) для определения правил масштабирования. Вы можете настроить несколько источников событий, установить пороговые значения и определить периоды охлаждения, чтобы избежать быстрых колебаний масштабирования. Такая гибкость делает KEDA надежным выбором как для облачных, так и для периферийных развертываний без необходимости внешних зависимостей.
Объединение нескольких стратегий масштабирования
Управление сложными рабочими нагрузками часто требует сочетания стратегий масштабирования. Объединив CPA, KEDA и HPA/VPA, вы можете создать более динамичную и эффективную систему масштабирования. Задача заключается в том, чтобы обеспечить бесперебойную совместную работу этих систем, а не конкурировать друг с другом.
Например, вы можете настроить HPA для использования пользовательских метрик приложений, в то время как VPA фокусируется на корректировках ЦП и памяти. KEDA также может интегрироваться с HPA, предоставляя внешние метрики, что позволяет вам масштабировать на основе глубины очереди, при этом по-прежнему используя HPA для масштабирования на основе ЦП.
Для решения проблемы пропускной способности узла Автомасштабирование кластера играет решающую роль. Когда VPA увеличивает запросы ресурсов или HPA масштабирует реплики, Cluster Autoscaler обеспечивает достаточное количество узлов для размещения этих изменений. Расширенные настройки могут объединять CPA для инфраструктурных служб, KEDA для задач, управляемых событиями, и HPA для пользовательских приложений для удовлетворения различных потребностей рабочей нагрузки.
Реализация гибридных стратегий масштабирования требует тщательного планирования и мониторинга. Начните с развертывания одного метода и наблюдения за его производительностью. Постепенно добавляйте дополнительные стратегии, обеспечивая наличие периодов охлаждения для предотвращения быстрых колебаний. Регулярно просматривайте показатели и действия масштабирования для выявления и устранения конфликтов или неэффективности. Такой подход гарантирует, что ваша система масштабирования будет эффективно развиваться по мере роста ваших приложений и инфраструктуры.
sbb-itb-59e1987
Преимущества автоматического масштабирования и эксплуатационные эффекты
Основные преимущества автоматического масштабирования
Автоматическое масштабирование преобразует управление рабочими нагрузками Kubernetes, предлагая лучший контроль затрат, стабильную производительность и более плавные операции. Речь идет не только об управлении ресурсами — речь идет о создании масштабируемых, надежных приложений.
Одним из главных преимуществ является оптимизация ресурсов. Cloud Native Computing Foundation (CNCF) сообщает, что, хотя 79% организаций используют Kubernetes в производственной среде, большинство развертываний используют только 20–30% запрошенных ЦП и 30–40% запрошенной памяти.
«Автомасштабирование в Kubernetes — это процесс, который динамически регулирует вычислительные ресурсы в соответствии с потребностями приложения в реальном времени». — Бен Грейди, ScaleOps
Еще одним ключевым преимуществом является снижение затрат. Исследования Flexera показывают, что интеллектуальное масштабирование может сократить расходы на облако более чем на 30%. Кроме того, данные Datadog показывают, что более 65% отслеживаемых контейнеров используют менее половины запрошенных ресурсов ЦП и памяти, что демонстрирует потенциал значительной экономии при правильном автоматическом масштабировании.
Автоматическое масштабирование также обеспечивает надежность производительности. Поддерживая постоянное время отклика во время пиков трафика и распределяя рабочие нагрузки между несколькими экземплярами, системы остаются доступными и отзывчивыми даже во время внезапных скачков спроса.
Окончательно, эффективность работы улучшается с помощью автоматического масштабирования. Автоматизируя корректировку ресурсов, команды DevOps могут сосредоточиться на задачах разработки вместо ручного масштабирования. Эта автоматизация также улучшает видимость как затрат, так и мощности, делая управление ресурсами менее головной болью.
Сравнение HPA, VPA и расширенных методов
Различные методы автоматического масштабирования удовлетворяют различные потребности рабочей нагрузки. Выбор правильного подхода может точно настроить среду Kubernetes и максимизировать эффективность.
| Метод | Лучшее для | Преимущества | Ограничения |
|---|---|---|---|
| HPA | Веб-приложения, API, микросервисы | Быстро реагирует на изменения дорожного движения, надежен, прост в настройке | Ограничено масштабированием реплик; лучше всего работает с предсказуемыми шаблонами использования ресурсов |
| ВПА | Пакетные задания, обработка данных, ресурсоемкие задачи | Оптимизирует ресурсы модуля, снижает избыточное выделение ресурсов | Может перезапускать модули; не подходит для приложений с отслеживанием состояния |
| CA (автоматическое масштабирование кластера) | Инфраструктурные услуги, системные компоненты | Масштабируется в зависимости от размера кластера, легко настраивается | Опирается на показатели размера кластера; менее гибкий, чем другие методы |
| КЕДА | Рабочие нагрузки, управляемые событиями, обработка очередей | Масштабируется до нуля, поддерживает более 70 внешних масштабаторов, справляется с нерегулярными рабочими нагрузками | Требуются внешние зависимости, более сложная настройка |
HPA идеально подходит для рабочих нагрузок с предсказуемыми шаблонами трафика, такими как веб-приложения или API. Он настраивает реплики pod на основе таких метрик, как использование ЦП и памяти, обеспечивая плавное масштабирование при регулярных колебаниях трафика.
ВПА лучше подходит для задач, которым нужны оптимизированные ресурсы pod, а не масштабирование. Например, пакетные задания обработки или задачи с большим объемом данных и различными потребностями в ресурсах выигрывают от этого подхода.
Продвинутые методы, такие как KEDA excel в системах, управляемых событиями. В отличие от традиционного масштабирования на основе показателей ЦП или памяти, KEDA использует такие сигналы, как глубина очереди или скорость сообщений, что делает его идеальным для спорадических рабочих нагрузок или событийных приложений.
Как инфраструктура хостинга поддерживает автоматическое масштабирование
Сильный хостинговая инфраструктура является основой эффективного автоматического масштабирования. Без надежной поддержки даже самые лучшие стратегии масштабирования могут оказаться неудачными.
Глобальная инфраструктура играет решающую роль в обеспечении быстрого времени отклика, независимо от того, где находятся пользователи. Для приложений, работающих в нескольких регионах, надежная сетевая магистраль имеет важное значение для поддержания производительности. Такие поставщики, как Serverionблагодаря соединениям с малой задержкой и избыточным путям обеспечивается плавное масштабирование операций и минимальное время простоя.
Управляемые услуги упрощают сложности автоматического масштабирования. Вместо того, чтобы жонглировать управлением инфраструктурой, команды могут сосредоточиться на тонкой настройке политик масштабирования и мониторинге производительности. Например, Serverion управляемые услуги хостинга управлять уровнем инфраструктуры, чтобы решения о масштабировании выполнялись бесперебойно.
Доступность ресурсов — еще один критический фактор. Платформа хостинга должна предоставлять достаточно процессора, памяти и хранилища в зонах доступности для обработки требований масштабирования без ущерба для производительности.
И наконец, инструменты мониторинга и наблюдения Интегрированные в платформу хостинга жизненно важны. Эти инструменты отслеживают использование ресурсов, производительность приложений и события масштабирования, помогая командам со временем совершенствовать свои политики масштабирования.
В сочетании с грамотно настроенной стратегией автоматического масштабирования надежная инфраструктура хостинга гарантирует, что приложения смогут справляться с непредсказуемым спросом, оставаясь при этом экономически эффективными и стабильно производительными.
Заключение
Выбор правильного метода автоматического масштабирования
Выбор лучшего подхода к автоматическому масштабированию начинается с понимания конкретных потребностей вашего приложения и принципов его работы.
Начните с оценки требований к ресурсам вашего приложения. Проанализируйте свою рабочую нагрузку, чтобы определить узкие места в ресурсах. Для веб-трафика без сохранения состояния Horizontal Pod Autoscaler (HPA) — надежный выбор, а Vertical Pod Autoscaler (VPA) хорошо подходит для рабочих нагрузок с различными требованиями к ресурсам. Сопоставьте триггеры масштабирования с фактическими узкими местами, а не только с общими метриками, такими как использование ЦП.
Подумайте о своей потребности в автоматизации и своей терпимости к сложности. HPA прост в настройке и хорошо работает для большинства сценариев. С другой стороны, такие инструменты, как KEDA, предлагают масштабирование на основе событий с большей гибкостью, но при этом имеют дополнительную сложность и зависимость от внешних систем.
Рассмотрите возможность объединения HPA и VPA там, где это уместно. Каждый метод решает различные задачи масштабирования, а их совместное использование может удовлетворить более широкий спектр потребностей — просто убедитесь, что их корректировки не конфликтуют.
«С помощью автоматического масштабирования вы можете автоматически обновлять свои рабочие нагрузки тем или иным способом. Это позволяет вашему кластеру реагировать на изменения спроса на ресурсы более эластично и эффективно». – kubernetes.io
Помня об этих моментах, вы сможете заложить прочную основу для эффективной работы.
Заключительные мысли об автоматическом масштабировании Kubernetes
После того, как вы выбрали стратегию, фокус смещается на ее реализацию и совершенствование. Автоматическое масштабирование — это то, что делает Kubernetes гибким и адаптивным.
Надежная инфраструктура — залог успешного автоматического масштабирования. Ваша хостинговая платформа должна быстро и последовательно предоставлять ресурсы при возникновении масштабируемых событий. Без прочной основы даже самые лучшие стратегии масштабирования могут оказаться неэффективными.
Регулярный мониторинг и корректировки имеют решающее значение. Настройте оповещения о непредвиденных поведениях масштабирования и регулярно проверяйте свои конфигурации. Тестируйте изменения в контролируемых средах перед их развертыванием в производстве. Следите за событиями масштабирования и данными о производительности, настраивая свои политики для поддержания оптимальной эффективности.
Отдавайте приоритет практическому исполнению. Тонкая настройка запросов и ограничений ресурсов, чтобы ваши приложения получали то, что им нужно, не тратя ресурсы впустую. Используйте надежные инструменты мониторинга для получения информации о проблемах производительности и принятия решений по масштабированию, что гарантирует бесперебойную работу вашей системы.
Управляемые хостинговые услуги Serverion и глобальная инфраструктура предлагают надежную поддержку, необходимую для эффективного автоматического масштабирования. Благодаря мощным сетевым ресурсам и интегрированным инструментам мониторинга ваша команда может сосредоточиться на оптимизации стратегий масштабирования, не беспокоясь о проблемах инфраструктуры.
При сочетании правильных методов масштабирования, надежной инфраструктуры и постоянной оптимизации автоматическое масштабирование Kubernetes становится решающим фактором, позволяя вашим приложениям легко и эффективно справляться с меняющимися требованиями.
Объяснение масштабирования с помощью Kubernetes HPA, VPA, KEDA и Cluster Autoscaler
Часто задаваемые вопросы
Когда следует использовать горизонтальное автомасштабирование Pod (HPA) или вертикальное автомасштабирование Pod (VPA) для рабочих нагрузок Kubernetes?
При выборе между Горизонтальное автомасштабирование Pod (HPA) а также Вертикальное автоматическое масштабирование Pod (VPA)все зависит от того, как работают и масштабируются ваши рабочие нагрузки.
- HPA разработан для обработки колеблющегося спроса путем увеличения или уменьшения количества реплик pod. Это делает его отличным вариантом для приложений без сохранения состояния или рабочих нагрузок, которые испытывают внезапные скачки трафика.
- ВПА, с другой стороны, фокусируется на регулировке ресурсов ЦП и памяти, выделенных для существующих pod. Он лучше подходит для приложений с сохранением состояния или рабочих нагрузок с постоянными, предсказуемыми потребностями в ресурсах.
В некоторых сценариях совместное использование HPA и VPA может обеспечить баланс, гарантируя эффективную работу среды Kubernetes.
Что следует учитывать при использовании нескольких стратегий автоматического масштабирования, таких как HPA, VPA, KEDA и CPA в Kubernetes?
При использовании стратегии автоматического масштабирования как HPA (горизонтальное автомасштабирование Pod), VPA (вертикальное автомасштабирование Pod), KEDA (событийно-управляемое автомасштабирование Kubernetes) и CPA (пользовательское автомасштабирование Pod), крайне важно обеспечить их слаженную работу, не мешая друг другу.
Каждый из этих инструментов играет определенную роль: HPA регулирует количество модулей на основе таких показателей, как использование ЦП или памяти, ВПА обрабатывает рекомендации по ресурсам или корректировки для отдельных модулей, КЕДА масштабирует рабочие нагрузки в ответ на внешние события и CPA реализует пользовательскую логику масштабирования, часто с упором на управление расходами. Чтобы все работало эффективно, убедитесь, что их конфигурации согласованы, чтобы избежать конфликтов или неустойчивого поведения масштабирования.
Также важно сбалансировать ваши требования к рабочей нагрузке с доступными ресурсами. Например, ваши политики масштабирования должны поддерживать целевые показатели производительности вашего приложения, оставаясь в рамках бюджетных ограничений. Тестирование и мониторинг необходимы для того, чтобы ваша среда Kubernetes оставалась стабильной, эффективной и хорошо оптимизированной для использования ресурсов.
Как инфраструктура хостинга влияет на производительность автоматического масштабирования Kubernetes?
Эффективность автоматического масштабирования Kubernetes во многом зависит от качества инфраструктуры хостинга. быстрая и масштабируемая инфраструктура обеспечивает быстрое распределение ресурсов, сокращает задержки и гарантирует высокую доступность — ключевые факторы для эффективной обработки колебаний рабочей нагрузки.
Однако такие проблемы, как узкие места в сети, ограниченная вычислительная мощность или нестабильная работа соединения с центром обработки данных может нарушить масштабирование, вызывая задержки, бесполезную трату ресурсов или низкую производительность приложений. Выбор хостинговых решений, которые предлагают надежные серверы, сильные сетевые соединения и глобальную сеть центров обработки данных, может значительно улучшить автоматическое масштабирование, что приведет к лучшему управлению ресурсами и экономии средств.