Support new `daemonset.updated` metric name from kube-state-metrics

[rewolf]

What does this PR do?

Adds a new metric mapping to daemonset.updated from the kube-state-metrics kube_daemonset_status_updated_number_scheduled metric (previously called kube_daemonset_updated_number_scheduled).

Motivation

In https://github.com/kubernetes/kube-state-metrics/commit/8031a708543563583990abfead7559bc29cc5b0c, the metric name was changed from kube_daemonset_updated_number_scheduled to kube_daemonset_status_updated_number_scheduled to be consistent with other metric names. This PR adds the new mapping and leaves the old mapping for backward compatibility.

Additional Notes

n/a

Review checklist (to be filled by reviewers)

• [ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• [ ] PR title must be written as a CHANGELOG entry (see why)
• [ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• [ ] PR must have changelog/ and integration/ labels attached

[rewolf]

I was not able to add a changelog label to the PR.

[codecov[bot]]

Codecov Report

Merging #12103 (a730833) into master (c943a73) will not change coverage. Report is 3330 commits behind head on master. The diff coverage is 100.00%.

Additional details and impacted files

Flag	Coverage Δ
kubernetes_state	89.35% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[clamoriniere]

hi @rewolf

The metrics was renamed in kube-state-metrics version >= 2. So the Datadog check that support v2 is kubernetes_state_core. Because the python check that you have modified only support kube-state-metrics <= 1.9.x. More information about the reason we have build this new check here: https://www.datadoghq.com/blog/kube-state-metrics-v2-monitoring-datadog/

Also the metric change is already done in the kuberneres_state_core check: https://github.com/DataDog/datadog-agent/pull/11369

I would suggest you to migrate to the kubernetes_state_core check: https://docs.datadoghq.com/integrations/kubernetes_state_core/

[rewolf]

Also the metric change is already done in the kuberneres_state_core check: https://github.com/DataDog/datadog-agent/pull/11369

Must have missed that when searching for references!

Thanks for the explanation @clamoriniere. Looks like we'll have to look at migrating to kubernetes_state_core sooner rather than later, although it's going to take us a while to assess the affected scope.

I understand your suggestion and viewpoint, but if this is only one of a few breaking changes between ksm v1 and v2, it'd be great to get support for the new metric backported to this kubernetes_state check with a merge of this PR and give us time to properly prepare for migration to kubernetes_state_core.

[clamoriniere]

Hi @rewolf

I understand your suggestion and viewpoint, but if this is only one of a few breaking changes between ksm v1 and v2, it'd be great to get support for the new metric backported to this kubernetes_state check with a merge of this PR and give us time to properly prepare for migration to kubernetes_state_core.

As I explained this metric renaming (kube_daemonset_updated_number_scheduled to kube_daemonset_status_updated_number_scheduled) was introduced in kube-state-metrics v2. But the Datadog kubernetes_state check only support scrapping kube-state-metrics <= 1.9.x. So this metric renaming doesnt applied to the kubernetes_state check.

The migration from kubernetes_state to kubernetes_state_core is not fully transparent, but it is worth doing it if you are using a recent Kubernetes version. It provided new useful metrics with much better performances.

If it is ok with you, I think we can close this PR.

[clamoriniere]

hi @rewolf, I'm closing this PR, feel free to reopen it if you want react on my previous comment