Skip to content

[Autoscaler] Refactor metrics client#83

Merged
TomerShor merged 8 commits intov3io:developmentfrom
weilerN:NUC-709-refactor_metrics_client_in_autoscaler
Jan 8, 2026
Merged

[Autoscaler] Refactor metrics client#83
TomerShor merged 8 commits intov3io:developmentfrom
weilerN:NUC-709-refactor_metrics_client_in_autoscaler

Conversation

@weilerN
Copy link
Collaborator

@weilerN weilerN commented Jan 6, 2026

📝 Description

This change refactors autoscaler metrics handling by introducing a dedicated MetricsClient abstraction and factory. The autoscaler no longer depends directly on Kubernetes custom metrics APIs and instead consumes metrics via a pluggable client interface.


🛠️ Changes Made

  • Introduced MetricsClient interface in scalertypes to abstract resource metrics retrieval.
  • Added MetricsClientOptions to autoscaler configuration to control metrics client configuration and selection.
  • Implemented CustomMetricsClient under pkg/autoscaler/metricsclient, encapsulating Kubernetes custom metrics logic.
  • Added a metrics client factory under pkg/autoscaler/metricsclient to construct the appropriate client based on configuration.
  • Refactored autoscaler to consume the MetricsClient interface instead of directly using Kubernetes custom metrics APIs.

✅ Checklist

  • I have tested the changes in this PR

🧪 Testing

  • Dev tests- deployed the nuclio-scaler and tested STZ
    • Tested STZ on a function that created with the new scaler
    • Backward compatibility test: Created a function, then replaced the scaler and validated that STZ works as expected.

🔗 References


🚨 Breaking Changes?

  • Yes (explain below)
  • No

🔍️ Additional Notes

@weilerN weilerN force-pushed the NUC-709-refactor_metrics_client_in_autoscaler branch 3 times, most recently from 779eb29 to 521e536 Compare January 7, 2026 15:40
@weilerN weilerN force-pushed the NUC-709-refactor_metrics_client_in_autoscaler branch from d1ed7fe to 44b998c Compare January 7, 2026 15:44
@weilerN weilerN requested review from TomerShor and rokatyy January 7, 2026 16:27
@weilerN weilerN marked this pull request as ready for review January 7, 2026 16:27
Copy link
Collaborator

@rokatyy rokatyy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very well! Just a couple of suggestions and questions

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I like the name, how about just custom? Because this are not metrics, the struct is for a client (a custom one), so either custom.go or customclient.go

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it can also just be k8s.go, and the client name K8sCustomMetricsClient

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that the naming here can be improved. fixing

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 36 to 41
type CustomMetricsClient struct {
k8scustommetrics.CustomMetricsClient
namespace string
groupKind schema.GroupKind
logger logger.Logger
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume some of those values are expected to be common across all the interface implementations? Do we want to have an abstract class or it would be redundant?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rokatyy Great question!
At the moment, the only shared values across implementations are the namespace and the logger, so I prefer to keep the current structure as is.

That said, if we start seeing duplicated state or logic (during the Prometheus client implementation), I’ll definitely consider introducing a common abstract struct to avoid repetition.

autoScalerConf.Namespace,
autoScalerConf.GroupKind), nil
default:
return nil, fmt.Errorf("unsupported metrics client kind: %s", autoScalerConf.MetricsClientOptions.Kind)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use errors instead of fmt

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"k8s.io/client-go/kubernetes"
)

type Kind string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind is too generic, let's change to MetricsClientKind or something more informative

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomerShor TomerShor changed the title Nuc 709 refactor metrics client in autoscaler [Autoscaler] Refactor metrics client Jan 8, 2026
Group: metricsResourceGroup,
},
MetricsClientOptions: scalertypes.MetricsClientOptions{
Kind: scalertypes.KindCustomMetrics,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we not getting this as an input instead of hardcoding it to custom metrics?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed F2F, comments will be added to improve readiness

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it can also just be k8s.go, and the client name K8sCustomMetricsClient

namespace string,
groupKind schema.GroupKind) *CustomMetricsClient {
return &CustomMetricsClient{
logger: logger,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
logger: logger,
logger: parentLogger.GetChild("custom-metrics"),

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weilerN weilerN requested review from TomerShor and rokatyy January 8, 2026 13:16
Comment on lines 39 to 51
case scalertypes.KindK8sMetricsClient:
discoveryClient, err := discovery.NewDiscoveryClientForConfig(restConfig)
if err != nil {
return nil, errors.Wrap(err, "Failed to create k8s metrics client")
}
availableAPIsGetter := k8scustommetrics.NewAvailableAPIsGetter(discoveryClient)
restMapper := restmapper.NewDeferredDiscoveryRESTMapper(memory.NewMemCacheClient(discoveryClient))
customMetricsClient := k8scustommetrics.NewForConfig(restConfig, restMapper, availableAPIsGetter)
return NewCustomMetricsClient(
logger,
customMetricsClient,
autoScalerConf.Namespace,
autoScalerConf.GroupKind), nil
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, Move all of this into NewCustomMetricsClient.
The factory needs to be simple - call the constructor, return the instance.
The constructor tells what it needs the factory to pass as arguments, and it defines any intermediate types etc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weilerN weilerN requested a review from TomerShor January 8, 2026 14:28
Copy link
Collaborator

@rokatyy rokatyy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@TomerShor TomerShor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job 👍🏼

@TomerShor TomerShor merged commit 72bd925 into v3io:development Jan 8, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants