РАЗРАБОТКА

Kubernetes 1.37: автошкалирование под нагрузкой до нуля реплик

Kubernetes 1.37 представил автошкалирование до нуля реплик. Улучшение позволяет экономить ресурсы и оптимизирует затраты на инфраструктуру.

✍️ Редакция iTech News | 23.08.2025 | ⏱ 2 мин | Источник: Kubernetes Blog
🧩

Kubernetes версии 1.37 теперь поддерживает автошкалирование нагрузок до нуля реплик с помощью HorizontalPodAutoscaler (HPA). Эта функция находится на стадии бета-тестирования и включена по умолчанию, что дает возможность оптимизировать затраты на ресурсы.

Почему это важно для разработчиков

Преимущество нового функционала заключается в том, что HPA может снижать количество реплик до нуля, когда ресурсы не используются. Ранее для этой функции требовался внешний компонент или специальная конфигурация, а теперь она доступна в основном сегменте Kubernetes. Для проектов, где Pods могут оставаться неактивными, включая системы обработки очередей и групповые обработчики, это открывает новые горизонты в части экономии затрат на дорогостоящие CPU и GPU.

Ключевые особенности нового автошкалирования

Теперь HPA умеет работать с внешними метриками, которые не зависят от работающих Pods. Например, длина очереди задач может служить таким независимым показателем. Это значит, что HPA сможет продолжать работу даже тогда, когда все рабочие экземпляры остановлены.

Чтобы задействовать новый функционал, необходимо установить метрики в формате, доступном для Kubernetes. Например, с помощью Prometheus можно создавать внешние метрики, такие как queue_consumer_lag. Доступный API позволяет интегрировать данные в автоматизацию масштабирования, что существенно упрощает управление очередями.

Вывод для ангел-инвесторов и стартапов

Для разработчиков, особенно в стартапах, внедрение такого функционала, как автошкалирование до нуля, может привести к значительной экономии на серверных мощностях. В условиях непостоянного трафика и запрашиваемых ресурсов это может снизить затраты на 30-50%. Отдельные компании также отмечают снижение времени простоя и улучшение общей производительности приложений.

Следующий шаг для разработчиков — приступить к тестированию нового функционала в своих проектах и оценить, как это может повлиять на общие затраты на инфраструктуру.

Поделиться: Telegram X LinkedIn