Support proxy_server_ready_backends metric

[maqiuyujoyce]

Fixes #294
Prior art: #295

Added a new metric to track the total number of backends based on proxy strategy. To avoid circular import, I extracted out ProxyStrategy related types, functions and tests into a separate package.

I didn't overwrite the existent proxy_server_ready_backend_connections metric because of potential backwards compatibility concern brought up here: https://github.com/kubernetes-sigs/apiserver-network-proxy/pull/295/files#r872839718 Instead, I marked the problematic proxy_server_ready_backend_connections metric deprecated in the help message.

Tested locally following this example and got the following result when supporting both default and desthost backend managers:

# HELP konnectivity_network_proxy_server_ready_backend_connections Number of konnectivity agent connected to the proxy server
# TYPE konnectivity_network_proxy_server_ready_backend_connections gauge
konnectivity_network_proxy_server_ready_backend_connections 1
# HELP konnectivity_network_proxy_server_ready_backend_connections_total Total number of konnectivity agent connected to the proxy server
# TYPE konnectivity_network_proxy_server_ready_backend_connections_total gauge
konnectivity_network_proxy_server_ready_backend_connections_total{proxy_strategy="default"} 1
konnectivity_network_proxy_server_ready_backend_connections_total{proxy_strategy="destHost"} 1

Added unit tests for the new metric as well.

[k8s-ci-robot]

Hi @maqiuyujoyce. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jkh52]

/ok-to-test

Did you consider using ProxyStrategy in the new metric? It would be nice to keep *Manager and *Storage types as implementation details. The proxy server already exposes --proxy-strategies to the cluster admin.

[cheftako]

Labels can generate cardinality issues. I don't think this is likely to be a problem but we can reassure/protect ourselves by changing managerName from a string (unbounded cardinality) to an enumeration with an observation on limiting the number of options.

[maqiuyujoyce]

Done.

Based on @jkh52 's suggestion above, I used proxy strategy enum as the label. (Thank you @jkh52 !)
It introduced the circular dependency, so I extracted out ProxyStrategy related types and functions into a separate package, and many files were updated. I can split it out into a separate PR if you prefer!

[jkh52]

I think there will remain a bug in ready_backend_connections (it gets clobbered when the server has more than one strategy). We could mark it deprecated (pkg/agent metrics has a help text example of this) if we think that will never get fixed.

[maqiuyujoyce]

I think there will remain a bug in ready_backend_connections (it gets clobbered when the server has more than one strategy). We could mark it deprecated (pkg/agent metrics has a help text example of this) if we think that will never get fixed.

Done.

[maqiuyujoyce]

@jkh52 Also moved the tests into this PR according to your suggestion. Please take a look!

[jkh52]

Final concern: the _total suffix here seems to contradict prometheus naming conventions (it implies a counter metric, not gauge).

Maybe just "ready_backends" or similar?

[maqiuyujoyce]

Done.

[jkh52]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jkh52, maqiuyujoyce

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jkh52]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment