Include k8s.pod.ip attribute in k8sattributes preset

[ChrsMark]

With the addition at open-telemetry/opentelemetry-collector-contrib#33440 to provide the option to explicitly export the k8s.pod.ip (in case it's not already added) I think it makes sense to enable this in the preset as well.

[jaronoff97]

we should be bumping the patch version i.e. 0.100.1 here :)

[TylerHelmuth]

I'd like to hear more about why this should be enabled by default. I'm not sure everyone would want the IP recorded on their telemetry.

[ChrsMark]

My idea here is mostly to achieve consistency. The preset defines the following pod_associations:

pod_association:
- sources:
  - from: resource_attribute
    name: k8s.pod.ip
- sources:
  - from: resource_attribute
    name: k8s.pod.uid
- sources:
  - from: connection

So this implies that some incoming data already have the k8s.pod.ip attribute based on which the metadata association is performed. The output of this processor still has the k8s.pod.ip obviously.
However, since we have 2 other pod_assocation rules, incoming data without a pre-existing k8s.pod.ip attribute will be enriched based on the k8s.pod.uid, for instance, and come out of the processor but this time without the k8s.pod.ip because this is not added explicitly by the processor.

This is in principle correct, because this is what we instruct the processor to do through the defined configuration, however users that just enable the preset without really diving into the details of its underlying (advanced :)) configuration might find this tricky to be explained and even complain about this being buggy. We have some relevant reports in Collector's contrib repository about the processor not being so clear what metadata it actually adds and I have spotted this k8s.pod.ip question specifically in some private conversations.

Consequently, my only intention was to avoid this kind of confusion and make the processor to always add the k8s.pod.ip if that's not already there so as all output data of the processor to be consistent.
I don't have any strong preference here though, so if there are reasons for not adding this I'm just fine :).

[povilasv]

I think k8s.pod.ip should be opt-in, one can use k8s attributes processor in many ways, for example enriching metrics coming from k8scluster receiver, then this would add new high cardinality attribute to the metric backends, which might be not even needed 🤔

[ChrsMark]

That make sense @povilasv. I agree this could potentially bring more trouble than convenience. I'm gonna close this PR then. Thank's for the feedback @TylerHelmuth @povilasv!