Expanding k8s.pod resource to include pod labels

[tokaplan]

Changes

This adds support for pod's labels to k8s.pod resource.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• [no changes to existing conventions] schema-next.yaml updated with changes to existing conventions.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: tokaplan / name: Alexander Kaplan (12feabe, bdb4799, 759931f, 0e2be58, a9e1b3b, f5b5960, 5523d93, ff30d0b, 5f94f4a, ef6bfb3, c8bbeb9, 7a35e0d, 9d7efbe, 6e6975c, 3fa6a81, 3f06aa1, 2c36c8b)
• ✅ login: arminru / name: Armin Ruech (9628f3c)
• ✅ login: AlexanderWert / name: Alexander Wert (3cf9ef1, 7686445, 8c1090f)

[trask]

cc future semconv-k8s-approver @frzifus @dmitryax @ChrsMark @mx-psi @TylerHelmuth @jinja2 @dashpole @mlunadia

[trask]

closing and re-opening to try to retrigger CI checks which seem stuck

[dashpole]

This makes sense to me. It seems more usable than a []string for k8s.pod.labels and follows the existing pattern set by container.labels.

[ChrsMark]

Hey @tokaplan since the k8s attributes are already in the registry shall we add the new one to the registry as well?

It would need an update to the registry's markdown as well.

[tokaplan]

Hey @tokaplan since the k8s attributes are already in the registry shall we add the new one to the registry as well?

It would need an update to the registry's markdown as well.

@ChrsMark Done, thank you

[ChrsMark]

LGTM, thanks!

[dmitryax]

The change looks good to me from the semantic conventions perspective. This pattern is already being used in the collector's k8sattributes processor.

I'm not sure about utilizing this definition. AFAIK, this is the first example of a "partial" attributes definition. So, I'm not sure that the tooling that generates the semantic conventions code in the instrumentation libraries and collector will not fail. Even if doesn't fail, the generated code likely will be useless. Should we prepare for that before merging this PR by properly supporting this new type of resource attributes? Or at least provide a way to mark them in some way to skip the code generation?

[AlexanderWert]

The change looks good to me from the semantic conventions perspective. This pattern is already being used in the collector's k8sattributes processor.

I'm not sure about utilizing this definition. AFAIK, this is the first example of a "partial" attributes definition. So, I'm not sure that the tooling that generates the semantic conventions code in the instrumentation libraries and collector will not fail. Even if doesn't fail, the generated code likely will be useless. Should we prepare for that before merging this PR by properly supporting this new type of resource attributes? Or at least provide a way to mark them in some way to skip the code generation?

@dmitryax Please see this comment: #494 (comment)