- Expose an additional configuration inside the ClusterLogForwarder CR that allows to define a list of pod labels (key/value pair).
The Log Forwarding API currently only exposes the ability for users to select logs by their namespace. Although that gives a lot of flexibility already, we've seen cases where more is needed. For example, there are some applications that may be deployed multiple times on multiple namespaces (e.g. any webserver). Now you only want aggregate all logs from this specific application to a single location (e.g. if you created dedicated indices in Elasticsearch or log groups on CloudWatch).
If there was a way to select logs from only certain applications identified by pod labels, you could target specific indices or use dedicated systems.
The Log Forwarding API abstracts away the individual technology underneath and uses standard k8s features to identify applications of interest. The two standard ways to group and identify k8s applications are namespaces and labels. There are no other alternative k8s-native ways to identify or select groups of k8s objects.
Note: K8s annotations are used for non-identifying metadata so are not suitable for this purpose.
- Verify that the receiving system only receives the selected logs.
- Verify that using a combination of `namespaces` and the new option (e.g. `labels`) will filter logs based on both values (e.g. forward logs from pods in selected namespaces and with the defined labels).
- Document the syntax and limitations for the new Log Forwarding API field.
- Document behaviour to when users mix namespace and pod label filtering.
- Provide an example.
- https://github.com/banzaicloud/fluent-plugin-label-router -> fluentd plugin that routes records based on k8s labels.