Add metrics about Vertical Pod Autoscaler recommendations

[jessie-JNing]

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind feature

What happened:
Vertical Pod Autoscaler is release in Kubernetes, which aims to provides recommendations to set appropriate resource request values for Kubernetes pods.

A number of recommended CPU/memory values are given by VPA, e.g.

containerRecommendations:
  - containerName: web
    lowerBound:
      cpu: 10m
      memory: "272054411"
    target:
      cpu: 11m
      memory: "87381333"
    uncappedTarget:
      cpu: 11m
      memory: "442809964"
    upperBound:
      cpu: 11m
      memory: "482354586"

What you expected to happen:
We would like to have the values(lowerBound, target and etc.) be collected by kube-state-metrics.

So that we can compare the actual CPU/memory cost with the recommended values via DataDog or other monitoring tools.

[tariq1890]

/kind feature

[brancz]

I think the VPA should expose these metrics itself. It's the same take as we have on operators, etc.

[jessie-JNing]

I think the VPA should expose these metrics itself. It's the same take as we have on operators, etc.

Could you provide a guide/doc on that? Thanks @brancz

[brancz]

I don't have docs but I can give two examples:

• the prometheus-operator creates its own prometheus registry and metrics collector and creates metrics about Prometheus objects that way:

  • Registration: https://github.com/coreos/prometheus-operator/blob/82094eff1c5465dd741e8a4880ca8f5bc1513e25/pkg/prometheus/operator.go#L321
  • Collector code: https://github.com/coreos/prometheus-operator/blob/master/pkg/prometheus/collector.go

• Operator SDK uses kube-state-metrics as a library to expose metrics about objects: pkg/kube-metrics: Add initial operator specific metrics operator-framework/operator-sdk#1277

[dturn]

It turns out @bskiba actually suggested adding the metrics in this project kubernetes/autoscaler#1631 (comment). Can the two of you offer a path forward? We could build our own scraping mechanism, but that doesn't seem like the right path forward ...

[brancz]

hmm.. maybe VPA is in kind of a unique situation, as it's part of core kubernetes (as in the kubernetes org), but not installed on every cluster. If we mark all metrics of the VPA as experimental, and have it be turned off by default, then I think I would be ok with having it in kube-state-metrics (and only support >=v0.5.0).

[milesbxf]

We're quite keen to have this too, so I'd be happy to have a go at adding it this week. @dturn have you started looking at this at all?

[dturn]

We're quite keen to have this too, so I'd be happy to have a go at adding it this week. @dturn have you started looking at this at all?

I haven't had a chance to work on this, and probably wont this week either. It would be great if you had time to work on this @milesbxf !

[milesbxf]

@dturn no worries - just wanted to avoid duplicating work. I've had an initial go at this here: #791