feat(persistentvolume): claimRef info to labels

[Duologic]

What this PR does / why we need it:

Adds a new metrics to provide claimRef information to Prometheus. In
tracking down lingering PVs, it would be of interest to know where the
PV came from. With the claimRef information, it is easier to track down
the resource owners and inform that they have unclaimed PVs lingering
around.

Main motivation is that PVs cost money at cloud providers, if PVs stick
around for long, the costs might increase significantly.

[k8s-ci-robot]

Welcome @Duologic!

It looks like this is your first PR to kubernetes/kube-state-metrics 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kube-state-metrics has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[Duologic]

I'm a bit unsure what to do best if there is no spec.claimRef. Feel free to put in some suggestions.

[lilic]

Thanks for your PR, couple of comments and you need to also generate the docs, hence the failing tets.

[lilic]

Can you explain the usecase for the apiserver value?

[lilic]

Can this be anything else but PVC?

[Duologic]

I didn't want to make an assumption here, the same reason I kept the apiversion around. I have no hard arguments to keep it around.

[brancz]

Can claimref change over the lifetime of a PV? If not then this would be a better fit for the general info metric I would say.

[Duologic]

Considering a PV can exist without a PVC, a PV could be unclaimed and thus without a claimref, the claimref is added/updated by a process that binds a PV to a PVC. I do think that once the PV has a claimref, it is very unlikely that the name/namespace will change, but technically it could as it is part of the 'binding' process.

I'm up for adding it to the info metric, but I don't know what impact that change might have, feel free to tell me where to put it as I lack the confidence to make a decision. 😊

Upon reading a bit in random github issues to see how relevant the apiversion/kind is, they seem unlikely to contain anything else than v1/PVC, I think we can drop those labels because of that.

[lilic]

Upon reading a bit in random github issues to see how relevant the apiversion/kind is, they seem unlikely to contain anything else than v1/PVC, I think we can drop those labels because of that.

Yep my thinking exactly. 👍

[brancz]

Taking all this information into consideration, I would say: let's drop the kind/apiversion, and have this be a separate metric and not part of the info metric since there is a chance this may change over the lifetime of the PV.

[Duologic]

That should do it, shall I squash it or do we do that on merge?

[brancz]

Small nit on naming, then should be good to go.

[brancz]

Let's squash the changes I'd say.

[Duologic]

Addressed comments, squashed and rebased on current master.

[lilic]

/lgtm

Thanks for the contribution!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Duologic, lilic

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lilic]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment