Add metrics for logical clusters count

[cnvergence]

Summary

Introduce kcp_logicalcluster_count metric, that will hold the value of currently running logical clusters in the shard.

What Type of PR Is This?

/kind feature

Related Issue(s)

Fixes #3479

Release Notes

Add metrics for logical clusters count

[kcp-ci-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[mjudeikis]

Can we add metrics for all states:

const (
	LogicalClusterPhaseScheduling   LogicalClusterPhaseType = "Scheduling"
	LogicalClusterPhaseInitializing LogicalClusterPhaseType = "Initializing"
	LogicalClusterPhaseReady        LogicalClusterPhaseType = "Ready"
	// LogicalClusterPhaseUnavailable phase is used to indicate that the logical cluster is unavailable to be used.
	// It will not be served via front-proxy when in this state.
	// Possible state transitions are from Ready to Unavailable and from Unavailable to Ready.
	// This should be used when we really can't serve the logical cluster content and not some
	// temporary flakes, like readiness probe failing.
	LogicalClusterPhaseUnavailable LogicalClusterPhaseType = "Unavailable"
)

Basically if I have bug where my logicalcluster hangs in failed or initializing state - I want to know

[cnvergence]

valid point, generic count can be helpful in this situation, let's keep it simpler as well

[embik]

This doesn't look implemented @cnvergence or am I missing something?

[cnvergence]

I dropped the Readiness check - we just fetch the count of all logical clusters.
Or do we want to add a logical cluster count metric for ready and other separately? 🙂

[embik]

I think that was the idea. So it would be a phase label on the metric:

kcp_logicalcluster_count{phase="Ready"} 5
kcp_logicalcluster_count{phase="Scheduling"} 3
kcp_logicalcluster_count{phase="Unavailable"} 0

[cnvergence]

I will consider adding the phase label and processing it during updates. Possibly, we can also split the metrics.
This will align with how, for example, kube-state-metrics processes the count of the pods

[embik]

/kind feature

[embik]

This doesn't look implemented @cnvergence or am I missing something?

[mjudeikis]

/lgtm
/approve

[kcp-ci-bot]

LGTM label has been added.

Git tree hash: f8834b926c94a3030f3347a5a60926207023dfb8

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mjudeikis

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 [mjudeikis]

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

[cnvergence]

/retest

[cnvergence]

/retest

[ntnn]

/retest

integration flake, it's been getting worse =/

[kcp-ci-bot]

LGTM label has been added.

Git tree hash: a4fb857ee54430d476313708e0f3142af893c4d7

[cnvergence]

/retest