Сбор логов DaemonSet в Kubernetes: практическое руководство для SecOps

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

Основное преимущество заключается в операционной простоте: приложения не требуют модификации, а при добавлении нового узла в Kubernetes DaemonSet автоматически разворачивает на нем еще один под сборщика.

Для команд безопасности такая архитектура особенно важна, поскольку логи контейнеров часто краткоживущи. Если логи остаются только на узле, перезапуск пода, замена узла, вытеснение (eviction) или ротация логов могут навсегда удалить ценную телеметрию безопасности.

В этом руководстве объясняется, как работает логирование в Kubernetes, как развернуть NXLog Agent в виде DaemonSet, как работать с современными средами выполнения контейнеров, такими как containerd и CRI-O, и как пересылать логи контейнеров и аудита Kubernetes в такие платформы, как Microsoft Sentinel и Splunk.

Что такое сбор логов на основе DaemonSet в Kubernetes?

DaemonSet — это контроллер Kubernetes, который гарантирует, что копия пода запускается на каждом узле или на выбранной группе узлов.

Когда к кластеру присоединяется новый узел, Kubernetes автоматически планомерно назначает туда под DaemonSet. При удалении узла под DaemonSet также удаляется.

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

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

В Kubernetes используются три распространенных паттерна сбора логов:

Паттерн	Как это работает	Преимущества	Компромиссы
Агент узла DaemonSet	Один под сборщика на узел читает файлы логов контейнеров из файловой системы хоста.	Покрытие всего кластера, отсутствие изменений в приложениях и один сборщик на узел независимо от количества подов.	Требует монтирования логов хоста и соответствующих разрешений уровня узла.
Сборщик Sidecar	Выделенный контейнер-сборщик работает вместе с приложением в одном поде.	Может собирать логи приложений, которые записываются исключительно в файлы внутри контейнера.	Более высокое потребление ресурсов и индивидуальная конфигурация для каждого приложения.
Логирование на уровне приложения	Приложение отправляет свои логи напрямую в центральное хранилище.	Отсутствует отдельная инфраструктура сбора.	Логика логирования становится частью приложения с ограниченным покрытием инфраструктуры Kubernetes и возможными пробелами при сбоях приложений.

Для большинства сред Kubernetes агент узла DaemonSet является предпочтительным выбором по умолчанию. Схема Sidecar лучше подходит для приложений, которые записывают важные логи напрямую в файлы, а не в stdout или stderr.

Как Kubernetes записывает логи контейнеров

Сборщик DaemonSet по своей сути является считывателем логов уровня узла. Чтобы настроить его правильно, необходимо понимать, где Kubernetes хранит логи контейнеров и какой формат использует среда выполнения контейнеров.

Базовый конвейер выглядит следующим образом:

1. Приложение записывает данные в stdout или stderr.
2. Среда выполнения контейнера перехватывает вывод.
3. Среда выполнения записывает записи в файлы на узле Kubernetes.
4. Kubernetes предоставляет удобные пути к файлам логов через /var/log/containers.
5. Сборщик DaemonSet считывает эти файлы и пересылает события в центральное назначение.

Логи контейнеров хранятся по таким путям, как:

/var/log/pods/ /var/log/containers/

Файлы в директории /var/log/containers обычно представляют собой символические ссылки, которые раскрывают информацию о поде, пространстве имен (namespace), контейнере и ID контейнера через свои имена файлов.

Это позволяет сборщику логов обогащать события контекстом без необходимости обязательного выполнения запросов к Kubernetes API.

Логирование CRI против устаревших логов Docker JSON

Среда выполнения контейнеров (container runtime) является важной частью архитектуры.

Kubernetes удалил dockershim в версии 1.24. Современные кластеры Kubernetes обычно используют среду выполнения Container Runtime Interface (CRI), такую как containerd или CRI-O.

Эти среды выполнения используют формат логирования Kubernetes CRI. Типичная запись выглядит так:

2026-08-14T09:26:31.123456789Z stderr F ERROR: connection to db-svc:5432 refused

Запись содержит:

• временную метку (timestamp);
• поток, например stdout или stderr;
• тег завершенности, например F или P;
• само сообщение лога.

Устаревшее логирование Docker json-file использует другую структуру:

