Resource dectection for Open-Source platforms should be distinct from cloud-provider detection

[dashpole]

Background

Currently, resource detection for GKE and EKS is done in separate packages (EKS, GKE), and have diverged in what they detect (container id vs container name, pod name, pod namespace), and how they detect those attributes (reading cgroup for container ID vs environment variables for pod name, namespace, container name).

It would be nice to be able to give users a consistent story around resource detection on kubernetes regardless of cloud provider.

As a potential use-case, it would be nice to be able to keep my application cloud-provider agnostic, and only use the kubernetes detector. Then, depending on the cloud-provider, I can send my telemetry to a collector that adds cloud-provider-specific attributes. This makes my application portable, which is one of the selling points of kubernetes.

Proposed Solution

Principle: A resource detector should detect at most one category of resource from the semantic conventions.

Users should install all relevant categories of resource (e.g. on GKE I should install GKE, GCE, and Kubernetes detectors)

Alternative: Resource detectors can "wrap" other resource detectors (e.g. GKE includes the GCE and Kubernetes detectors, but doesn't re-implement detection).

We should introduce a separate "kubernetes" resource detector, that detects all kubernetes attributes, and a "container" detector that detects container attributes.

Cloud providers should only detect cloud-provider-specific resource attributes.

Let me know if this should be an OTEP instead...

[dashpole]

cc @aabmass

[Aneurysm9]

I think this seems like a reasonable proposal. It would probably be good to make an OTEP to get broader feedback and see if we can make the pattern consistent across all implementations, but I don't see why we'd need to let that stop us from moving forward with it if we thing it is the right thing for our implementation.