Лимиты ресурсов в Kubernetes: разбор инцидента

В Kubernetes сервис может начать тормозить без очевидного дефицита ресурсов на узле: контейнер упирается в собственный лимит CPU и получает меньше процессорного времени, чем просит приложение. Ниже — разбор типового, а не документированного реального инцидента на Kubernetes 1.32: какие симптомы искать, чем отличаются CPU- и memory-лимиты и как проверить гипотезу, прежде чем поднимать значения наугад.

Сценарий: узел свободен, а API отвечает медленно

Представим API-сервис, который после роста числа одновременных запросов стал отвечать с увеличенной задержкой. Средняя загрузка процессоров узла выглядит умеренной, перезапусков контейнера нет, но хвост задержек растёт. Команда увеличивает CPU limit — и ситуация улучшается. Это сильная зацепка, но не доказательство: одновременно могли измениться нагрузка, число реплик или состояние соседних сервисов.

В Kubernetes запрос и лимит решают разные задачи. requests.cpu и requests.memory участвуют в размещении Pod и учитываются при планировании ресурсов. Лимит CPU ограничивает процессорное время контейнера, а превышение лимита памяти может привести к завершению процесса. Нельзя свести оба случая к правилу «контейнеру дали меньше ресурсов»: последствия и диагностика различаются.

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

Как распознать, какой лимит сработал

CPU: квота и троттлинг

CPU limit задаёт верхнюю границу потребления процессора контейнером. Если приложению регулярно нужно больше, чем разрешает лимит, ядро ограничивает исполнение. Контейнер при этом не обязан перезапускаться или переходить в состояние ошибки: чаще проблема проявляется как замедление обработки работы. Поэтому одного показателя средней загрузки CPU недостаточно. Смотрите на троттлинг и задержки за тот же интервал времени, а также сравнивайте их с количеством запросов.

Проверьте, на каком уровне собираются метрики: контейнер, Pod или узел. Сравнение процентов из разных источников может вводить в заблуждение из-за разных знаменателей и интервалов агрегации. Для гипотезы о CPU важна связь во времени: растёт ли throttling одновременно с задержками и пиковым потоком запросов. Если доступна только средняя загрузка за несколько минут, краткие пики в ней могут потеряться.

Память: превышение лимита и OOM

Память ведёт себя иначе: Kubernetes и ОС не «замедляют» контейнер плавно по мере приближения к memory limit. При нехватке памяти процесс могут завершить; в статусе контейнера часто виден OOMKilled. Проверьте события Pod, причину завершения и график потребления памяти перед перезапуском. Увеличивать лимит без проверки опасно: так можно перенести проблему с одного контейнера на весь узел, особенно если суммарные запросы и реальные пики не помещаются в доступную память.

Не только CPU и память

Если причина не сходится с этими симптомами, проверьте временное дисковое пространство и число процессов. Заполнение ephemeral storage может мешать контейнеру и Pod работать с ожидаемыми файлами; ограничения на число процессов могут проявиться отказом создавать новые потоки или процессы. Конкретные сообщения зависят от приложения, runtime и способа сбора логов. Не приписывайте любой рост задержки CPU throttling только потому, что в манифесте есть CPU limit.

Порядок проверки во время инцидента

1. Зафиксируйте окно проблемы. Сопоставьте время роста задержек с изменениями трафика, релизами, числом реплик и событиями Pod. Результат: у команды есть общий интервал для сравнения графиков, а не несколько несвязанных снимков.
2. Проверьте завершения контейнеров. Посмотрите статус последнего завершения и события Pod; отдельно отметьте перезапуски и причины, связанные с памятью. Результат: становится ясно, есть ли прямые признаки OOM, а не только медленная обработка.
3. Сравните CPU request, limit и фактическое потребление. Уточните, какие значения реально попали в Pod после применения манифестов и политик кластера. Результат: вы знаете действующие настройки, а не только содержимое файла в репозитории.
4. Поставьте рядом throttling, задержки и нагрузку. Используйте один временной интервал и одинаковые границы агрегирования. Результат: видно, совпадает ли рост ограничений по CPU с ухудшением ответа сервиса.
5. Проверьте узел и соседние Pod. Сравните потребление ресурсов узла, размещение реплик и события планировщика. Результат: можно отличить локальный лимит контейнера от конкуренции на узле или нехватки ресурсов для размещения новых Pod.
6. Меняйте один параметр и сравнивайте одинаковые нагрузки. Зафиксируйте исходные настройки, долю троттлинга, задержки и количество запросов; после изменения повторите сравнение. Результат: решение опирается на измерение, а не на ощущение, что «стало лучше».