{"log":"ERROR: connection to db-svc:5432 refused\n","stream":"stderr","time":"2026-08-14T09:26:31.123456789Z"}

Эта разница имеет определяющее значение при развертывании сборщика. Конфигурации, написанные специально для логов Docker JSON, могут не справиться с правильным парсингом логов в современных кластерах с containerd или CRI-O.

Что означают теги CRI P и F?

Третье поле в записи лога CRI указывает, считает ли среда выполнения запись завершенной.

• F указывает на полную запись лога (Full).
• P указывает, что запись является частичным фрагментом (Partial), и за ней следуют дополнительные данные.

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

Ротация логов контейнеров

Kubernetes также выполняет ротацию логов контейнеров. Компонент kubelet управляет ротацией через такие параметры, как:

• containerLogMaxSize
• containerLogMaxFiles

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

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

Почему сбор логов на уровне узла важен для SecOps

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

Для команд SecOps это означает, что локальные логи узла следует рассматривать как временную телеметрию, а не как долгосрочное хранилище доказательств.

Событие безопасности может стать недоступным, если:

• скомпрометированный под завершает работу;
• узел удаляется автомасштабировщиком кластера;
• рабочая нагрузка вытесняется (eviction);
• выполняется ротация логов контейнеров;
• происходит сбой узла;
• кластер пересоздается или мигрирует.

Централизованный сбор перемещает логи из этого нестабильного слоя и делает их доступными для обнаружения угроз, расследования инцидентов, threat hunting, комплаенса и криминалистического анализа.

Принципы безопасности для сборщика логов Kubernetes

Сам сборщик должен соответствовать архитектуре наименьших привилегий.

• Монтируйте директории логов хоста только для чтения (read-only). Сборщик должен читать логи без возможности изменять файловую систему хоста.
• Минимизируйте Kubernetes RBAC. Если метаданные можно извлечь из имен файлов и переменных окружения, разрешения на доступ к API в масштабе всего кластера могут не потребоваться.
• Шифруйте трафик к SIEM. Используйте TLS во всех случаях, когда целевая система это поддерживает.
• Используйте постоянное буферизованное хранение (persistent buffering). Временные сбои сети или SIEM не должны автоматически приводить к постоянным пробелам в логах.
• Защищайте учетные данные сборщика. Храните токены SIEM, сертификаты и другие секреты с использованием соответствующих механизмов Kubernetes.

NXLog Agent может потребовать привилегий root внутри контейнера сборщика для чтения файлов логов, принадлежащих всем рабочим нагрузкам. Это следует комбинировать с монтированием хоста в режиме read-only и минимальными разрешениями Kubernetes, необходимыми для развертывания.

Развертывание NXLog Agent в виде Kubernetes DaemonSet

NXLog Agent может быть развернут как DaemonSet, благодаря чему каждый узел Kubernetes получает собственный сборщик логов.

Следующая архитектура разработана для современных сред Kubernetes на базе CRI и позволяет собирать логи контейнеров без внесения изменений в приложения.

Шаг 1: Сборка образа NXLog Agent

Перед развертыванием DaemonSet создайте образ контейнера NXLog Agent, используя соответствующую процедуру установки NXLog.

Если агент должен читать логи, создаваемые всеми рабочими нагрузками, настройте контейнер для запуска с разрешениями, необходимыми для доступа к файлам логов хоста. Отправьте полученный образ в реестр контейнеров (container registry), доступный кластеру Kubernetes.

Для продакшен-развертывания избегайте использования локально собранных образов. Используйте версионированный образ в реестре и задавайте явный тег вместо latest.

Шаг 2: ServiceAccount и RBAC

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

Если сборщик извлекает информацию о поде и пространстве имен непосредственно из имен файлов логов, этого дополнительного доступа к API можно избежать.

Если обогащение через API необходимо, минимальный пример выглядит так:

