Как посмотреть логи в Kubernetes?

Как посмотреть логи в Kubernetes

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

Основные команды kubectl logs

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

Просмотр логов конкретного пода:

# Логи текущего пода
kubectl logs <pod-name>

# Логи пода с указанием пространства имен
kubectl logs <pod-name> -n <namespace>

# Логи конкретного контейнера в поде (если их несколько)
kubectl logs <pod-name> -c <container-name>

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

# Логи с "живым" выводом (аналог tail -f)
kubectl logs -f <pod-name>

# Логи за последний час
kubectl logs --since=1h <pod-name>

# Логи за определенный временной период
kubectl logs --since-time="2024-01-15T10:00:00Z" <pod-name>

# Последние N строк логов
kubectl logs --tail=100 <pod-name>

# Логи предыдущего контейнера (если контейнер перезапускался)
kubectl logs -p <pod-name>

Продвинутые сценарии работы с логами

Для подов с несколькими репликами (например, в Deployment или StatefulSet) нужно сначала определить конкретные поды:

# Получить список всех подов в деплойменте
kubectl get pods -l app=my-app

# Просмотреть логи из всех подов с определенной меткой
kubectl logs -l app=my-app --all-containers=true

# Или использовать параллельный просмотр
for pod in $(kubectl get pods -l app=my-app -o name); do
  echo "=== Logs for $pod ==="
  kubectl logs $pod
done

Для инициализирующих контейнеров (init containers) логи хранятся отдельно и доступны даже после завершения работы:

kubectl logs <pod-name> -c <init-container-name>

Инструменты для агрегации и анализа логов

В production-средах простого kubectl logs недостаточно, поэтому используются:

1. Centralized Logging Solutions:

• EFK Stack (Elasticsearch, Fluentd/Fluent Bit, Kibana) — классическое решение
• Loki от Grafana Labs — легковесная альтернатива, особенно эффективная с Grafana
• Datadog, Splunk, Sumo Logic — коммерческие платформы

2. Архитектура сбора логов:

Поды → Sidecar/Node агенты (Fluent Bit) → Брокер (Kafka) → Хранилище (Elasticsearch/Loki) → Визуализация (Kibana/Grafana)

3. Пример настройки Fluent Bit DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
spec:
  template:
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:latest
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: config
          mountPath: /fluent-bit/etc/
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: config
        configMap:
          name: fluent-bit-config

Практические рекомендации

Структурированное логирование:

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "ERROR",
  "message": "Failed to connect to database",
  "pod": "app-7c8b9d6f-abc12",
  "namespace": "production",
  "labels": {
    "app": "api-service",
    "version": "2.1.0"
  }
}

Мои best practices:

• Всегда используйте структурированные логи (JSON)
• Настройте ротацию логов на уровне узлов (node logging)
• Включайте контекстную информацию в логи (pod name, namespace, labels)
• Разделяйте логи приложения и системные логи
• Настройте алертинг на критические ошибки в логах
• Используйте distributed tracing (Jaeger, OpenTelemetry) вместе с логами

Решение частых проблем

Проблема: "Error from server (BadRequest): previous terminated container not found" Решение: Контейнер был удален или под пересоздан. Используйте централизованную систему логов.

Проблема: Логи слишком объемные Решение:

# Фильтрация по шаблону
kubectl logs <pod-name> | grep -i "error\|exception"

# Использование jq для структурированных логов
kubectl logs <pod-name> | jq 'select(.level == "ERROR")'

Проблема: Нужны логи после перезапуска пода Решение: Используйте флаг -p или настройте сохранение логов на узле.

Заключение

Для эффективной работы с логами в Kubernetes я рекомендую:

1. Для разработки и отладки — kubectl logs с различными флагами
2. Для staging-сред — добавить Loki как легковесное решение
3. Для production — полноценный стек EFK или коммерческое решение

Ключевой принцип: логи должны быть доступны даже после удаления подов, что достигается только при использовании централизованных систем сбора логов. Современные практики также предполагают использование структурированного логирования и корреляции логов с метриками и трейсами для полной observability системы.