Release Notes

v1.0.11

Changes

• Optimized the ClusterLogDestination transformations to reduce the agent CPU load.

Bug fixes

• Fixed handling of special characters ({{ }}, $, non-ASCII) in label values.
• Fixed addLabels references to label keys with /, such as {{ .pod_labels."app.kubernetes.io/name" }}.
• Fixed In/NotIn filters for numeric field values: string filter values now match integer fields.
• Fixed the syslog format of the Socket destination: an unknown or numeric syslog.severity, a missing timestamp or a non-string message no longer make the agent send the message without the syslog header.

Security

• Fixed CVE-2026-63209 in the module images.

v1.0.10

Security

• Fixed CVE-2026-56857, CVE-2026-56866, CVE-2026-78659, CVE-2026-78660, CVE-2026-78663, CVE-2026-78667, CVE-2026-78669, CVE-2026-94439, CVE-2026-94440, CVE-2026-94448, CVE-2026-97030, CVE-2026-97031 and CVE-2026-97032 in the module images.

v1.0.9

Bug fixes

• Fixed the log collection agent failing to start on a node after an unclean stop (for example, an out-of-memory kill or a node reboot) when a destination uses a disk buffer (buffer.type: Disk in ClusterLogDestination). The buffer is kept on the node disk, and if the stop damaged the end of the buffer, the agent crashed on every start on that node until the buffer directory was removed by hand. Now the agent starts and continues delivering logs. The log entries from the damaged part of the buffer may be lost, and the vector_buffer_discarded_events_total metric for that destination shows a one-off very large value.

v1.0.8

Changes

• Stricter validation of log sources and destinations. In ClusterLoggingConfig, the file source now requires include with at least one non-empty path pattern, and the include and exclude patterns are checked for correct glob syntax when the agent configuration is generated: ***, ** inside a path component and an unclosed [ range are rejected. An invalid pattern is reported as a configuration generation error with the name of the resource, and the agent configuration is not updated until the resource is fixed. Previously such a pattern crashed the agent. In ClusterLogDestination, the Loki tenantID now accepts only the characters Loki allows, {{ field }} templates and strftime specifiers such as %Y; other values are rejected when the resource is created or updated.

Bug fixes

• Fixed agent crashes. The log collection agent no longer crashes and restarts in these cases: a file source with an invalid path pattern or a log file with a non-UTF-8 name; a disk buffer file that has already been deleted from the node by the time the agent finishes reading it; a configuration reload while one of the sources or destinations has already stopped with an error (the agent now shuts down gracefully and the pod restarts cleanly); a pod whose log directory contains special glob characters, such as a static pod with the kubernetes.io/config.mirror annotation; a Loki destination whose tenantID renders into a value that cannot be sent as an HTTP header (the batch is now dropped with an error in the metrics and the agent keeps running).
• Fixed the maxSize of the disk buffer in ClusterLogDestination for values of 4Gi and more. The value overflowed, so 4Gi turned into the 256MiB minimum and 5Gi into 1Gi; now the configured size is applied.
• The agent now validates the generated configuration at startup before applying it, as it already did on updates; previously the initial configuration was applied without validation. If the configuration is invalid, the agent keeps running without it and reports the vector_config_validation_error metric. A configuration update that arrives during this validation is not lost, and the configuration file is written atomically, so the agent never reads a partially written file.

v1.0.7

Features

• Read order and read portion size for log files. The kubernetesPods and file sources in ClusterLoggingConfig and PodLoggingConfig accept two new parameters. maxReadBytes limits how many bytes are read from one file in a pass before the agent moves on to the next file, so reads are spread more evenly across many actively growing files. oldestFirst makes the agent finish older files before reading newer ones. When not set, the agent behaves as before: pod logs are read oldest first, files are read evenly, and a read portion is 2048 bytes. The agent also no longer attaches the container ID, image ID, pod IP list, pod annotations, pod UID and namespace labels to each collected pod log entry. These fields were removed before sending, so the exported logs do not change.

Bug fixes

• Fixed the event time for the Loki, Splunk, Vector and Socket (GELF codec) destinations. The agent converted the timestamp of every log entry to a string in the node local timezone, and these destinations, which take the event time only from a typed timestamp, stored the time the entry was sent instead of the time it was written. Now the timestamp reaches them unchanged, so the timestamp field in the entry is in UTC instead of the node local timezone; for Splunk the local-time string is kept in the datetime field. Elasticsearch, Logstash, Kafka and Socket with other codecs still receive the timestamp as a string in the node local timezone. The conversion now runs right before the destination transformations, and a timestamp already replaced by a transformation is left as is.

v1.0.6

Features

• Dropping log entries per destination. The new DropEvent transformation in ClusterLogDestination drops a log entry when all conditions in when are true. The conditions use the same syntax as in AddLabels, and the transformation runs at its position in the list, so it can rely on labels added by earlier transformations. Unlike logFilter and labelFilter in ClusterLoggingConfig, which filter at the source for all destinations, DropEvent applies only to the destination where it is set.

Changes

• Logs collected from Kubernetes pods now carry the host_ip label with the IP address of the node the pod runs on. Logs collected from files already had it.

v1.0.5

Enhancements

• The examples documentation now explains how multiple ParseMessage transformations are processed: they are applied to each log entry from top to bottom, and once one of them parses the entry successfully, the rest are skipped. Transformations for specific formats, such as JSON, should therefore come first, and the universal string transformation last.

v1.0.4

Bug fixes

• Fixed the ReplaceValue transformation with a literal replacement string (without named groups in target). The log collection agent rejected the generated configuration, so the transformation did not work.

v1.0.3

Changes

• System metrics of the log collection agent now carry the d8_source="dkp" label. It allows platform metrics to be told apart from metrics exposed by user applications.
• The module namespace is now checked against the restricted Pod Security Standards profile. Violations are reported as warnings only and do not block workloads. The deviations the agent requires — running as root and mounting node paths to read container and node logs and to store its read position — are declared and explained in the SecurityPolicyException resource shipped with the module, so log collection keeps working without any action.
• The privileges of the agent are reduced as far as log collection permits: the RuntimeDefault seccomp profile is applied, all Linux capabilities are dropped, privilege escalation is denied, and the container root filesystem is read-only.
• The registry.dockercfg module configuration parameter is removed. Module images are always pulled with the platform registry credentials, so if the parameter is set in the module configuration, remove it before updating.

Security

• Fixed various vulnerabilities.

v1.0.2

Bug fixes

• Fixed links between documentation pages and in custom resource descriptions that had been broken after the module was moved to a separate repository.

v1.0.1

Changes

• Module images are now built using the container-base images and the pm package manager.

Security

• Fixed various vulnerabilities. The module now ships a VEX document listing the vulnerabilities of its dependencies that cannot affect it, along with the reason for each.

v1.0.0

Changes

• Resource management in the Static mode is reworked: CPU and memory requests are now set in the resourcesRequests.static.requests section, and CPU and memory limits for the agent can be configured in resourcesRequests.static.limits. Existing module configuration is converted automatically, so no action is required.

Bug fixes

• Fixed the CPU and memory requests configured for the Static resource management mode not reaching the log collection agent container.