Как организован сбор логов контейнеров в Kubernetes и в чём разница между подходом "DaemonSet-агент на узле" и "sidecar-контейнер в поде"?

Короткий ответ

DaemonSet-агент (например, Fluent Bit или Promtail) запускается один раз на каждый узел и читает stdout/stderr всех контейнеров узла через файлы логов, которые kubelet уже складывает на диск — это самый распространённый и ресурсоэффективный подход. Sidecar-контейнер работает в паре с конкретным подом и нужен, когда приложение пишет логи в файл внутри контейнера, а не в stdout, и требуется прочитать именно этот файл.

Как это работает подробнее

kubelet по умолчанию перенаправляет stdout/stderr каждого контейнера в файлы на узле (обычно через container runtime, в формате JSON-строк), и DaemonSet-агент на этом же узле читает эти файлы, добавляет метаданные (namespace, pod, labels через Kubernetes API) и отправляет в центральное хранилище. Sidecar-подход добавляет дополнительный контейнер в тот же под, который либо сам читает файл лога через общий volume, либо сам "tail"-ит и пересылает данные.

Пример кода

config.yamlКопировать

# Фрагмент конфигурации kubelet (через KubeletConfiguration) — ротация логов на узле
containerLogMaxSize: "50Mi"
containerLogMaxFiles: 5
---
# DaemonSet Fluent Bit — читает общий путь логов узла
spec:
  template:
    spec:
      containers:
        - name: fluent-bit
          volumeMounts:
            - name: varlog
              mountPath: /var/log

Что использовать на практике

• Практика. DaemonSet-подход предпочтителен в большинстве случаев, так как не требует менять каждый под и потребляет меньше ресурсов (один агент на узел против одного sidecar на каждый под). Sidecar нужен точечно — например, legacy-приложение, которое невозможно быстро переписать на логирование в stdout, или когда нужна специфичная предобработка лога для конкретного приложения.
• Практика. После применения ограничений ротации логов и развёртывания DaemonSet команда kubectl logs -n kube-system -l app=fluent-bit должна показывать стабильную обработку без ошибок нехватки диска, а логи приложений должны появляться в центральном хранилище с задержкой в пределах нескольких секунд.

Подводные камни

• Частые ошибки. добавлять sidecar для сбора логов по умолчанию для всех приложений, резко увеличивая суммарное потребление CPU/памяти кластера; не настраивать ротацию и ограничение размера логов на узле (containerLogMaxSize, containerLogMaxFiles у kubelet), из-за чего диск узла заполняется логами до того, как агент успевает их вычитать и отправить.