Как оптимизировать ресурсы Kubernetes: запросы, ограничения и автоскейлинг

Большинство команд, которые приходят к оптимизации Kubernetes, делают это после неприятного открытия: кластер работает, приложения отвечают, но счёт за инфраструктуру давно перестал соответствовать реальной нагрузке. По данным Datadog (State of Kubernetes, 2024), средняя утилизация выделенных ресурсов в кластерах составляет 18% по ЦП и 23% по памяти. Остальное — оплаченные, но неиспользуемые мощности.

Корень проблемы почти всегда один: запросы и лимиты выставлены наугад или не выставлены вовсе. А ведь грамотная настройка этих механизмов позволяет сократить расходы на инфраструктуру на 30–60% и устранить простои из-за нехватки ЦП или памяти — без увеличения бюджета.

В нашей практике развития платформы VK Cloud мы видим, как неоптимизированные кластеры приводят к перерасходу 40–60% бюджета. В этой статье разберём, как правильно настроить запросы и лимиты ресурсов, когда подключать автомасштабирование и как выстроить мониторинг, чтобы реагировать на проблемы раньше, чем они дойдут до пользователей.

Зачем оптимизировать ресурсы в Kubernetes

Без контроля ресурсов один контейнер способен забрать всё процессорное время или всю память узла, оставив соседние поды ни с чем. Вот к чему это приводит на практике:

• Перерасход бюджета. Запросы ресурсов завышены относительно реального использования, и кластер резервирует мощности, которые никто не потребляет. По данным Datadog (2024), средняя утилизация ЦП в кластерах Kubernetes составляет 18%, памяти — 23%. Разница между запросами и фактом — прямые убытки.
• Нестабильность приложений. Контейнер без лимитов памяти рано или поздно получит OOMKilled. Контейнер без лимитов ЦП начнёт троттлиться. Оба сценария ведут к деградации производительности.
• Проблемы планирования. Kubernetes использует requests при размещении подов на узлах. Если запросы завышены, планировщик считает узел занятым — и pod зависает в статусе Pending, даже когда реальных ресурсов достаточно.
• Каскадные отказы. «Шумный сосед» без лимитов вытесняет соседние поды с узла. Нагрузка перераспределяется на оставшиеся, они не выдерживают — и отказ расползается по кластеру.

Запросы стоит пересматривать регулярно: нагрузка на приложения меняется, и то, что было точной настройкой три месяца назад, сегодня может оказаться источником проблем.

Основы ресурсов Kubernetes. CPU, память и сетевые ресурсы

Kubernetes управляет тремя категориями ресурсов каждого контейнера: процессорным временем (CPU), оперативной памятью (memory) и сетевыми ресурсами.

CPU измеряется в миллиярдах (millicores): одно ядро процессора равно 1000m, запрос cpu: 500m резервирует половину ядра. Лимит ЦП работает через механизм cgroups ядра Linux — при превышении контейнер получает throttling. Планировщик Kubernetes не разместит pod на узле, если запрос превышает доступные мощности. Память указывается в мебибайтах (Mi) или гибибайтах (Gi). Лимит памяти — жёсткое ограничение: превышение немедленно приводит к OOMKilled. Здесь важно отличие от CPU: превышение лимита cpu замедляет приложение, превышение лимита memory завершает процесс.

Сетевые ресурсы Kubernetes не лимитирует по умолчанию, но QoS и сетевые политики позволяют управлять приоритетом трафика и полосой пропускания.

Запросы и ограничения

Запросы (requests) — минимальный объём ресурсов, гарантированный контейнеру. Планировщик использует их при выборе узла для pod. Если на узле есть свободные ресурсы сверх запроса, контейнер может их использовать.

Ограничения (limits) — максимальный объём. Kubelet принудительно соблюдает их через cgroups: превышение по ЦП даёт throttling, по памяти — OOMKilled.

resources:
  requests:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"

Если задать limits без requests, Kubernetes скопирует limits в requests автоматически. Это распространённая ошибка: контейнер резервирует максимальный объём ресурсов и блокирует их для соседних подов.

Управление ресурсами на уровне namespace

ResourceQuota задаёт ограничения на суммарные ресурсы в namespace: запросы и лимиты ЦП и памяти, количество подов. Это защищает кластер от ситуации, когда одна команда занимает все доступные мощности. LimitRange устанавливает значения по умолчанию для контейнеров, у которых разработчик не указал запросы или ограничения. Без LimitRange такой контейнер запустится без каких-либо ограничений — и станет потенциальным источником проблем. LimitRange также задаёт минимальный и максимальный объём ЦП и памяти для одного контейнера.

Вместе ResourceQuota и LimitRange дают контроль над ресурсами на уровне namespace без необходимости вручную проверять каждый деплоймент.

