Add support for custom resource definition

[andyxning]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature

What happened:
As with the popular about operators, CRDs are used more and more frequently in Kubernetes. We should try to add support for collecting metrics about CRDs.

But, as CRDs are defined by different users and may vary from user to user, we may need to extract some common metrics or fields.

Maybe we should work with people from https://github.com/operator-framework as it may become the de facto sdks to develop operators.

I am not quite sure what to do for now, just propose this issue and hope to learn some suggestions from others.

[brancz]

My take: operators should expose metrics about the objects they expose themselves. There is no meaningful extension kube-state-metrics can do other than potentially providing a library to reuse the mechanisms built in this repository.

The Prometheus Operator does this today already.

[andyxning]

Background:

I am currently working on nsq operator, so i think some similar metrics about crds should also be exposed.

@brancz That is a good suggestion. Only the custom controller manager, i.e., operator can best know and learn how to expose important object metrics.

[brancz]

Only the custom controller manager, i.e., operator can best know and learn how to expose important object metrics.

Precisely.

[brancz]

Do open an issue on the operator framework as I feel it should give you a nice surface to expose metrics.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[brancz]

I think we can close this.

[anandsinghkunwar]

Don't metrics like *_created make sense?