Kube-state-metrics: StafeulSet metrics?

[nvartolomei]

Is anyone working on these?

[brancz]

Definitely interesting! I am not aware of anyone working on this currently. A few caveats if you were to get started:

• It will require an upgrade of the vendored k8s.io/client-go library, which is pretty painless, but necessary. I was thinking of doing this some time soon, but if someone wants to take a go at it go ahead. (I probably won't get started before the holidays)
• It will need to be done in a backward compatible way, as we currently have compatibility down to 1.2 and it would be nice if we can keep that. What that would mean is that collection for StatefulSets is turned off if the cluster version is lower than 1.5.0.

[brancz]

While I'm still not aware that someone is working on this, the things I mentioned before don't apply anymore. The k8s.io/client-go dependency has been updated and backward-compatibility is not an issue anymore as those collectors can now be disabled when necessary.

[nvartolomei]

This is blocked by https://github.com/kubernetes/client-go/issues/183

[nvartolomei]

@brancz looks like there is no easy way to support multiple kubernetes versions using a single client.

https://github.com/kubernetes/client-go/issues/183

[brancz]

I guess then we people will just have to disable the collector and that way we can provide backward compatibility on a best effort basis, but not for multiple versions of the same object. At least there is some light at the horizon, but it doesn't sound like we can wait for that.

[nvartolomei]

@brancz what light? Looks like there is only one proper solution, to have different kube-state-metrics releases to match kubernetes (api) versions.

There will be conflicts each time apis graduate or deprecated and deleted (from client-go too).

[brancz]

He mentioned that they're planning to release generators to generate the clients for deprecated APIs .. that's basically what https://github.com/ericchiang/k8s already does, however it is currently lacking the informer functionality that we heavily rely on.

That said, what I meant is that we can't wait for the generators to be released, and for now we'll have to move forward with what we have, which means whatever is the latest version of each resource. And if that causes problems for individual users, they'll have to turn off that collector via the available flags.

[devth]

Is this still blocked?

[brancz]

We should do what we can get out of a 1.6 cluster, so aside from having to update client go this should be possible to be worked on.

[blakebarnett]

Hoping https://github.com/kubernetes/kube-state-metrics/pull/151 goes in and 0.6 gets released soon! Would love to have jobs/cronjob and statefulset metrics.

[stijndehaes]

@blakebarnett I was just about to mention my PR on this issue. I am also waiting for StatefulSet metrics. So I am hoping that someone reviews my PR as soon as possible

[brancz]

I reviewed and merged #151, there is one more thing I would like to get into the next release, which is selecting which namespaces to gather the objects from. I don't think I'll get to implementing that before next week, but after that I'll do another release. It's coming! :slightly_smiling_face:

[brancz]

Closing here as #151 is merged.

[devth]

Shouldn't statefulset metrics have available_replicas, the same as deployments? It's not as useful to know the intended number of replicas in prom_kube_statefulset_replicas as it would be to know whether those replicas are actually up.

[stijndehaes]

You have kube_statefulset_status_replicas and kube_statefulset_replicas.
The first one is the available replicas and the second one is the intended replicas. Statefulsets work a bit differently under the hood that's why the naming is not exactly the same as with deployments

[brancz]

The metric names are typically determined by the fields in the Kubernetes API objects.