Управление ресурсами контейнеров. Предотвращение OOMKilled

OOMKilled возникает, когда контейнер потребляет больше памяти, чем указано в limits. Ядро Linux принудительно завершает процесс, контейнер перезапускается и прерывает обработку запросов. По данным CNCF Survey (2024), проблемы с памятью входят в топ-3 причин инцидентов в Kubernetes.

Чаще всего это происходит по одной из трёх причин.

• Лимит ниже реального потребления. Приложение на Java с heap 512 МБ фактически требует минимум 768 МБ с учётом non-heap. Лимит в 512Mi в таком случае гарантирует регулярные перезапуски.
• Утечка памяти. При росте нагрузки память потребляется, но не освобождается. Увеличение лимита здесь не поможет — нужно профилировать приложение и искать причину утечки.
• Отсутствие лимитов. Контейнер без ограничений памяти занимает все ресурсы узла и роняет соседние поды.

Устанавливайте лимит памяти на 20–30% выше среднего потребления и опирайтесь на метрики за 7–14 дней, а не на интуицию.

QoS-классы и настройка лимитов

Соотношение запросов и ограничений определяет QoS-класс pod, который влияет на приоритет вытеснения при нехватке ресурсов.

• Guaranteed — запросы равны ограничениям по ЦП и памяти для всех контейнеров. Такие поды вытесняются последними. Подходит для баз данных и платёжных модулей.
• Burstable — запросы установлены, ограничения выше. Контейнеры могут использовать дополнительные ресурсы, если узел позволяет. Подходит для веб-приложений и микросервисов.
• BestEffort — ни запросов, ни ограничений. Вытесняются первыми при любой нехватке ресурсов. Только для batch-задач, где прерывание допустимо.

Для production-приложений задавайте лимиты по профилю нагрузки: по ЦП — в 1,5–2 раза выше запроса, по памяти — в 1,2–1,5 раза. Разница обоснована механикой Kubernetes: превышение лимита ЦП замедляет контейнер, превышение лимита памяти его убивает.

В Managed Kubernetes от VK Cloud для каждой группы узлов доступны индивидуальные конфигурации: флейворы с ЦП до 64 ядер и памятью до 512 ГБ, что позволяет подобрать ресурсы узла под конкретные требования приложения.

Автоматическая оптимизация с Kubernetes Autoscale

Ручная настройка запросов и ограничений хорошо работает для стабильных нагрузок, но большинство production-приложений ведут себя иначе: трафик то растёт, то падает. Для таких случаев в Kubernetes есть три инструмента автомасштабирования.

Horizontal Pod Autoscaler (HPA) увеличивает или уменьшает количество реплик pod по метрикам. По умолчанию HPA ориентируется на загрузку ЦП, но умеет работать и с памятью, и с пользовательскими метриками. Если среднее использование ЦП превышает целевое значение, HPA добавляет реплики, при снижении — убирает лишние. Для расчёта утилизации HPA использует значения requests контейнеров.

Vertical Pod Autoscaler (VPA) корректирует сами запросы и ограничения контейнеров, опираясь на историческое потребление ресурсов. VPA анализирует метрики за 8 дней, рассчитывает оптимальные значения и применяет их при пересоздании pod. Доступны три режима: Off — только рекомендации без применения, Initial — значения выставляются при создании pod, Auto — VPA обновляет запросы и ограничения для уже работающих подов.

Cluster Autoscaler управляет количеством узлов в кластере. Если запросы ресурсов подов превышают то, что кластер может предоставить, автоскейлер добавляет узел. Когда узел простаивает — вытесняет поды на другие узлы и удаляет его.

Когда применять масштабирование

В Managed Kubernetes от VK Cloud Cluster Autoscaler предустановлен и масштабирует кластер до 500 узлов и 55 000 подов. Посекундная тарификация гарантирует оплату только за реально использованные ресурсы.

Не используйте HPA и VPA для одной метрики одновременно. VPA изменит запросы и ограничения ресурсов, HPA пересчитает использование и создаст лишние реплики. Разделяйте: VPA — на memory, HPA — на cpu.

Мониторинг и профилирование нагрузки. Инструменты мониторинга

Без данных о реальном потреблении настройка запросов, лимитов и автомасштабирования превращается в угадывание. Мониторинг показывает, какие контейнеры запрашивают слишком много, а каким не хватает ограничений.

Metrics Server — базовый аддон Kubernetes, который поставляет метрики ЦП и памяти в реальном времени. Хранит данные за несколько минут — достаточно для оперативной диагностики, но не для анализа тrendов.

Prometheus + Grafana — стандартная связка для мониторинга кластера. Prometheus собирает метрики с kubelet, cAdvisor и kube-state-metrics, Grafana визуализирует потребление ресурсов по контейнерам, подам и узлам. Именно здесь видно, у каких контейнеров запросы сильно расходятся с фактическим потреблением.

