Устранение распространенных узких мест производительности Kubernetes

Проблемы производительности Kubernetes редко заявляют о себе как "Kubernetes работает медленно". Вы видите зависший rollout, API, внезапно возвращающий ошибки 5xx, очередь, переставшую обрабатываться, или поды, которые выглядят здоровыми, пока пользователи жалуются на задержки. Кластер — лишь часть этой истории, но именно ее можно проверить с помощью набора стандартных команд.

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

Фаза 1: Выявление симптомов

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

Медленные развертывания/обновления: Создание подов занимает чрезмерно много времени, или rolling updates зависают.
Неотвечающие приложения: Поды работают, но не отвечают на трафик уровня приложения (например, высокая задержка, ошибки 5xx).
Высокие скачки ресурсов: Необъяснимые скачки использования CPU или памяти на узлах или в конкретных развертываниях.
Задержки планирования: Новые поды остаются в состоянии Pending бесконечно.

Фаза 2: Диагностика ограничений ресурсов (CPU и память)

Неправильное управление ресурсами — самая частая причина проблем с производительностью Kubernetes. Неправильно установленные requests и limits приводят к троттлингу или OOMKills.

1. Проверка использования ресурсов и лимитов

Начните с проверки выделения ресурсов для затронутого приложения с помощью kubectl describe и kubectl top.

Практическая проверка: Сравните requests и limits с фактическим использованием, сообщаемым серверами метрик.

# Получить использование ресурсов для всех подов в пространстве имен
kubectl top pods -n <namespace>

# Проверить requests/limits ресурсов для конкретного пода
kubectl describe pod <pod-name> -n <namespace>

Также проверьте родительскую рабочую нагрузку, чтобы понять, затрагивает ли проблема один под или весь Deployment:

kubectl get deploy <deployment-name> -n <namespace> -o yaml
kubectl get pods -n <namespace> -l app=<label> -o wide

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

2. Троттлинг CPU

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

Совет по диагностике: Ищите ответы с высокой задержкой, даже если kubectl top не показывает 100% использование CPU на узле. Троттлинг происходит на контейнер.

Для более глубокого подтверждения используйте вашу систему метрик, если она предоставляет метрики троттлинга CPU контейнера. В настройках на основе Prometheus команды часто отслеживают такие метрики, как периоды троттлинга CPU, вместе с задержкой запросов. Сырое использование CPU само по себе может скрывать троттлинг, потому что контейнер может быть затроттлен до того, как он вообще покажет использование полного ядра узла.

Решение:

Увеличьте limit CPU, если рабочая нагрузка действительно требует больше вычислительной мощности.
Если приложение занято ожиданием (busy-waiting), оптимизируйте код приложения, а не просто увеличивайте лимиты.
Рассмотрите возможность удаления лимитов CPU для некоторых чувствительных к задержкам сервисов, оставив при этом requests CPU, если это соответствует вашей политике платформы. Это позволяет избежать жесткого троттлинга, предоставляя планировщику полезную информацию для размещения.

3. Давление памяти и OOMKills

Если контейнер превышает свой лимит памяти, Kubernetes инициирует Out-Of-Memory (OOM) kill, перезапуская контейнер снова и снова.

Диагностика: Проверьте статус пода на предмет частых перезапусков (проверьте столбец RESTARTS в kubectl get pods) и изучите логи на предмет событий OOMKilled.

# Проверить последние события на предмет OOMKills
kubectl get events --field-selector involvedObject.name=<pod-name> -n <namespace>

Решение:

Если OOMKills часты, немедленно увеличьте limit памяти.
Для долгосрочных исправлений профилируйте приложение, чтобы найти и исправить утечки памяти или уменьшить размер кучи.

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

Лучшая практика: Устанавливайте Requests разумно. Убедитесь, что requests ресурсов установлены достаточно близко к ожидаемому минимальному использованию. Если requests слишком низкие, планировщик может переподписать узел, что приведет к конкуренции, когда все поды одновременно достигнут своих пиковых нагрузок.

Фаза 3: Исследование узких мест планирования

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

1. Анализ ожидающих подов

