Is it correct that there are no attributes in any of these metrics?

As mentioned at https://github.com/open-telemetry/semantic-conventions/pull/2267/files#r2120289448, instead of just defining the metrics as-is from the Collector's implementation we should work on defining them correctly.

We do this for all the metrics of #1032 and we have already "breaking" changes that we plan to handle through a specific migration process once we have k8s metrics to GA. We document these diffs at https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/k8s-migration.md

That said, the missing piece here is if we should have a k8s.node.allocatable.* namespace with all the sub-resources attached (cpu, memory etc) or if we should re-use the existing k8s.node.cpu.*, k8s.node.memory namespaces. I don't have a strong preference for any of these 2, but maybe picking the k8s.node.allocatable.* namespace will better align context-wise?

Can we also list how these metrics are different to what Collect has today? We track those diffs at https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/k8s-migration.md#summary-of-changes

LGTM! Thank's for contributing this!

I think this PR is not affected by the discussion on naming UpDownCounters https://github.com/open-telemetry/semantic-conventions/pull/2317/files, so giving my approval.

For the implementation, consider this important fact when using UpDownCounters: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/metrics.md#consistent-updowncounter-timeseries