cAdvisor — встроенный модуль kubelet, который собирает метрики ресурсов контейнеров: ЦП, память, использование диска. Prometheus забирает данные напрямую из него.

В VK Cloud встроенный мониторинг отслеживает состояние Control Plane и узлов, а Cloud Alerting отправляет уведомления о масштабировании через email, Telegram или webhook.

Анализ нагрузки

Процесс оптимизации запросов и ограничений устроен так:

1. Сбор метрик. Зафиксируйте потребление ЦП и памяти каждым pod за 7–14 дней. Prometheus-запрос
   container_memory_working_set_bytes
   показывает реальное использование памяти.
2. Сравнение запросов с фактом. Если pod запрашивает 1000m ЦП, а использует 150m с пиками до 400m — запросы завышены. Разумная настройка: request 400m, limit 800m.
3. Поиск OOMKilled. Проверьте статус контейнеров. Если причина перезапусков — OOMKilled, увеличьте лимит памяти или профилируйте приложение на предмет утечек.
4. Анализ throttling. Метрика
   container_cpu_cfs_throttled_periods_total
   показывает, сколько периодов контейнер был ограничен по ЦП. Высокие значения — сигнал пересмотреть лимиты.

Оптимизация хранения и сетевых ресурсов. Persistent Volumes

Persistent Volumes (PV) и Persistent Volume Claims (PVC) позволяют контейнерам сохранять данные между перезапусками. Несколько практических правил при работе с хранилищами:

• SSD — для приложений с высокими требованиями к производительности, HDD — для архивов
• accessModes выбирайте под задачу: ReadWriteOnce для stateful-модулей, ReadWriteMany для общего доступа
• reclaimPolicy: Retain для production-данных, чтобы не потерять том при удалении PVC
• настройте alerting на 80% заполнения диска — переполнение хранилища кладёт pod быстро и без предупреждения

В VK Cloud PVC интегрированы с блочным хранилищем и поддерживают динамическое создание и расширение томов.

Сетевые ограничения и QoS

Балансировка нагрузки между подами в Kubernetes реализуется через Service. Для более тонкого контроля над сетью есть несколько инструментов.

Network Policies задают правила сетевого доступа между подами: изоляция по namespace, ограничение входящего и исходящего трафика. Без них любой pod в кластере может обращаться к любому другому.

CNI-плагины с bandwidth-ограничениями позволяют управлять полосой пропускания на уровне контейнера — там, где QoS-классов недостаточно.

Ingress Controller с rate-limiting защищает backend от всплесков трафика. Ограничение запросов в секунду не даёт входящему потоку превысить то, что backend способен обработать.

В VK Cloud сеть построена на SDN Sprut: низкая задержка между узлами и встроенная балансировка нагрузки L4/L7. Мультизональные кластеры с распределением между тремя ЦОД обеспечивают доступность при отказе одной зоны.

Выводы и рекомендации

Несколько принципов, которые стоит держать в голове при работе с ресурсами кластера.

• Устанавливайте запросы и ограничения для каждого контейнера. Контейнер без ограничений — потенциальный источник нестабильности для всего узла. LimitRange помогает автоматически выставлять значения по умолчанию на уровне namespace, если разработчик забыл указать их явно.
• Опирайтесь на метрики, а не на интуицию. Собирайте данные о потреблении ЦП и памяти минимум 7–14 дней, прежде чем выставлять запросы. Пересматривайте значения при изменении нагрузки на приложение.
• Подключайте автомасштабирование под тип нагрузки. HPA — для stateless-приложений с переменным трафиком, VPA — для stateful, где важнее правильно подобрать ресурсы одного pod. Cluster Autoscaler управляет узлами кластера и не даёт платить за простаивающие мощности.
• Разделяйте ресурсы через namespace. ResourceQuota не позволяет одной команде или сервису занять весь кластер, распределяя доступные мощности между проектами.
• Выбирайте QoS-класс осознанно. Guaranteed — для критичных приложений, которые не должны вытесняться при нехватке ресурсов. Burstable — для большинства сервисов. BestEffort — только там, где прерывание работы допустимо.
• Настройте alerting заранее. Уведомления на OOMKilled, throttling ЦП и превышение лимитов памяти позволяют среагировать на проблему до того, как она дойдёт до пользователей.

Managed Kubernetes от VK Cloud включает предустановленный Cluster Autoscaler, встроенный мониторинг и Self-Healing за 3–5 минут. Посекундная тарификация означает оплату только за реально использованные ресурсы. Платформа масштабируется до 500 узлов и 55 000 подов.

Полезные ссылки

Быстрый старт

Управление ресурсами кластера в личном кабинете

Мониторинг и алертинг кластера

Автоскейлинг