[k8s] Define missing roles for entity attributes

[ChrsMark]

Related to #3120

Changes

This PR adds roles for entity attributes that were missing this.

⚠️ Note that for k8s.namespace.name can be an identifying attribute within the scope of a K8s a cluster, hence k8s.namespace.uid is not defined at all nor used in k8sattributes processor of the Collector. I'd love to hear what people think about this and if we should consider introducing the k8s.namespace.uid as an identifying attribute for consistency across k8s resources/entities.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[ChrsMark]

/cc @open-telemetry/semconv-k8s-approvers

[jsuereth]

I'm still not certain we need to have this be identifying.

When grouping based on a k8s.container do I want to have restarts be considred separate containers?

It seems to me like you want to leverage a diffrent entity (like service.instance.id) to distinguish containers by restart. Or you need something like "Container instance" entity that would track this.

[ChrsMark]

When grouping based on a k8s.container do I want to have restarts be considred separate containers?

Hmm, I think you are right.

I remember the reason for having container's restart count both as an attribute and as a metric was to be able to use the attribute for identifying from which container instance a log was collected from. Specifically this is used for container's logs at https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/stanza/docs/operators/container.md#add-metadata-from-file-path (not sure if used in other places too).

I'll defer to @dmitryax here since he should remember more details.

It seems to me like you want to leverage a diffrent entity (like service.instance.id) to distinguish containers by restart. Or you need something like "Container instance" entity that would track this.

Probably for that purpose we could just use the container.id which k8sattributes processor can add if k8s.container.name is present? I can try and come-up with a configuration that verifies this.

[ChrsMark]

@jsuereth I have changed the k8s.container.restart_count to descriptive attribute. Thinking of it again, a k8s.container within the Pod's scope can be uniquely identified by its name: 37887f0

@dmitryax please confirm

[ChrsMark]

Chatted a bit about this with @dmitryax during last K8s SIG meeting.
Probably what we will need for "capturing" the k8s container's restarts/instances is sth like a k8s.container.instance entity similar to

semantic-conventions/model/service/entities.yaml

Lines 18 to 31 in fd1fb75

	- id: entity.service.instance
	type: entity
	name: service.instance
	brief: >
	A unique instance of a logical service.
	note: >
	A `service.instance` uniquely identifies an instance of a logical service. For example,
	a container that is part of a Kubernetes deployment
	that offers a service.
	stability: development
	attributes:
	- ref: service.instance.id
	role: identifying
	requirement_level: required

. However for k8s.container entity the k8s.container.restart_count is just a descriptive attribute.

[jsuereth]

Thanks for following up on this! I think I agree, and I'm hoping as entity work lands in the collector, can start getting a practical feel for these decisions with OTEL-Operator / log collection architecture for k8s.