kubectl logs: просмотр логов Pod в Kubernetes

Просмотр логов Pod — первый шаг при диагностике проблем в кластере. Команда kubectl logs позволяет получить существующие логи, вести потоковую трансляцию, смотреть предыдущие контейнеры и ограничивать вывод по времени или по количеству строк. Для фильтрации и анализа используйте привычные Unix-утилиты или централизованные системы логирования.

Логотип Kubernetes

Быстрые ссылки

Получение доступа к окружению
Доступ к логам Pod
Постоянная трансляция логов
Просмотр старых логов
Получение недавних логов
Логи других типов ресурсов
Более продвинутое управление логами
Короткое резюме

Получение доступа к окружению

Убедитесь, что kubectl установлен и подключён к вашему кластеру. Вы можете задать файл kubeconfig через переменную окружения KUBECONFIG:

KUBECONFIG

В shell установите её так:

export KUBECONFIG=~/.kube/my-cluster.yaml

Список Pod можно получить командой:

kubectl get pods

Если Pod находятся не в default namespace, добавьте флаг –namespace:

kubectl --namespace my-namespace get pods

Чтобы упростить ввод, можно добавить временный алиас в shell:

alias k="kubectl --namespace my-namespace"

k get pods

Важно: алиасы удобны в интерактивной работе, но не подходят для скриптов.

Доступ к логам Pod

Команда kubectl logs выводит логи для указанного Pod:

kubectl logs pod-name

Если Pod содержит несколько контейнеров, укажите имя контейнера:

kubectl logs pod-name container-name

Скриншот: просмотр логов Pod в Kubernetes с помощью kubectl

Флаг –all-containers включает строки журналов от всех контейнеров Pod. На загруженных Pods вывод может быть громоздким и повторяющимся:

kubectl logs pod-name --all-containers

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

kubectl logs -l my-label=my-value --all-containers

Постоянная трансляция логов

По умолчанию kubectl logs выводит текущие сохранённые строки и завершает работу. Добавьте флаг -f или –follow для трансляции в реальном времени:

kubectl logs -f pod-name

Команда будет печатать новые строки до прерывания Ctrl+C. Это эквивалентно tail -f для локального файла логов.

Просмотр старых логов

kubectl logs по умолчанию не показывает строки, записанные контейнерами, которые были завершены и заменены. Чтобы просмотреть логи предыдущих контейнеров, используйте флаг -p или –previous:

kubectl logs -p pod-name

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

Получение недавних логов

Если не нужно всё логохранилище, используйте флаги –since и –since-time:

kubectl logs pod-name --since=2h

Команда покажет строки за последние два часа. –since-time принимает метку времени в формате RFC3339.

Флаг –tail ограничивает количество строк вывода:

# Показать последние 10 строк
kubectl logs pod-name --tail=10

По умолчанию kubectl не добавляет метки времени к строкам (многие приложения уже включают их). Для добавления временной метки используйте –timestamps:

kubectl logs pod-name --timestamps

Флаг –prefix добавляет имя Pod и контейнера перед каждой строкой. Можно комбинировать с –timestamps, чтобы видеть источник и время каждой строки.

Скриншот: префиксы имени pod и метки времени в логах kubectl

Логи других типов ресурсов

kubectl logs работает не только с Pod. Вы можете получить логи из Job или Deployment так:

kubectl logs job/my-job
kubectl logs deployment/my-deployment

Это покажет логи первого контейнера в ресурсе. Для всех контейнеров используйте –all-containers. Все описанные выше флаги применимы и к Job/Deployment.

Более продвинутое управление логами

kubectl не предоставляет встроенных средств для сложной фильтрации или поиска. Для этого удобно использовать знакомые инструменты Unix:

kubectl logs my-pod | grep search-expression

Чтобы сохранить лог в файл, перенаправьте вывод:

kubectl logs my-pod > my-pod-logs.txt

Для регулярного анализа на продакшене лучше централизовать логи в системах типа EFK/ELK, Loki, Splunk или облачных решениях. Эти платформы предоставляют индексацию, поиск и алёртинг.

Когда kubectl logs не помогает

