[umbrella] Karmada federated HPA implementation

karmada-io / karmada

Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration

https://karmada.io

Apache License 2.0

4.48k stars 888 forks source link

[umbrella] Karmada federated HPA implementation #2378

Closed Poor12 closed 2 years ago

Poor12 commented 2 years ago

What would you like to be added: We are going to implememt federated HPA according to proposal.

I'd like to list all the iterated tasks here, anyone wants to join or help on it, please feel free to leave your comment on it.

Why is this needed:

[ ] implement FederatedHPA controller to distribute HPA resource to member clusters.
[ ] state collection and reset the scale sub-resource of the resource template.
[ ] introduce a label for migrate from existing HPA resources.
[ ] HPA resource template status aggregate.
[ ] user guide for federated HPA.
[ ] UT/e2e test for federated HPA.

chaunceyjiang commented 2 years ago

Hi, can I pick some tasks?

RainbowMango commented 2 years ago

Sure, but frankly speaking, I'm not so confident with this solution, I'm not sure if it really works as expected. @snowplayfire and @riverzhang might have implemented it in their private products, and I haven't got feedback about that. Also, I'm looking forward to seeing a demo for it.

chaunceyjiang commented 2 years ago

Hi, @YueHonghui @RainbowMango I found that the existing hpa proposal also strongly depend on the stability and performance of the control plane.

According to the description in the proposal, we use the resource interpreter webhook to retain the replicas of the workload of the member cluster, which means that whenever the replicas of the workload of the member cluster change, the control plane needs to send an http request to the webhook to determin is it necessary to retain the replicas.

From the description of the webhook proposal, the webhook cannot only take effect on a certain workload in the workload, that is, regardless of whether a workload has HPA enabled, the control plane will request the webhook again.

YueHonghui commented 2 years ago

The critical path(autoscaling) of the HPA in the member cluster doesn't depend on the stability of the control plane. Suppose that the webhook or karmada is down, the retain process will fail, but the replicas of workload in the member cluster won't be overwritten by karmada at the same time. That is, the replicas of the workload in the member cluster will be retained if the webhook works properly, or the replicas of the workload in the member cluster will not be edited by the karmada control plane if the webhook or karmada is down. Both are what we want.

chaunceyjiang commented 2 years ago

Yes, I know, my proposal can also guarantee this.

If webhook is used, will the control plane frequently send http requests to the webhook server?

YueHonghui commented 2 years ago

@chaunceyjiang

Yes, I know, my https://github.com/karmada-io/karmada/pull/2484 can also guarantee this. What if only Fed-HPAController is down?

I think this issue is not the right place to discuss these two proposals. In my opinion, the main difference between these two proposals is how to solve the overwritten replicas. So I suggest creating a PR for the existing federatedhpa proposal. Then, we can discuss it there.

chaunceyjiang commented 2 years ago

So I suggest creating a PR for the existing federatedhpa proposal. Then, we can discuss it there.

ok.

Poor12 commented 2 years ago

This issue is task decomposition based on existing proposals. Since the plan still needs to be discussed in detail, I'll close it.