Centralized HPA architecture

[jwcesign]

What would you like to be added:

Decentralized HPA:

The concept of Decentralized HPA can be complex to comprehend and configure, leading to confusion among users. Additionally, it may result in duplicate jobs with the scheduler.
But it does have one advantage, though: if the control plane goes down, it can still handle burst requests.

Centralized HPA

Centralized HPA is quite easy to understand and configure, there are three kinds of architecture:
K8s native metrics server(CPU/Memory):

Customer metrics server:

By implementing this architecture, the HPA will solely focus on scaling deployments while the scheduler schedules replicas based on priority policies.
However, a drawback of this approach is that in case of control plane failure, it cannot manage sudden surge requests.

Why is this needed:
In the current era of single clusters, Horizontal Pod Autoscaling (HPA) is commonly used to dynamically scale workload replicas to handle incoming requests and enhance resource utilization. Therefore, in the era of multi-clusters, HPA should still work and be capable of scaling the workloads in different member clusters, to resolve resource limitations for a single cluster and improve scaling fail recovery capabilities.

[jwcesign]

cc @Garrybest @XiShanYongYe-Chang @chaunceyjiang what do you think?

[chenwei01]

By the way，Will the new version adopt a centralized architecture ? When is the next version scheduled to be released？

[jwcesign]

Hi @chenwei01 ,
There are two types of architecture: centralized and decentralized, each with its own advantages. Users can choose the type they prefer.

The decentralized HPA has a higher priority.

BTW, what's your use case? @chenwei01

[chenwei01]

@jwcesign got it, thanks, my scenario basically matches the use cases in the proposal.

[jwcesign]

This feature is finished, let's close this issue