Контейнер не пишет в stdout/stderr — команда вернёт пустой вывод.
Логи были ротацией удалены на уровне хоста/драйвера логирования.
Приложение пишет в бинарный формат или в отдельный файл внутри контейнера.

В таких случаях проверьте конфигурацию приложения и драйвер логирования, или подключитесь в контейнер (kubectl exec) и просмотрите локальные файлы.

Альтернативные подходы

Централизованные системы логирования (Loki, Elasticsearch, Splunk) — для поиска, агрегирования и хранения.
Sidecar-контейнеры, которые пересылают логи в реестр или агент (Fluentd, Filebeat).
Использование kubectl cp или kubectl exec для доступа к локальным файлам логов внутри контейнера.

Быстрый справочник (cheat sheet)

Получить логи Pod: kubectl logs pod-name
Смотреть конкретный контейнер: kubectl logs pod-name container-name
Все контейнеры: kubectl logs pod-name –all-containers
Трансляция: kubectl logs -f pod-name
Предыдущий контейнер: kubectl logs -p pod-name
Ограничить по времени: –since=1h или –since-time=2020-01-02T15:04:05Z
Последние N строк: –tail=N
Добавить метки времени: –timestamps
Префикс имени: –prefix

Роли и чек-листы

Разработчик

Убедиться, что приложение пишет в stdout/stderr.
Добавить структурированные логи (JSON) при возможности.
Локально тестировать флаги логирования.

Инженер SRE

Настроить сбор логов и ротацию.
Интегрировать централизованный стек логирования.
Настроить алёртинг по ошибочным паттернам.

Оператор кластера

Проверить доступность kubelet и драйвера логов.
Мониторить использование дискового пространства для логов.

Методология быстрого расследования (mini-method)

Получите список Pod и их статусы: kubectl get pods -o wide.
Для проблемного Pod получите последние 200 строк: kubectl logs pod-name –tail=200.
Если контейнер перезапускался, посмотрите предыдущие логи: kubectl logs -p pod-name.
Если нужно — следите в реальном времени: kubectl logs -f pod-name.
При массовой проблеме агрегируйте логи по лейблу: kubectl logs -l app=your-app –all-containers.
Если вывод неинформативен — подключитесь внутрь контейнера: kubectl exec -it pod-name – /bin/sh.

Дерево решений для выбора метода (Mermaid)

flowchart TD
  A[Есть проблема в приложении?] --> B{Подозрение на конкретный Pod}
  B -->|Да| C[kubectl logs pod-name]
  B -->|Нет| D[kubectl get pods -l app=your-app]
  D --> E[kubectl logs -l app=your-app --all-containers]
  C --> F{Контейнер перезапускался}
  F -->|Да| G[kubectl logs -p pod-name]
  F -->|Нет| H{Нужно ли следить в реальном времени?}
  H -->|Да| I[kubectl logs -f pod-name]
  H -->|Нет| J[Использовать --since или --tail]

Критерии приёмки

Вы можете получить текущие логи Pod командой kubectl logs.
Вы можете просматривать предыдущие контейнеры с помощью -p.
Вы умеете ограничивать выдачу по времени и строкам (–since, –tail).
Логи централизованы в вашем стеке логирования (при требовании хранения и поиска).

Примеры ошибок и когда это не работает

Пустой вывод: приложение не пишет в stdout/stderr или права доступа к файлам ограничены.
Нет старых логов: ротация или драйвер логирования удалил предыдущие файлы.
Много шума: используйте фильтрацию grep/awk или централизованный стек.

Безопасность и приватность

Логи могут содержать чувствительные данные (пароли, токены). Ограничьте доступ к логам, настройте маскирование и хранение с ротацией в соответствии с политиками безопасности и GDPR, если применимо.

Краткое резюме

kubectl logs — быстрый инструмент для интерактивного изучения работы контейнеров. Он удобен для отладки и живого мониторинга, но не заменяет централизованные решения для долгосрочного хранения, поиска и алёртинга. Убедитесь, что ваши приложения пишут в stdout/stderr, и интегрируйте систему агрегации логов на уровне кластера.

Важное

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

Глоссарий 1 строка

Pod — минимальная единица развертывания в Kubernetes, содержащая один или несколько контейнеров, которые разделяют сеть и тома.