Освоение kubectl logs и describe для эффективной отладки подов

Освоение `kubectl logs` и `describe` для эффективной отладки подов

Отладка приложений в распределенной среде, такой как Kubernetes, может быть сложной задачей. Когда под не запускается, входит в цикл перезапусков или ведет себя неожиданным образом, двумя наиболее важными инструментами в наборе оператора Kubernetes являются kubectl describe и kubectl logs.

Эти команды предоставляют различные, но дополняющие друг друга представления о состоянии и истории пода Kubernetes. kubectl describe предоставляет метаданные пода, статус, переменные среды и, что крайне важно, историю системных событий. kubectl logs предоставляет потоки стандартного вывода (stdout) и стандартного потока ошибок (stderr), генерируемые самим контейнеризированным приложением.

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

Трехэтапный рабочий процесс отладки подов

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

Проверка статуса: Используйте kubectl get pods, чтобы определить состояние отказа (Pending, CrashLoopBackOff, ImagePullBackOff и т. д.).
Получение контекста и событий: Используйте kubectl describe pod, чтобы понять, почему произошел переход состояния (например, планировщик не справился, проверка живости не справилась, не удалось смонтировать том).
Проверка вывода приложения: Используйте kubectl logs для изучения поведения приложения во время выполнения (например, ошибки конфигурации, сбои подключения к базе данных, трассировки стека).

1. `kubectl describe`: Инструмент системной диагностики

kubectl describe — это первая команда, которую следует запускать, когда под ведет себя некорректно. Она не показывает вывод приложения, но предоставляет критические метаданные и историю, которые сам Kubernetes записал о поде.

Основное использование

Для базового использования требуется только имя пода:

kubectl describe pod my-failing-app-xyz789

Ключевые разделы вывода

При просмотре вывода describe сосредоточьтесь на следующих критических разделах:

A. Статус и состояние

Посмотрите на поле Status вверху, а затем просмотрите индивидуальные состояния контейнеров внутри пода. Это покажет вам, находится ли контейнер в состоянии Running, Waiting или Terminated, и укажет причину этого состояния.

Поле	Обычный статус/причина	Значение
`Status`	`Pending`	Под ожидает планирования или имеет отсутствующие ресурсы.
`Reason`	`ContainerCreating`	Среда выполнения контейнера извлекает образ или выполняет настройку.
`State`	`Waiting` / `Reason: CrashLoopBackOff`	Контейнер многократно запускался и завершался.
`State`	`Terminated` / `Exit Code`	Контейнер завершил выполнение. Ненулевые коды выхода обычно указывают на ошибки.

B. Конфигурация контейнера

Этот раздел проверяет, что ваши переменные среды, запросы/ограничения ресурсов, монтирование томов и проверки живости/готовности определены правильно, соответствуя примененному вами манифесту.

C. Раздел `Events` (Ключевой)

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

Распространенные ошибки, выявляемые в разделе Events:

Проблемы с планированием: Warning FailedScheduling: Указывает на то, что планировщик не смог найти подходящий узел (например, из-за ограничений ресурсов, taint-ов узлов или правил аффинности).
Сбои извлечения образа: Warning Failed: ImagePullBackOff: Указывает на неправильное имя образа, отсутствие тега или на то, что Kubernetes не хватает учетных данных для извлечения из приватного реестра.
Ошибки томов: Warning FailedAttachVolume: Указывает на проблемы с подключением внешнего хранилища.

Совет: Если раздел Events пуст, проблема обычно связана с приложением (сбой во время выполнения, сбой инициализации, ошибка конфигурации), что указывает на необходимость использования kubectl logs следующим шагом.

2. `kubectl logs`: Проверка вывода приложения

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

Базовое получение логов и потоковая передача в реальном времени

Для просмотра текущих логов для основного контейнера в поде:

# Получить все логи до текущего момента
kubectl logs my-failing-app-xyz789

# Потоковая передача логов в реальном времени (полезно для мониторинга запуска)
kubectl logs -f my-failing-app-xyz789

Работа с подами, содержащими несколько контейнеров

Для подов, использующих шаблон Sidecar или другие многоконтейнерные архитектуры, необходимо указать, логи какого контейнера вы хотите просмотреть, используя флаг -c или --container.

# Просмотреть логи для контейнера 'sidecar-proxy' внутри пода
kubectl logs my-multi-container-pod -c sidecar-proxy

# Потоковая передача логов для основного контейнера приложения
kubectl logs -f my-multi-container-pod -c main-app

Отладка перезапускающихся контейнеров (`--previous`)

Одним из наиболее распространенных сценариев отладки является состояние CrashLoopBackOff. Когда контейнер перезапускается, kubectl logs показывает только вывод текущей (неудачной) попытки, который часто содержит только сообщение о запуске до сбоя.

Чтобы просмотреть логи из предыдущего, завершенного экземпляра, который содержит фактическую ошибку, вызвавшую завершение работы, используйте флаг --previous (-p):

# Просмотреть логи из предыдущего, вышедшего из строя экземпляра контейнера
kubectl logs my-crashloop-pod --previous

# Объединить со спецификацией контейнера, если необходимо
kubectl logs my-crashloop-pod -c worker --previous

Ограничение вывода

Для большого объема логов получение всей истории может быть медленным или чрезмерным. Используйте --tail для ограничения вывода последними N строками.

# Показать только последние 50 строк логов контейнера
kubectl logs my-high-traffic-app --tail=50

3. Комбинирование методов для расширенной диагностики

Эффективная отладка часто включает быстрое переключение между командами describe и конкретными командами logs.

Пример: Диагностика сбоя Liveness-проверки

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

Шаг 1: Проверьте describe для системного представления.

kubectl describe pod web-server-dpl-abc

Вывод показывает в разделе Events:

Type     Reason      Age   From               Message
----     ------      ----  ----               -------
Warning  Unhealthy   2s    kubelet, node-a01  Liveness probe failed: HTTP GET http://10.42.0.5:8080/health failed: 503 Service Unavailable

Вывод из Шага 1: Контейнер запущен, но Liveness-проверка завершается ошибкой 503, что приводит к перезапуску контейнера Kubernetes.

Шаг 2: Проверьте logs для контекста приложения.

Теперь выясните, почему приложение возвращает статус 503, что является сбоем на уровне приложения.

kubectl logs web-server-dpl-abc --tail=200

Вывод логов показывает:

2023-10-26 14:01:15 ERROR Database connection failure: Timeout connecting to DB instance 192.168.1.10

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

Практика	Команда	Обоснование
Всегда проверяйте предыдущие логи	`kubectl logs --previous`	Необходимо для диагностики `CrashLoopBackOff`. Критическая ошибка почти всегда находится в предыдущем запуске.
Указывайте контейнеры	`kubectl logs -c <name>`	Избегает двусмысленности в подах с несколькими контейнерами и предотвращает получение логов от непредназначенных сайдкаров.
Используйте метки для массовых операций	`kubectl logs -l app=frontend -f`	Позволяет одновременно потоково передавать логи из нескольких подов, соответствующих селектору (полезно для скользящих обновлений).
Предупреждение: Ротация логов	N/A	Узлы Kubernetes выполняют ротацию логов. Логи старше политики хранения, настроенной на узле (часто несколько дней или на основе размера), будут удалены и станут недоступны через `kubectl logs`. Используйте внешнее централизованное решение для логирования (например, Fluentd, Loki, Elastic Stack) для долгосрочного хранения.

Заключение

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