[processor/k8sattributes] Add support for extracting labels and annotations from Deployments, StatefulSets, Jobs, and DaemonSets

[hamfila]

Component(s)

processor/k8sattributes

Is your feature request related to a problem? Please describe.

Currently, the k8s attributes processor is capable of extracting labels and annotations from pods, namespaces, and nodes. It would be great if the processor could be extended to also support extracting metadata from high-level workloads, like Deployments, StatefulSets, Jobs, and DaemonSets.

Describe the solution you'd like

metadata.labels and metadata.annotations can be extracted from Deployments, StatefulSets, Jobs, and DaemonSets.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• processor/k8sattributes: @dmitryax @fatsheep9146 @TylerHelmuth @ChrsMark

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dmitryax]

Hi @hamfila. Thanks for filing the issue. This feature would be nice to have. However, I don't think anyone from code owners has time to work on it. Please feel free to contribute.

[bacherfl]

@dmitryax I could offer to look into implementing this

[bacherfl]

FYI I had a brief look into how this could be implemented - right now, the k8sattributes processor gathers information by having one informer for pods, nodes, namespaces, and replicasets (which suffices to get the currently supported information from high level workloads, such as deployment name, etc).
If also the labels and annotations from high level workloads should be added, this means that we need to run additional informers for each type (deployment, statefulset, daemonset, etc). This can certainly be done, but will likely result in higher resource consumption and additional rbac permissions to be required.
I'd still be happy to look into implementing this, but would like to clarify first if the additional informers and rbac permissions are worth introducing. In any case, we'd have to make these optional and only attempt to start the additional informers if this is enabled explicitly in the config, otherwise this might break existing collector deployments due to the lack of permissions

[odubajDT]

pinging here regarding @bacherfl thoughts @dmitryax @TylerHelmuth @ChrsMark @fatsheep9146

[odubajDT]

I would suggest creating a separate PR for each workload type due to the complexity of the implementation. Will finish the first PR for Deployments in short time