Enhancement: Support partial GVK filtering in Metric and FederatedMetric targets

[HannesDyballa]

What would you like to be added

The spec.target field for Metric and FederatedMetric should be enhanced to interpret partial GVK specifications as filters. The handler should discover all matching resources based on the provided fields.

The desired filtering behaviour should be as follows:

• If only group is set: Monitor all resources across all versions and kinds within that API group.
• If only version is set: Monitor all resources across all groups and kinds that exist in that version.
• If only kind is set: Monitor all resources with that kind, regardless of their group or version.
• Any combination (e.g., group and version): Monitor all resources that match the specified combination.

Why is this needed

The spec.target fields for Metric and FederatedMetric (group, version, and kind) are defined as optional in the API schema. This implies that users should be able to omit any of these fields, and the controller should handle it gracefully by treating them as filters.
However, the current implementation requires a full Group-Version-Kind (GVK) to be specified. If any part of the GVK is omitted, the metric controller either fails to reconcile or returns an incorrect value.

For example, it is not possible to create a single Metric that counts all resources within a specific API group (e.g., account.btp.sap.crossplane.io or toolkit.fluxcd.io).

The ManagedMetric resource already supports this filtering behaviour.

Analysis of Current Behaviour

I tested the current behaviour of Metric with various partial GVK combinations. The results show that the current implementation cannot handle these cases correctly.

The group a.b.c is a placeholder for account.btp.sap.crossplane.io and MyKind for Subaccount from the original test data.

Target Configuration	Result
Full GVK (Working Baseline) target: group: "a.b.c" version: "v1alpha1" kind: "MyKind"	✅ Success: Correctly records a value of 1, as only one resource existed.
Group Only target: group: "a.b.c"	❌ Error: failed to retrieve target resource(s): converting (v1.APIGroup) to (v1.APIResourceList): unknown conversion
Version Only target: version: "v1alpha1"	❌ Error: failed to retrieve target resource(s): the server could not find the requested resource
Kind Only target: kind: "MyKind"	❌ Error: failed to retrieve target resource(s): groupVersion shouldn't be empty
Group and Kind target: group: "a.b.c" kind: "MyKind"	❌ Error: failed to retrieve target resource(s): converting (v1.APIGroup) to (v1.APIResourceList): unknown conversion
Group and Version target: group: "a.b.c" version: "v1alpha1"	⚠️ Silent Failure: Reconciles successfully but records a value of 0, even when matching resources exist.
Version and Kind target: version: "v1alpha1" kind: "MyKind"	❌ Error: failed to retrieve target resource(s): the server could not find the requested resource

[reshnm]

This can be done with the discovery client and discoveryCli.ServerGroupsAndResources().
However this can be very expensive as all resources/versions/groups have to be listed individually which can lead to dozens and dozens of calls to the API server.

This is also why kubectl get managed can be very slow because it has to query each api resource and check if it has managed in its categories.

Doing this cyclically may has a serious impact on metrics-operator and and API server performance.

[HannesDyballa]

Thank you for your insight. 😁
Do you think caching could be an option?

And couldn't we use discoveryCli.ServerGroups() to get all the groups and version, filter based on the returned group and version and only use valid groupVersion to do the lookup via discoveryCliServerResourcesForGroupVersion(groupVersion string) like we are doing now?

I think this pre-filtering would be a lot better than listing all resources/versions/groups. Do you think this smaller pre-filtering layer also has such a dramatic impact on performance?

[reshnm]

Do you think caching could be an option?

Could be. But you know, caching is hard ;-)
First I would try to find out if there is already caching in place with the library.

I would avoid retrieving the groups for each metric individually, but rather have some global mechanism.
Unfortunately I currently don't have much time looking into it.

[HannesDyballa]

There seem to be a caching options for in memory and on disk:
https://github.com/kubernetes/client-go/tree/master/discovery/cached

I just took a quick peek and noticed that the reference to the cluster does not get added to the cached entry.
So we would need one instance per cluster.
This is especially important for federatedMetric/federatedManagedMetric.
I think we can implement the retrieval of the right instance with a global component.
What do you think?

[reshnm]

We are happy for contributions. If you have any concrete ideas please go ahead. We will be available for review.