Как забрать логи с Kubernetes

Мониторинг и сбор логов в Kubernetes: стратегии и инструменты

Сбор логов в Kubernetes имеет свои особенности из-за распределенной природы системы. Я бы разделил подходы на несколько стратегий в зависимости от требований и инфраструктуры.

Основные подходы к сбору логов

Node-level logging (логирование на уровне узлов) Наиболее распространенный подход, где агент логирования (например, Fluentd, Filebeat или Logstash) работает на каждом узле Kubernetes как DaemonSet и собирает логи из /var/log/containers/.

# Пример DaemonSet для Fluentd
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
        env:
        - name: FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch-logging"
        - name: FLUENT_ELASTICSEARCH_PORT
          value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Sidecar container (сайдкар-контейнеры) Для приложений, которые пишут логи в stdout/stderr, можно использовать sidecar-контейнеры, которые перенаправляют логи в нужное место.

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
  - name: log-sidecar
    image: busybox
    args: [/bin/sh, -c, 'tail -f /var/log/1.log']
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume
    emptyDir: {}

Application-level logging (логирование на уровне приложения) Приложения могут напрямую отправлять логи в централизованную систему (Elasticsearch, Loki, Datadog и т.д.) через свои SDK.

Популярные стеки для логирования

В моей практике наиболее эффективными показали себя следующие комбинации:

• EFK Stack (Elasticsearch, Fluentd, Kibana) — классическое решение для полнотекстового поиска и анализа
• PLG Stack (Promtail, Loki, Grafana) — современный lightweight-подход от Grafana Labs
• Коммерческие решения — Datadog, Splunk, New Relic с их операторами для Kubernetes

Ключевые рекомендации по архитектуре

• Используйте структурированное логирование (JSON) для упрощения парсинга и фильтрации
• Реализуйте ротацию логов на уровне узлов чтобы избежать заполнения дисков
• Настройте тегирование логов по namespace, pod name, container name и другим метаданным
• Внедрите политики хранения для соответствия требованиям compliance
• Мониторьте производительность агентов логирования, особенно в high-load окружениях

Практический пример с Fluent Bit

# Установка Fluent Bit через Helm
helm repo add fluent https://fluent.github.io/helm-charts
helm install fluent-bit fluent/fluent-bit \
  --namespace logging \
  --set backend.type=elasticsearch \
  --set backend.es.host=elasticsearch \
  --set backend.es.port=9200

Мониторинг процесса сбора логов

Важно не просто собирать логи, но и следить за самим процессом сбора:

• Отслеживайте задержки в pipeline логирования
• Настройте алертинг при недоступности бэкендов хранения
• Мониторьте объемы данных и прогнозируйте рост
• Регулярно проверяйте парсинг критически важных полей

Заключение

Выбор стратегии логирования зависит от многих факторов: объема данных, требований к задержкам, бюджета и экспертизы команды. В production-окружениях я рекомендую начинать с node-level подхода с DaemonSet, так как он наиболее универсален и прост в поддержке. По мере роста потребностей можно дополнять его sidecar-контейнерами для специфических случаев. Главное — обеспечить единую точку сбора и стандартизировать форматы логов на раннем этапе.