Траблшутинг нагрузок
Логи, терминал, события в GUI и консоли, частые ошибки и сетевые проблемы.
При диагностике проблем с подами и нагрузками используйте логи контейнеров, события (Events) и при необходимости терминал пода. В интерфейсе «Штурвал» всё это доступно на странице пода и на страницах нагрузок (Deployment, StatefulSet и т.д.). Ниже — где именно смотреть в GUI и как дублировать проверки в консоли (kubectl), а также типичные ошибки и ссылки на официальную документацию Kubernetes.
С чего начать: логи, события, терминал
| Что нужно | В интерфейсе | В консоли |
|---|---|---|
| Логи контейнера | Страница пода → вкладка Логи. См. раздел Просмотр логов пода ниже. | kubectl logs <pod> -n <namespace> |
| События (Events) | Дашборд неймспейса → вкладка События; или страница нагрузки/пода → вкладка События. Подробнее: Обзор дашборда неймспейса. | kubectl get events -n <namespace> --sort-by='.lastTimestamp'; kubectl describe pod <pod> |
| Терминал пода | Страница пода → вкладка Терминал (если в контейнере есть shell). См. раздел Вызов терминала пода ниже. | kubectl exec -it <pod> -n <namespace> -- /bin/sh |
Рекомендуемый порядок: сначала посмотрите события (причина планирования, образа, падений), затем логи пода; при необходимости откройте терминал для ручной проверки внутри контейнера.
Просмотр логов пода
В интерфейсе (GUI)
- Перейдите в Нагрузки → Pods (или откройте нагрузку → вкладка Pods) и выберите под.
- На странице пода откройте вкладку Логи.
- Выберите контейнер (если их несколько), при необходимости включите предыдущий лог (логи контейнера до последнего перезапуска), задайте диапазон времени или поиск по тексту, при необходимости скачайте логи.
На вкладке Логи доступны выбор контейнера, автообновление, отображение временной метки и предыдущего лога, количество записей (по умолчанию 100), диапазон времени, поиск по тексту и скачивание log-файла.
В консоли (kubectl)
# Логи основного контейнера
kubectl logs <pod-name> -n <namespace>
# Логи конкретного контейнера (если в поде несколько)
kubectl logs <pod-name> -n <namespace> -c <container-name>
# Поток логов в реальном времени (аналог tail -f)
kubectl logs -f <pod-name> -n <namespace>
# Логи за последний час
kubectl logs <pod-name> -n <namespace> --since=1h
# Логи предыдущего контейнера (после перезапуска — важно при CrashLoopBackOff)
kubectl logs <pod-name> -n <namespace> --previous
# Последние N строк
kubectl logs <pod-name> -n <namespace> --tail=100
Просмотр событий (Events)
События помогают понять, почему под не запланировался, не тянет образ, падает или не переходит в Ready.
В интерфейсе (GUI)
- По неймспейсу: откройте дашборд неймспейса → вкладка События. Отображаются события всех объектов неймспейса (создание/удаление, ошибки планирования, предупреждения о ресурсах). Подробнее: Обзор дашборда неймспейса — вкладка «События».
- По нагрузке или поду: откройте страницу Deployment / StatefulSet / Pod и перейдите на вкладку События. Там отображаются события, связанные с этим объектом (в том числе FailedScheduling, ImagePullBackOff, Killing, Unhealthy и т.п.).
В названии вкладки может отображаться количество событий. Обращайте внимание на сообщения с индикацией ошибок и предупреждений.
В консоли (kubectl)
# События неймспейса (последние в конце)
kubectl get events -n <namespace> --sort-by='.lastTimestamp'
# Детали пода, включая блок Events
kubectl describe pod <pod-name> -n <namespace>
# Только предупреждения
kubectl get events -n <namespace> --field-selector type=Warning
Официальная документация: kubectl events.
Вызов терминала пода
Удобен для ручной проверки файлов, переменных окружения и команд внутри контейнера.
В интерфейсе (GUI)
- Откройте страницу пода (Нагрузки → Pods → выберите под, или со страницы нагрузки → вкладка Pods → под).
- Перейдите на вкладку Терминал. Вкладка отображается только если хотя бы в одном контейнере пода есть shell (Bash в интерфейсе не поддерживается).
- Откроется интерактивная консоль внутри контейнера.
Обратите внимание! корректная работа терминала гарантируется в браузере Google Chrome.
В консоли (kubectl)
# Интерактивная оболочка (часто /bin/sh)
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh
# Если доступен bash
kubectl exec -it <pod-name> -n <namespace> -- /bin/bash
# Выполнить одну команду без входа в контейнер
kubectl exec <pod-name> -n <namespace> -- ls -la /app
Частые ошибки и что проверять
Ниже — типичные состояния и ошибки, что смотреть в GUI (события, логи) и как исправлять. Дополнительно см. официальные руководства: Troubleshooting Applications, Determine the Reason for Pod Failure.
Под в состоянии Pending
Симптом: под долго остаётся в статусе Pending, не переходит в Running.
Причины и действия:
-
Нехватка ресурсов на узлах (Insufficient CPU / Insufficient memory)
В событиях пода или неймспейса обычно есть сообщение вроде0/N nodes are available: N Insufficient cpu, N Insufficient memory.- В GUI: проверьте вкладку События на странице пода или дашборда неймспейса.
- Решение: уменьшите
requests(и при необходимостиlimits) в манифесте пода/Deployment; или запросите у администратора добавление узлов / увеличение квот.
-
Несовпадение taints узлов и tolerations пода
Под не может быть запланирован на узлы с taints, если у пода нет подходящих tolerations.- Проверьте события (в GUI — вкладка События; в консоли —
kubectl describe pod <pod>). - Добавьте в spec пода соответствующие
tolerationsили измените taints на узлах (через администратора).
- Проверьте события (в GUI — вкладка События; в консоли —
-
Использование hostPort
Ограничивает выбор узлов. По возможности используйте Service вместо hostPort.
Пример проверки в консоли:
kubectl describe pod <pod-name> -n <namespace>
# В блоке Events ищите FailedScheduling и текст причины
CrashLoopBackOff
Симптом: под постоянно перезапускается, статус CrashLoopBackOff.
Причины (часто): ошибка в приложении при старте, превышение лимита памяти (OOMKilled), неверные переменные окружения или конфигурация, отсутствие зависимостей (БД, внешний сервис), слишком строгие или неверные readiness/liveness probes, ошибки монтирования томов.
Что сделать:
- Логи предыдущего контейнера — часто там видна причина падения.
- В GUI: страница пода → вкладка Логи → включите опцию отображения предыдущего лога (логи до последнего рестарта).
- В консоли:
kubectl logs <pod-name> -n <namespace> --previous
- События — на странице пода или нагрузки откройте вкладку События; в консоли —
kubectl describe pod <pod-name>. Ищите сообщения о Killing, Unhealthy, Back-off restarting. - Проверьте: образ и тег, переменные окружения, монтирование секретов/ConfigMap, доступность БД и внешних сервисов, настройки probes (начальная задержка, таймауты, порты).
См. также: Determine the Reason for Pod Failure (termination message, логи).
OOMKilled (Out Of Memory)
Симптом: контейнер завершён из-за превышения лимита памяти (в событиях/статусе — OOMKilled).
Причина: потребление памяти выше значения resources.limits.memory.
Решение:
- Увеличьте
memory.limits(и при необходимостиmemory.requests) в манифесте Deployment/Pod. - Оптимизируйте приложение (утечки памяти, кэши, размер пулов).
- Проверьте логи и метрики перед падением (в GUI — вкладка Логи, блок метрик на странице пода/нагрузки).
Пример:
resources:
limits:
memory: "512Mi" # увеличить при необходимости
requests:
memory: "256Mi"
ImagePullBackOff / ErrImagePull
Симптом: под не может загрузить образ, статус ImagePullBackOff или ErrImagePull.
Причины: неверное имя образа или тег, образ в приватном реестре без учётных данных, нет сетевого доступа к реестру.
Что сделать:
- Проверьте имя образа и тег в манифесте (в GUI — вкладка Манифест или Шаблон пода).
- Убедитесь, что образ существует в реестре (доступен с узлов кластера).
- Для приватного реестра: задайте
imagePullSecretsв поде (секреты создаются в разделе Неймспейс → Хранилище). См. подготовку образа и registry перед деплоем. - Проверьте события пода (вкладка События) — там часто указана точная причина (например, 401 Unauthorized, 404 Not Found).
Официально: Pull an Image from a Private Registry, ImagePullBackOff.
Init-контейнер падает (Init:Error / Init:CrashLoopBackOff)
Симптом: под не переходит в Running, в статусе видно падение init-контейнера.
Что сделать: смотрите логи именно init-контейнера (в GUI — на вкладке Логи выберите этот контейнер; в консоли — kubectl logs <pod-name> -n <namespace> -c <init-container-name>). Проверьте скрипты, переменные окружения, доступ к зависимостям (сети, секреты, тома). События пода (вкладка События) также покажут причину перезапуска.
Liveness / Readiness probe failed
Симптом: в событиях пода сообщения о failed liveness или readiness probe; под перезапускается или не попадает в Service.
Что сделать:
- Проверьте логи приложения (вкладка Логи) — не падает ли приложение по таймауту или ошибке на пути проверки.
- Убедитесь, что порт, путь и период проверки в
livenessProbe/readinessProbeсоответствуют приложению (начальная задержкаinitialDelaySecondsможет быть слишком мала). - При необходимости временно ослабьте или отключите пробу для проверки (только для отладки).
Сетевые проблемы
Под не может подключиться к другому сервису
Проверьте:
- Существует ли Service для целевого приложения: в GUI — раздел Сервисы в неймспейсе; в консоли —
kubectl get svc -n <namespace>. - DNS-имя: внутри кластера —
<service-name>.<namespace>.svc.cluster.local; в том же неймспейсе можно использовать короткое имя<service-name>. - Совпадение портов у Service и контейнера.
- Сетевые политики (NetworkPolicy) не блокируют трафик:
kubectl get networkpolicy -n <namespace>. При необходимости обратитесь к администратору кластера.
Ingress не открывает приложение
Проверьте: наличие и работоспособность Ingress Controller; корректность host, path и backend в ресурсе Ingress; DNS и TLS-сертификат при использовании HTTPS. При необходимости проверьте события Ingress и подов контроллера (вкладки События в GUI).
Отсутствие requests/limits
Проблема: у контейнеров не заданы requests и limits.
Последствия: HPA по CPU/памяти не работает; возможны перегрузка узлов и непредсказуемое планирование.
Решение: задайте requests и limits в манифесте (в GUI — форма создания/редактирования пода или вкладка Манифест):
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
Превышение квоты неймспейса
Симптом: под не создаётся, в событиях — ошибка о превышении квоты (ResourceQuota).
Решение: проверьте квоты неймспейса (в GUI — дашборд неймспейса, блок Квоты; в консоли — kubectl describe quota -n <namespace>). Уменьшите суммарные requests подов в неймспейсе или запросите у администратора увеличение квоты.
Нехватка ресурсов на узлах
Симптом: под в Pending, в событиях — недостаточно CPU/памяти на узлах.
Решение: проверьте использование узлов (kubectl top nodes); уменьшите requests подов или обратитесь к администратору для добавления узлов / очистки неиспользуемых подов и образов.
Неверные tolerations
Симптом: под в Pending; в событиях — не удаётся запланировать из-за taints узлов.
Решение: проверьте taints узлов (kubectl describe node <node-name> | grep Taints) и добавьте в spec пода подходящие tolerations (или согласуйте с администратором изменение taints). Пример:
spec:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
Общие рекомендации по траблшутингу
- Сначала события — вкладка События на дашборде неймспейса или на странице пода/нагрузки часто сразу указывает на причину (FailedScheduling, ImagePullBackOff, Killing, probe failed).
- Затем логи — вкладка Логи на странице пода (при падениях включайте «предыдущий лог»).
- Терминал пода — для ручной проверки файлов и команд внутри контейнера.
- Проверяйте зависимости — БД, внешние API, ConfigMap/Secret и монтирование томов.
- Сверяйтесь с манифестом — в GUI вкладка Манифест на странице пода/нагрузки; убедитесь, что образ, ресурсы, probes и окружение заданы верно.
Полезные команды kubectl
# Описание пода (события, условия, контейнеры)
kubectl describe pod <pod-name> -n <namespace>
# События неймспейса
kubectl get events -n <namespace> --sort-by='.lastTimestamp'
# События для конкретного пода
kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name>
# Использование ресурсов
kubectl top nodes
kubectl top pods -n <namespace>
# Сетевые политики
kubectl get networkpolicy -n <namespace>
# Service и endpoints
kubectl get svc, endpoints -n <namespace>
Дополнительные материалы
- Troubleshooting Applications — обзор отладки приложений в Kubernetes.
- Determine the Reason for Pod Failure — сообщение о завершении контейнера (termination message).
- Debug Init Containers — отладка init-контейнеров.
- Images (ImagePullBackOff) — образы и ошибки загрузки.
- Как задеплоить приложение — создание и управление нагрузками в интерфейсе.
- Обзор дашборда неймспейса — вкладка «События» по неймспейсу.