apiVersion: v1 kind: ServiceAccount metadata: name: nxlog namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nxlog rules: - apiGroups: [""] resources: ["pods", "namespaces"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: nxlog roleRef: kind: ClusterRole name: nxlog apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: nxlog namespace: kube-system

Если доступ к API не требуется, опустите объекты ServiceAccount и RBAC и запустите сборщик с сервисной учетной записью по умолчанию.

Шаг 3: Развертывание DaemonSet

Упрощенный манифест DaemonSet может выглядеть следующим образом:

apiVersion: apps/v1 kind: DaemonSet metadata: name: nxlog namespace: kube-system labels: k8s-app: nxlog-logging spec: selector: matchLabels: name: nxlog template: metadata: labels: name: nxlog spec: serviceAccountName: nxlog tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule containers: - name: nxlog image: registry.example.com/nxlog:1.0 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName volumeMounts: - name: varlog mountPath: /var/log readOnly: true - name: nxlog-cache mountPath: /var/lib/nxlog volumes: - name: varlog hostPath: path: /var/log - name: nxlog-cache hostPath: path: /var/lib/nxlog type: DirectoryOrCreate terminationGracePeriodSeconds: 30

В этом манифесте важны несколько деталей.

Узлы Control-plane

Узлы управляющего слоя (control-plane) могут иметь тейнт NoSchedule. Если сборщик должен работать и на этих узлах, DaemonSet требует соответствующего толеранса (toleration).

Монтирование логов только для чтения

Директория хоста /var/log должна монтироваться с параметром readOnly: true. Это дает сборщику доступ к логам контейнеров и системы без предоставления прав на запись в файловую систему логов хоста.

Сохранение состояния агента (Persistent Agent State)

Монтирование доступной для записи директории /var/lib/nxlog обеспечивает постоянное хранилище для кэша и позиций чтения агента. Без сохранения состояния перезапущенный сборщик может повторно прочитать ранее обработанные файлы логов.

Шаг 4: Настройка NXLog Agent для логов контейнеров Kubernetes

Наиболее важная деталь конфигурации — поддержка как современного формата CRI, так и устаревших логов Docker JSON, если кластер содержит смешанную среду выполнения.

CacheDir /var/lib/nxlog envvar NODE_NAME <Extension json> Module xm_json </Extension> <Input k8s_containers> Module im_file File '/var/log/containers/*.log' <Exec> # CRI format: # timestamp stream P|F message if $raw_event =~ /^(\S+) (stdout|stderr) ([FP]) (.*)$/ { $EventTime = parsedate($1); $stream = $2; $Message = $4; } else { # Legacy Docker JSON format parse_json(); $EventTime = parsedate($time); $Message = $log; delete($log); delete($time); } $log_type = "k8s_container"; $log_file = file_name(); $k8s_node = '%NODE_NAME%'; # Extract pod, namespace and container information # from the Kubernetes container-log filename. if $log_file =~ /\/.*\/(.+)_(.+)_(.+)-(.+).log$/ { $k8s_pod = $1; $k8s_namespace = $2; $k8s_container = $3; $k8s_container_id = $4; } </Exec> </Input>

Эта конфигурация считывает файлы из /var/log/containers, определяет формат CRI, используемый современными средами выполнения контейнеров, и сохраняет ветку парсинга JSON для устаревших сред на базе Docker.

Она также извлекает полезный контекст Kubernetes из имени файла:

• Имя пода
• Пространство имен (namespace)
• Имя контейнера
• ID контейнера
• Имя узла (node name)

Такое обогащение может выполняться без предоставления сборщику широкого доступа к Kubernetes API.

Пересылка логов Kubernetes в Microsoft Sentinel

NXLog Agent может пересылать собранные события Kubernetes в Microsoft Sentinel с помощью Azure Monitor Logs Ingestion API.

Упрощенная конфигурация вывода выглядит так:

<Output sentinel> Module om_azuremonitor API LogsIngestion ClientId <entra-app-client-id> ClientSecret <entra-app-secret> TenantId <entra-tenant-id> URL https://<your-dce>.ingest.monitor.azure.com DcrImmutableId dcr-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx StreamName Custom-K8sContainers-Stream Exec to_json(); </Output>

Структура события должна быть выровнена с столбцами, определенными в правиле сбора данных (Data Collection Rule) и потоке Microsoft Sentinel.

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

Пересылка логов Kubernetes в Splunk

Для сред Splunk агент NXLog Agent может отправлять события Kubernetes в Splunk HTTP Event Collector (HEC).

<Output splunk_hec> Module om_http URL https://splunk.example.com:8088/services/collector/event AddHeader Authorization: Splunk <hec-token> HTTPSCAFile %CERTDIR%/splunk-ca.pem <Exec> $raw_event = '{"event":' + to_json() + '}'; </Exec> </Output>

Для развертывания в продакшене включите соответствующие метаданные Splunk, такие как time, host и sourcetype, чтобы события Kubernetes можно было эффективно искать и сопоставлять.

Шаг 5: Развертывание и проверка DaemonSet

Примените манифест:

$ kubectl apply -f nxlog-daemonset.yml

Затем проверьте DaemonSet:

$ kubectl -n kube-system get daemonset nxlog

Значение DESIRED должно соответствовать количеству узлов, которые должен охватывать DaemonSet.

Также проверьте отдельные поды сборщика:

$ kubectl -n kube-system get pods -l name=nxlog -o wide

На стороне SIEM правильно обогащенное событие должно содержать информацию, аналогичную следующей:

{ "EventTime": "2026-10-05T09:26:31.123456+00:00", "stream": "stderr", "Message": "ERROR: connection to db-svc:5432 refused", "log_type": "k8s_container", "k8s_node": "node003", "k8s_pod": "payments-api-7f6d9c5b8-x2kkq", "k8s_namespace": "prod", "k8s_container": "payments-api", "k8s_container_id": "bdc9da43d94800e213477bbddbc9f96fa7a32b680509580cfce97fa4186d63e5" }

Для SecOps этот контекст делает событие значительно более полезным, поскольку аналитики могут сразу определить рабочую нагрузку, namespace, узел и контейнер, связанные с событием.

Сбор логов аудита Kubernetes с помощью NXLog Agent

Логи контейнеров показывают, что делают рабочие нагрузки. Логи аудита Kubernetes показывают, что пользователи и службы делают с Kubernetes API.

Записи аудита могут раскрыть:

• кто обращался к Kubernetes API;
• к каким ресурсам запрашивался доступ;
• какие действия были выполнены;
• были ли запросы разрешены или отклонены;
• какая сервисная учетная запись (service account) инициировала операцию.

Это делает логи аудита Kubernetes особенно ценными для мониторинга безопасности и реагирования на инциденты.

После включения аудита Kubernetes API-сервер может записывать события аудита в файл, например:

/var/log/kubernetes/audit.log

NXLog Agent может собирать этот файл через дополнительный модуль ввода:

<Input k8s_audit> Module im_file File '/var/log/kubernetes/audit.log' BufferSize 150000 <Exec> parse_json(); $log_type = "k8s_audit"; $k8s_node = '%NODE_NAME%'; </Exec> </Input>

События аудита могут быть значительно больше обычных записей логов приложений. При необходимости увеличьте размеры входного и выходного буферов, чтобы предотвратить усечение (truncation) больших записей аудита.

Также следует учитывать ротацию логов аудита. Централизованный сбор предотвращает превращение локальной политики ротации API-сервера в фактическую политику хранения логов безопасности.

Управление сборщиками логов Kubernetes с помощью NXLog Platform

DaemonSet решает задачу развертывания: он гарантирует, что сборщик работает на требуемых узлах.

Однако он не решает все операционные задачи.

Крупным средам Kubernetes также необходимо иметь ответы на такие вопросы, как:

• Какие агенты в настоящее время исправны?
• Какие узлы перестали отправлять логи?
• Как обновить правило парсинга на сотнях узлов?
• Как новые узлы могут автоматически получать правильную конфигурацию?
• Как централизованно управлять различными конечными точками SIEM?

NXLog Platform обеспечивает централизованное управление агентами NXLog, позволяя организациям управлять конфигурациями и отслеживать статус агентов из единого интерфейса.

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

Это особенно ценно при изменении архитектуры логирования — например, когда требуется развернуть новое правило парсинга CRI, изменить SIEM-назначение, политику фильтрации или контроль безопасности по всему кластеру.

Распространенные ошибки при логировании в Kubernetes

1. parse_json() сбоит на логах контейнеров

Если кластер использует containerd или CRI-O, логи контейнеров обычно используют текстовый формат CRI, а не формат JSON от Docker.

Конфигурация, которая слепо вызывает parse_json() для каждой записи, может не справиться с правильным парсингом современных логов Kubernetes.

Решение состоит в том, чтобы сначала определить формат CRI и сохранить парсинг JSON только как ветку совместимости для устаревших сред Docker.

2. Многострочные трассировки стека разбиваются на отдельные события

Логирование контейнеров в Kubernetes ориентировано на строки. Поэтому трассировка стека Java, трассировка Python или аналогичное многострочное событие приложения могут поступать в виде нескольких отдельных записей.

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

Длинные записи CRI также могут разбиваться на частичные записи с пометкой P до поступления финального фрагмента F. Конвейер сбора должен учитывать это, когда приложения генерируют очень длинные сообщения.

3. DaemonSet не запускается на узлах Control-Plane

Если количество подов DaemonSet ниже ожидаемого, проверьте тейнты (taints) на отсутствующих узлах:

$ kubectl describe node <node-name>

Узлы Control-plane обычно используют тейнт NoSchedule, поэтому DaemonSet должен включать соответствующий толеранс (toleration), если эти узлы также необходимо мониторить.

4. События аудита Kubernetes усекаются

События аудита могут быть значительно больше обычных сообщений приложений.

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

5. Агент повторно отправляет старые события после перезапуска

Сборщику на основе файлов необходимо сохранять позиции чтения.

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

Используйте постоянное хранилище (persistent storage) для кэша NXLog Agent, когда ваши операционные требования требуют надежного возобновления работы.

Чек-лист безопасности логирования Kubernetes

Мера контроля	Рекомендация
Монтирование логов хоста	Монтируйте директории логов хоста в режиме только для чтения (read-only).
RBAC	Предоставляйте разрешения Kubernetes API только тогда, когда требуется обогащение данных через API.
Транспорт	Используйте TLS при отправке логов во внешние SIEM или централизованные сборщики.
Буферизация	Используйте постоянные очереди или буферизацию для защиты от временных сбоев целевых систем.
Ротация логов	Отправляйте важные логи до того, как Kubernetes выполнит ротацию и удалит локальные файлы.
Многострочные логи	Внедрите многострочную обработку для приложений, создающих трассировки стека или аналогичные события.
Логи аудита	Собирайте события аудита Kubernetes API централизованно и отслеживайте доступ к конфиденциальным ресурсам.
Учетные данные	Храните токены SIEM, сертификаты и секреты вне образов контейнеров.
Состояние агента	Используйте постоянное хранилище для состояния сборщика там, где необходимо минимизировать дублирование или потерю событий.

Почему NXLog Agent подходит для Kubernetes SecOps

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

NXLog Agent решает эти задачи за счет:

• нативного сбора из файлов логов узлов Kubernetes;
• поддержки современных сред логирования на базе CRI;
• парсинга и обогащения событий;
• поддержки Syslog, HTTP и других вариантов вывода;
• доставки логов с защитой TLS;
• постоянных очередей и буферизации;
• сбора данных с Linux, Windows и других корпоративных источников;
• централизованного управления через NXLog Platform.

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

Заключение: Отправляйте логи Kubernetes до того, как кластер их удалит

Кластер Kubernetes может генерировать огромные объемы телеметрии безопасности и операционных данных, но большая часть этих данных изначально хранится только на отдельных узлах.

Сборщик логов на основе DaemonSet обеспечивает масштабируемый способ перемещения этих данных за пределы узла без модификации подов приложений. По мере роста кластера слой логирования растет вместе с ним.

Ключ к успеху — проектирование конвейера с учетом того, как современный Kubernetes реально записывает логи: форматы на базе CRI, ротация логов на уровне узла, краткоживущие нагрузки, тейнты control-plane, многострочные события и временные сбои целевых систем.

NXLog Agent предоставляет гибкий слой сбора для логов контейнеров и аудита Kubernetes, а NXLog Platform позволяет централизовать конфигурацию и мониторинг всего парка агентов.

Softprom является официальным партнером NXLog и помогает организациям проектировать и внедрять архитектуры централизованного сбора логов, интегрировать телеметрию Kubernetes с платформами SIEM и строить надежные конвейеры мониторинга безопасности.

Свяжитесь с Softprom, чтобы обсудить ваши требования к логированию Kubernetes и подобрать оптимальную архитектуру NXLog для вашей среды.