[processor/k8sattributes] Allow adding custom attributes from the ownerReferences chain

[kamalmarhubi]

Component(s)

processor/k8sattributes

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

We use Argo Rollouts to allow us to do canary deployments. There are effectively a replacement for the Deployment resource, but with some additional control over the rollout process. Under the hood it works similarly to the Deployment controller: it creates ReplicaSets and adjusts their relative sizes; it just uses different criteria for making those adjustments.

Until #14003, the k8sattributeprocessor happily put the rollout's name in the k8s.deployment.name attribute, because the deployment name was based on a regex of the replicaset name. This wasn't exactly accurate, but it was definitely handy to have a common attribute across pods belonging to a Rollout.

We haven't upgraded yet, but when we do this change will mean we lose this common attribute for pods in our lower-case-deployments, which are Rollouts instead of Deployments.

Describe the solution you'd like

I'd like to be able to configure the processor to add the name of a specific resource kind in the ownerRef chain. For my example of a Rollout, I'm imagining adding an PodOwners along side Metadata, Labels, and Annotations in the ExtractConfig.

The semantics would be to follow ownerReferences from the pod, and if one matches the configured api version and kind, add its name and/or uid as an attribute.

This would mean my Rollout example could look like

k8sattributes:
  # [...]
  extract:
    metadata:
    - k8s.pod.name
    - k8s.pod.uid
    - k8s.deployment.name
    - k8s.namespace.name
    - k8s.node.name
    - k8s.pod.start_time
    pod_owners:
    - tag_name_prefix: argocd.rollout
      api_version: argoproj.io/v1alpha1
      kind: Rollout
      attributes:
      - name
      - uid

or some similar alternative, eg require the .uid and .name fields to be listed individually:

    pod_owners:
    - tag_name: argocd.rollout.name
      api_version: argoproj.io/v1alpha1
      kind: Rollout
      metadata_field: name
    - tag_name: argocd.rollout.uid
      api_version: argoproj.io/v1alpha1
      kind: Rollout
      metadata_field: uid

I'm not sure if it's necessary to allow arbitrarily long ownerReferences chains. For Rollouts, it happens to have the same number of levels as Deployments (pod -> replicaset -> "real owner"). But if someone were using Flagger, then it manages a pair of deployments rather than managing replicasets directly, so the chain to the Canary object is pod -> replicaset -> deployment -> Canary.

Describe alternatives you've considered

The main alternatives I see are:

• add the attribute via OTEL_RESOURCE_ATTRIBUTES
  • this would work so long as we remember to do so in every place we use rollouts
• don't upgrade to 0.78 or later
  • we'll want to upgrade eventually!
• fork the processor and modify it to handle the specific case we care about (Rollout)
  • doable but means we'll have to keep cherry-picking our change on top of upstream, and continue to run a custom build
• adapt the transformprocessor workaround from [processor/k8sattributes] Excessive heap usage from k8sattributes processor after 0.78.0 upgrade #23067 (comment)
  • would probably work, but regex weirdness was the reason for [processor/k8sattribute] support attribute k8s.deployment.uid #14003 in the first place

Additional context

There's some conversation in #23067 which is slightly relevant but doesn't get in the way of implementing this. The suggestion there is to stop tracking replicasets, and instead walk the ownerReferences chain from the pod directly, storing the replicasets' deployment metadata in an LRU cache.

[github-actions]

Pinging code owners:

• processor/k8sattributes: @dmitryax @rmfitzpatrick @fatsheep9146

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

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/k8sattributes: @dmitryax @rmfitzpatrick @fatsheep9146 @TylerHelmuth
• needs: Github issue template generation code needs this to generate the corresponding labels.

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

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.