`kube_persistentvolume_*` and `kube_persistentvolumeclaim_*` should expose the volume name under the same label

[multani]

What would you like to be added:

kube_persistentvolume_* metrics and kube_persistentvolumeclaim_* metrics should expose the "name of the volume" inside the same metric label.

Why is this needed:

It's a bit difficult at the moment to combine the Persistent Volume and Persistent Volume Claim metrics together to get, for instance, the "size" of the PVC in a specific namespace:

• kube_persistentvolume_* metrics have a persistentvolume label containing the name of the underlying persistent volume.
• kube_persistentvolumeclaim_* on the other hand, expose the name of the persistent volume in the volumename label

It's then difficult to combine both metrics together, and bring the PVC labels into the PV metric (or vice-versa) (see https://github.com/prometheus/prometheus/issues/2204)

Describe the solution you'd like

Rename one of the two label to have the same label as the other metric.

Additional context

I was trying to get the "size" of the PVCs with a query like this, but it doesn't work because it's not possible to join on different labels:

avg(kube_persistentvolume_capacity_bytes) by (persistentvolume)
* on (volumename) group_left (namespace, persistentvolumeclaim)
avg(kube_persistentvolumeclaim_info) by (namespace, persistentvolumeclaim, volumename)

[dashpole]

/assign @CatherineF-dev /traige accepted

[multani]

/traige accepted

@dashpole there's a typo here ;)

Also, I'm happy to help on this feature, if needed :+1:

[dashpole]

/triage accepted

[CatherineF-dev]

You can rename a metric label, as long as this metric is not marked as STABLE.

# HELP kube_persistentvolume_status_phase [STABLE] The phase indicates if a volume is available, bound to a claim,…
46

# HELP kube_persistentvolumeclaim_created Unix creation timestamp

Free feel to open a PR @multani, I can help review

[multani]

I created https://github.com/kubernetes/kube-state-metrics/pull/2303 to fix the issue.

Looking at the code base, it seems the volumeattachment-related metrics may have the same issue.