Збирання логів у Kubernetes DaemonSet: практичний посібник для 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 для вашого середовища.