Используйте kubectl describe pod на ожидающем поде, чтобы прочитать раздел Events. Этот раздел обычно содержит четкое объяснение причины неудачи планирования.

Распространенные сообщения планировщика:

0/3 nodes are available: 3 Insufficient cpu. (Проблема с емкостью узла)
0/3 nodes are available: 3 node(s) had taint {dedicated: infra}, that the pod didn't tolerate. (Несоответствие Taints/Tolerations)
0/3 nodes are available: 1 node(s) had taint {NoSchedule: true}, that the pod didn't tolerate. (Давление на узел или обслуживание)

2. Насыщение ресурсов кластера

Если планирование задерживается из-за нехватки CPU/памяти, кластеру не хватает общей емкости.

Решение:

Добавьте больше узлов в кластер.
Убедитесь, что использование узлов не является искусственно высоким из-за неправильно настроенных запросов ресурсов (см. Фазу 2).
Используйте Cluster Autoscaler (CA), если работаете в облачных провайдерах, чтобы динамически добавлять узлы при накоплении ожидающих подов.

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

Фаза 4: Проблемы производительности в механизмах масштабирования

Автоматическое масштабирование должно реагировать быстро, но неправильные настройки Horizontal Pod Autoscaler (HPA) или Vertical Pod Autoscaler (VPA) могут вызывать проблемы.

1. Задержка Horizontal Pod Autoscaler (HPA)

HPA полагается на Metrics Server для предоставления точных данных об использовании CPU/памяти или пользовательских метрик.

Шаги диагностики:

Проверьте работоспособность Metrics Server: Убедитесь, что Metrics Server работает и доступен.
```
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"
```
Проверьте статус HPA: Изучите конфигурацию HPA и последние события.
```
kubectl describe hpa <hpa-name> -n <namespace>
```
Ищите сообщения, указывающие на то, что источник метрик недоступен или цикл принятия решений о масштабировании не функционирует.

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

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

2. Взаимодействие с Vertical Pod Autoscaler (VPA)

Хотя VPA автоматически корректирует запросы ресурсов, он может вызывать нестабильность производительности во время фазы настройки, если часто перезапускает или изменяет размер подов, особенно для stateful-приложений, которые не терпят перезапусков.

Рекомендация: Сначала используйте VPA в режиме Recommender или используйте updateMode: "Off", чтобы только наблюдать за рекомендациями без автоматического применения, сводя к минимуму сбои из-за ненужных изменений размера.

Фаза 5: Производительность сети и хранилища

Когда вычислительные ресурсы в порядке, узким местом может быть сеть или постоянное хранилище.

1. Проблемы CNI (Container Network Interface)

Если связь между подами (особенно между узлами) медленная или периодически прерывается, плагин CNI может быть перегружен или неправильно настроен.

Устранение неполадок:

Проверьте логи подов DaemonSet CNI (например, Calico, Flannel).
Проверьте базовую связь с помощью ping или curl между подами на разных узлах.

2. Задержка Persistent Volume (PV)

Приложения, сильно зависящие от дискового ввода-вывода (базы данных, системы журналирования), будут страдать, если задержка базового Persistent Volume высока.

Практическая проверка: Подтвердите тип провизионера (например, AWS EBS gp3 vs. io1) и убедитесь, что том соответствует требуемым характеристикам IOPS/пропускной способности.

Предупреждение о хранилище: Никогда не запускайте высокопроизводительные базы данных непосредственно на стандартных томах hostPath, не понимая характеристик производительности базового диска. Используйте управляемые облачные решения для хранения или высокопроизводительные локальные провизионеры для требовательных рабочих нагрузок.

Узкие места на уровне узлов

Иногда все поды на узле замедляются одновременно. Это сигнал перестать смотреть на один Deployment и проверить узел.

kubectl describe node <node-name>
kubectl top node <node-name>
kubectl get pods --all-namespaces -o wide | grep <node-name>

Ищите условия MemoryPressure, DiskPressure и PIDPressure. Давление на диск легко упустить из виду, потому что симптомом приложения может быть медленный запуск, сбои при вытягивании образов или вытеснения, а не очевидная ошибка диска.

На самом узле, если у вас есть доступ, проверьте:

df -h
iostat -x 1
free -h
journalctl -u kubelet --since "30 minutes ago"

Управляемые сервисы Kubernetes могут ограничивать прямой доступ к узлу, но идея остается той же: используйте метрики провайдера, события kubelet и условия узла, чтобы решить, является ли узел общим узким местом.

Давление на Control Plane и API

Большинство задержек приложений не вызваны сервером API Kubernetes. Ваш веб-запрос обычно не обращается к серверу API при каждом запросе пользователя. Но давление на control plane может навредить операционной производительности: медленные rollout'ы, задержки планирования, медленные обновления endpoint'ов или отстающие контроллеры.

Симптомы включают:

Команды kubectl выполняются медленно во всем кластере.
Развертывания занимают больше времени, чем обычно, для создания подов.
Контроллеры отстают от желаемого состояния.
События показывают повторяющиеся тайм-ауты API.

Проверьте, затрагивает ли проблема нормальный трафик приложения или операции кластера. Если замедлены только rollout'ы и планирование, посмотрите на работоспособность сервера API, поведение controller manager, admission webhooks и работоспособность etcd в кластерах, где вы управляете control plane.

Admission webhooks заслуживают особого внимания. Медленный или недоступный webhook может задерживать создание подов, даже если на узлах достаточно ресурсов. Если rollout зависает на этапе создания, а события упоминают вызовы webhook, исследуйте сервис webhook, прежде чем изменять размер узлов.

Практический порядок устранения неполадок

Начните с видимого пользователю симптома:

Медленные HTTP-запросы: сравните задержку приложения, троттлинг CPU, перезапуски памяти, задержку нижестоящих сервисов и сетевой путь.
Медленный запуск пода: проверьте время вытягивания образа, события планирования, время подключения тома и init-контейнеры.
Ожидающие поды: проверьте requests, емкость узла, taints, affinity, квоты и лимиты autoscaler.
Периодические скачки задержки: проверьте троттлинг CPU, сборку мусора, шумных соседей, задержку хранилища и время масштабирования HPA.
Случайные перезапуски: проверьте OOMKilled, liveness probes, давление на узел и логи приложения из предыдущего контейнера.

Затем доказывайте или исключайте один уровень за раз. Например, если скачки задержки точно совпадают с троттлингом CPU, у вас есть веская зацепка. Если скачки задержки происходят, когда CPU, память, сеть и хранилище выглядят спокойно, узкое место может быть внутри приложения или во внешнем сервисе за пределами Kubernetes.

Настройка Request и Limit без гаданий

Неправильные настройки ресурсов создают множество проблем с производительностью:

Requests слишком низкие: планировщик упаковывает слишком много занятых подов на один узел.
Requests слишком высокие: поды остаются в ожидании, хотя фактическое использование скромное.
Лимиты CPU слишком низкие: чувствительные к задержкам приложения подвергаются троттлингу.
Лимиты памяти слишком низкие: контейнеры убиваются вместо замедления.
Отсутствие requests: планирование становится менее предсказуемым, и критически важные рабочие нагрузки могут плохо конкурировать с шумными соседями.

Используйте недавние производственные метрики в качестве отправной точки, затем оставьте запас для нормальных скачков. Для рабочих нагрузок на Java, Node.js, Go, Python и базах данных поведение памяти может сильно различаться, поэтому избегайте копирования лимитов из одного сервиса в другой только потому, что размер образа контейнера выглядит похожим.

Следующие шаги

Лучшие расследования производительности Kubernetes скучны в хорошем смысле: определите симптом, проверьте под, проверьте узел, проверьте масштабирование, затем проверьте сеть и хранилище. kubectl describe и kubectl top — это только начало, но они обычно указывают, в каком направлении стоит двигаться.

Внедрите надежные Resource Quotas, чтобы предотвратить истощение ресурсов критически важных приложений шумными соседями.
Регулярно проверяйте количество перезапусков подов, чтобы вовремя заметить скрытые OOM или проблемы в поведении приложения.
Используйте дашборды Prometheus/Grafana, специально отслеживающие метрики троттлинга CPU, а не только сырое использование.