Продвинутая диагностика: глубокое погружение в логи, события и метрики Kubernetes

Диагностика Kubernetes становится проще, если разделить три вопроса: что сказал контейнер, что сделала панель управления и что показывают метрики? Логи, события и метрики отвечают на разные части одного инцидента.

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

Логи Kubernetes: основа отладки

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

Доступ к логам контейнеров

Команда kubectl logs — ваш основной инструмент для получения логов из подов. Она универсальна и предлагает несколько полезных опций.

Получение логов из одного контейнера в поде:
```
kubectl logs <имя-пода>
```
Если в поде только один контейнер, эта команда работает напрямую.
Получение логов из определенного контейнера в мультиконтейнерном поде:
```
kubectl logs <имя-пода> -c <имя-контейнера>
```
Просмотр логов предыдущего экземпляра упавшего контейнера: Если контейнер перезапустился из-за ошибки, вы можете просмотреть его логи до перезапуска с помощью флага --previous:
```
kubectl logs <имя-пода> --previous
```
Просмотр логов в реальном времени: Аналогично tail -f, флаг -f (или --follow) позволяет транслировать новые записи логов по мере их появления, что бесценно для отладки текущих проблем.
```
kubectl logs -f <имя-пода> -c <имя-контейнера>
```
Фильтрация логов по времени: Вы можете указать, сколько строк с конца получить (--tail) или логи за определенный промежуток времени (--since).
```
kubectl logs <имя-пода> --tail=100 # Последние 100 строк
kubectl logs <имя-пода> --since=1h # Логи за последний час
```

Централизованные решения для логирования

Хотя kubectl logs отлично подходит для немедленной отладки, он не практичен для крупномасштабного долгосрочного управления логами. Для производственных сред необходимы централизованные решения для логирования. Эти решения обычно включают:

Агенты логирования: Запуск агента (например, Fluentd, Fluent Bit, Filebeat) на каждом узле для сбора логов со всех подов.
Хранение и индексация логов: Хранение логов в центральном репозитории (например, Elasticsearch, Loki, Splunk).
Визуализация и анализ логов: Предоставление интерфейса для поиска, фильтрации и визуализации логов (например, Kibana, Grafana, Splunk UI).

Лучшие практики логирования

Структурированное логирование: Выводите логи в структурированном формате (например, JSON), чтобы их было легко парсить и запрашивать с помощью централизованных систем логирования.
Соответствующие уровни логирования: Используйте разные уровни логирования (DEBUG, INFO, WARN, ERROR, FATAL) для категоризации сообщений и контроля подробности.
Избегайте конфиденциальной информации: Не записывайте в логи конфиденциальные данные (пароли, PII).

События Kubernetes: рассказчик кластера

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

Доступ к событиям Kubernetes

События всего кластера:

kubectl get events

Эта команда показывает все недавние события в текущем пространстве имен. Вы можете добавить --all-namespaces, чтобы увидеть события во всем кластере.

Типичный вывод событий выглядит так:

LAST SEEN   TYPE      REASON      OBJECT                         MESSAGE
3m21s       Normal    Scheduled   pod/my-app-789c6f66-abcde      Successfully assigned default/my-app-789c6f66-abcde to node01
3m20s       Normal    Pulling     pod/my-app-789c6f66-abcde      Pulling image "example/my-app:1.2.3"
2m58s       Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off restarting failed container app

События для одного объекта:
```
kubectl describe pod <имя-пода>
```
Раздел Events внизу часто является самым быстрым способом увидеть проблемы с планированием, загрузкой образов, монтированием и перезапусками для одного пода.
Сортировка событий по времени создания:
```
kubectl get events --sort-by=.metadata.creationTimestamp
```

Что обычно говорят события

События — это недолговечные записи, поэтому они лучше всего подходят для недавних сбоев. Обратите внимание на эти распространенные причины:

FailedScheduling: Планировщик не смог разместить под. Проверьте селекторы узлов, taints, tolerations, запросы ресурсов и доступную емкость.
ImagePullBackOff или ErrImagePull: Kubernetes не смог загрузить образ. Проверьте имя образа, тег, доступ к реестру и секрет для загрузки образа.
FailedMount: Не удалось смонтировать том. Проверьте привязку PVC, класс хранения, разрешения узла и работоспособность CSI-драйвера.
BackOff: Контейнер постоянно выходит из строя. Сопоставьте событие с kubectl logs --previous.

Метрики Kubernetes: представление о ресурсах

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

Быстрые проверки с metrics-server

Если metrics-server установлен, используйте kubectl top:

kubectl top nodes
kubectl top pods
kubectl top pod <имя-пода> --containers

Высокое использование памяти подом, близкое к лимиту контейнера, часто совпадает с перезапусками OOMKilled. Высокая загрузка CPU на узле может объяснить задержки, даже если логи пода выглядят чистыми.

Более глубокие метрики с Prometheus

В производственной среде Prometheus и Grafana обычно предоставляют исторический обзор, которого не хватает kubectl top. Полезные сигналы включают:

Перезапуски контейнеров с течением времени.
Троттлинг CPU для контейнеров с низкими лимитами CPU.
Рабочий набор памяти по сравнению с лимитами.
Ожидающие поды по пространствам имен.
Задержка запросов к API-серверу и частота ошибок.
Давление на диск узла, давление на память и насыщение сети.

Сопоставление логов, событий и метрик

Используйте временное окно и двигайтесь от симптома к причине:

Проверьте состояние пода:

kubectl get pod <имя-пода> -o wide
kubectl describe pod <имя-пода>

Прочитайте текущие и предыдущие логи:

kubectl logs <имя-пода> -c <имя-контейнера>
kubectl logs <имя-пода> -c <имя-контейнера> --previous

Проверьте недавние события в пространстве имен:
```
kubectl get events --sort-by=.metadata.creationTimestamp
```

Сравните использование ресурсов:

kubectl top pod <имя-пода> --containers
kubectl top node

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

Вывод

Не отлаживайте Kubernetes, полагаясь только на один сигнал. Логи объясняют поведение приложения, события — решения панели управления, а метрики — нехватку ресурсов. Когда вы выстраиваете их по времени и имени объекта, коренные причины становится гораздо легче отделить от симптомов.