[k8s] Promote k8s and container memory metrics to RC

[ChrsMark]

This issue tracks the promotion to RC of the following metrics:

• *.memory.usage
• *.memory.available
• *.memory.rss
• *.memory.working_set

Relevant issues to take into account:

• Ensure container.* metrics are populated in a unified way #2418
• [k8s stability] Improve k8s memory metrics' descriptions #2853

[ChrsMark]

Summarising the information for these metrics for my own benefit:

container.memory.usage

tldr: memory.current of cgroup

It is derived from the UsageBytes of kubelet. This comes from the Usage of cAdvisor which is set at https://github.com/google/cadvisor/blob/44b8e3062d678022939d40b2a2e9b259b07ebab0/lib/container/libcontainer/handler.go#L824 from the MemoryStats.Usage.Usage of the opencontainers/cgroups/stats which is set at https://github.com/opencontainers/cgroups/blob/main/fs2/memory.go#L104-L114 using the cgroup's memory.current (ref: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files).

This is exposed as container_memory_usage_bytes from cAdvisor.

container.memory.working_set

tldr: memory.current - memory.stat.active_file of cgroup

It is derived from the WorkingSetBytes of Kubelet. This comes from the WorkingSet of cAdvisor which is set at https://github.com/google/cadvisor/blob/44b8e3062d678022939d40b2a2e9b259b07ebab0/lib/container/libcontainer/handler.go#L890-L900 and is effectively the Usage - inactiveFileKeyName calculated at https://github.com/google/cadvisor/blob/44b8e3062d678022939d40b2a2e9b259b07ebab0/lib/container/libcontainer/handler.go#L890-L900. Where inactiveFileKeyName comes from cgroup memory.stat.inactive_file (ref: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files) at https://github.com/opencontainers/cgroups/blob/main/fs2/memory.go#L89-L95.

This is exposed as container_memory_working_set_bytes from cAdvisor.

This is the metric that K8s Eviction manager uses.

container.memory.available

tldr: workingSet - memory.limit_in_bytes

It is derived from the AvailableBytes of Kubelet which is set at https://github.com/kubernetes/kubernetes/blob/v1.36.0/pkg/kubelet/stats/helper.go#L75-L78. It is limit - workingSetBytes where limit is from https://github.com/google/cadvisor/blob/master/lib/model/container.go#L33 which comes from https://github.com/google/cadvisor/blob/44b8e3062d678022939d40b2a2e9b259b07ebab0/lib/container/common/helpers.go#L187 memory.limit_in_bytes of the cgroup.

In general, this metric can be derived from cadvisor and by subtracting the container_memory_working_set_bytes metric from the container_spec_memory_limit_bytes metric.

container.memory.rss

tldr: the anon from cgroup

In K8s, this metric is derived from the MemoryStats.RSSBytes field of the ContainerStats.Memory of the Kubelet's stats API.

In general, this metric can be derived from cadvisor and specifically the container_memory_rss metric.

In cgroup v2 it comes from the anon: https://github.com/google/cadvisor/blob/44b8e3062d678022939d40b2a2e9b259b07ebab0/lib/container/libcontainer/handler.go#L832

Memory metrics for containers, pods and nodes are calculated and retrieved indepenetly as also explained at #3001 (comment). Hence all should be at the same requirement level.

Key observation here is that the container.memory.* metrics have a well defined equivalent in cadvisor and hence we are good to use the container.* namespace since those are not K8s/Kubelet specific.

Based on the above I believe we are confident enough to promote these metrics to release_candidate. @dashpole @open-telemetry/semconv-k8s-approvers let me know what you think.