Kube-state-metrics: pod collector should surface all request and limit resources

[derekwaynecarr]

The pod collector exposes a named metric for each standard resource.

The pod collector should support the ability to expose metrics for all request and limits on a pod/container including extended resources. This is important for handling resources that are introduced via device plugins.

@brancz - this was a topic that came up in resource mgmt f2f discussion. we want to engage with sig-instrumentation to find the right approach.

[brancz]

If I understand correctly, you're looking for a generic metric a la kube_pod_container_resource_requests (and limits) that specifies the resource type as a label and the value as the metric. Generally that seems like a good idea, but would be a breaking change, so I would suggest that we have a couple of versions supporting each way. We may even want to put it behind a flag as if both sets of metrics are created that may be a significant increase in total metrics ingested through kube-state-metrics.

[andyxning]

@derekwaynecarr Vote for the generic resource as it seems device plugin will come to GA in the next release.

suggest that we have a couple of versions supporting each way. We may even want to put it behind a flag as if both sets of metrics are created that may be a significant increase in total metrics ingested through kube-state-metrics.

Agreed. a few co-existence kube-state-metrics release is needed.

[brancz]

We should get deprecation going for the existing metrics and implement the new generic one.

As the change can introduce a significant amount of metrics per scrape in a large cluster I would suggest to introduce a new flag “disable-deprecated-metrics” for those who know what they’re doing and skip directly to removing deprecated metrics targeted for removal.

[andyxning]

Will work on this in the next week. :)