Что менять — и чем за это платите

Для проверки механизма можно временно изменить CPU limit в контролируемом окружении. Фрагмент ниже задаёт requests и limits для контейнера; значения условные и не являются рекомендацией для конкретного сервиса. Манифест сам по себе не доказывает, что лимит был причиной: после применения конфигурации нужна проверка поведения под сопоставимой нагрузкой.

apiVersion: v1
kind: Pod
metadata:
  name: api-example
spec:
  containers:
    - name: api
      image: example.invalid/api:VERSION
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"
        limits:
          cpu: "1"
          memory: "1Gi"

В рабочем манифесте замените образ на используемый вами; указанное доменное имя — заглушка, не источник готового контейнера. Единицы CPU обозначают доли процессора: например, 500m — половина одного CPU. Для памяти Kubernetes принимает значения с единицами, такими как Mi и Gi.

Выбор зависит не от универсального правила, а от симптома. При совпадении задержек с CPU throttling проверьте лимит и конкуренцию на узле. При OOMKilled исследуйте профиль памяти и пики до изменения memory limit. Если метрики не подтверждают ни одну гипотезу, сначала ищите очередь запросов, блокировки, медленные зависимости и ошибки масштабирования: увеличение ресурсов может только отсрочить следующий сбой.

Где диагностика ломается

• Смотрят только на среднее. Среднее потребление CPU не показывает, как часто контейнер упирался в квоту. Добавьте метрику throttling и сопоставляйте её с задержками на коротком интервале.
• Увеличивают лимиты всем Pod сразу. Это меняет поведение всего узла и усложняет поиск причины. Начните с одной реплики или тестового окружения, если архитектура и политика выкладки это позволяют.
• Считают OOM доказательством нехватки только контейнерного лимита. Проверьте потребление на уровне узла и изменения в соседних нагрузках: повышение лимита не создаёт физическую память.
• Сравнивают разные релизы и нагрузку. Если после изменения одновременно выросло число реплик или упал трафик, эффект лимита не отделить от остальных факторов. Зафиксируйте условия эксперимента.

Что измерить после инцидента

До изменения сохраните базовый профиль: задержки запросов, пропускную способность, CPU throttling, потребление и события памяти, перезапуски контейнеров, загрузку узлов и число реплик. После изменения сравните те же показатели на сопоставимой нагрузке. Не ограничивайтесь одним удачным графиком: проверьте, не выросла ли очередь, не ухудшились ли задержки соседнего сервиса и хватает ли узлу ресурсов при масштабировании.

Универсальных значений requests и limits для API нет: они зависят от приложения, профиля трафика и конфигурации кластера. Отдельная тема — выбор стратегии автоскейлинга и настройка профилирования приложения; здесь речь только о диагностике ограничений ресурсов.

Сноска. Троттлинг — принудительное ограничение процессорного времени, когда контейнер исчерпал доступную ему квоту CPU в заданном периоде.

Что делать дальше

После разбора добавьте дашборд, на котором рядом видны задержки, нагрузка, CPU throttling, память и перезапуски контейнеров. Затем проверьте, что значения requests и limits в манифесте совпадают с реально созданными Pod, и договоритесь о безопасном способе сравнивать настройки под одинаковой нагрузкой. Следующий показатель для регулярного наблюдения — не только средняя загрузка узла, но и доля времени, когда контейнер ограничивали по CPU.