kube_endpoint_address_available and kube_endpoint_address_not_ready get computed by kube-state-metrics

[bavarianbidi]

What would you like to be added:

kube_endpoint_address_available and kube_endpoint_address_not_ready should be marked as deprecated and replaced in the future by an other metric which only export these information and calculation could be done afterwards.

Why is this needed:

Yes, kube-state-metrics shouldn't be responsible for the computation. As an exporter, its only goal is to expose kubernetes objects data as metrics. Any computation such as getting the total number of ports should be done in promQL.

xref: #1571 (comment)

Describe the solution you'd like

• kube_endpoint_address_available and kube_endpoint_address_not_ready should be marked as deprecated
• new metrics is implemented
• kube_endpoint_address_available and kube_endpoint_address_not_ready will be removed

Additional context

Similar implementation got rejected in #1571 and was reimplemented to do the computation via promQL later on.

[bavarianbidi]

#1549 is also doing some changes on this topic

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[bavarianbidi]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[bavarianbidi]

/remove-lifecycle stale

[bavarianbidi]

@dgrisonnet if #1761 got merged, what's the process to mark kube_endpoint_address_available and kube_endpoint_address_not_ready as deprecated?

[bavarianbidi]

@dgrisonnet if #1761 got merged, what's the process to mark kube_endpoint_address_available and kube_endpoint_address_not_ready as deprecated?

• @fpetkovski ☝️

[dgrisonnet]

@bavarianbidi in the FamilyGenerator struct there is a DeprecatedVersion field that you can fill: https://github.com/kubernetes/kube-state-metrics/blob/master/pkg/metric_generator/generator.go#L35
It will add the version at which the metric was deprecated to the HELP text of the metric. Then we should wait for at least two minor releases before removing it completely.

[mangkoran]

Apologize for the necrobump. The new kube_endpoint_address would have cardinality of all IPs in the endpoint subset. This seems to be a major cost compromise if we have service with a lot of endpoints and only want to have the number of available addresses and readiness of these addresses. Whereas kube_endpoint_address_available and kube_endpoint_address_not_ready should always have one series per endpoint. In our case we would like to check for service readiness and kube_endpoint_address_available and kube_endpoint_address_not_readyseems the better option to keep our cost down.

[receperdogan]

Apologize for the necrobump. The new kube_endpoint_address would have cardinality of all IPs in the endpoint subset. This seems to be a major cost compromise if we have service with a lot of endpoints and only want to have the number of available addresses and readiness of these addresses. Whereas kube_endpoint_address_available and kube_endpoint_address_not_ready should always have one series per endpoint. In our case we would like to check for service readiness and kube_endpoint_address_available and kube_endpoint_address_not_readyseems the better option to keep our cost down.

I agree with @mangkoran. for this reason, we downgraded the version.