[processor/resourcedetection]: Add support for k8s.cluster.name where possible

[gouthamve]

Component(s)

processor/k8sattributes

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

When using the k8sattributes processor, I shouldn't need to declare any attributes manually. I still need to manually specify k8s.cluster.name as the processor doesn't support it yet.

There is no standard API to get the cluster name, but GKE and EKS make it easy to detect. We should support this in the processor and provide k8s.cluster.name where possible.

Describe the solution you'd like

For GKE, See: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/deb9aa441dc7d2b0fd5ec11b41c934a1e93134fd/detectors/node/opentelemetry-resource-detector-gcp/src/detectors/GcpDetector.ts#L81 (it gets it from curl http://metadata/computeMetadata/v1/instance/attributes/cluster-name -H "Metadata-Flavor: Google")

For EKS see: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/deb9aa441dc7d2b0fd5ec11b41c934a1e93134fd/detectors/node/opentelemetry-resource-detector-aws/src/detectors/AwsEksDetector.ts#L86 (it gets it from the cert name on kubernetes.default.svc, iiuc)

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• processor/k8sattributes: @dmitryax @rmfitzpatrick @fatsheep9146 @TylerHelmuth

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

[TylerHelmuth]

I wonder if this would be better suited for the resourcedetectionprocessor where we already have some GKE and EKS specific functionality

[crobert-1]

The resource detection processor is the best place for this. The k8s cluster name is actually already included for GKE, but not for EKS. I think it's a good idea.

[github-actions]

Pinging code owners for processor/resourcedetection: @Aneurysm9 @dashpole. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[crobert-1]

I'll work to add this.

[jinja2]

re: EKS cluster name, the example linked library is getting the cluster name from configmap cluster-info from namespace amazon-cloudwatch. I think the referenced configmap is only created in an eks cluster if cloudwatch agent with fluentd is installed (checked an eks cluster and this is definitely not available by default). So I don't think we should be adopting the same approach.

The aws-auth configmap which is used in the detector to verify if the collector is running in an EKS cluster also does not have any info which can be used to derive the cluster name.

EC2 instances run as workers in eks should have tags such as kubernetes.io/cluster/CLUSTER_NAME, eks:cluster-name or the billing tag aws:eks:cluster-name. So checking the tags might be a viable approach. One issue with this might be access to querying tags. Tags are not available from instance metadata by default, so the IAM role assigned to the node might need updating (usually the AWS managed role AmazonEKSWorkerNodePolicy is used and it allows ec2:DescribeInstance).