Seperate events and leader-election qps from kube-api-qps

[vie-serendipity]

Please provide an in-depth description of the question you have:

I understand semantically that all types of clients should use a single ratelimiter with an input parameter for the total QPS. #6095
However, in reality, for example, in the case of a scheduler, events and scheduling should not share a single ratelimiter, just like in the k8s community, where various types of clients have their own rate limiters, especially for events and leader election.

What do you think about this question?:

I prefer to modify the semantic of kube-api-qps to indicate that it doesn't include API calls for leader elections, events, and the like. For events, we could introduce an 'event-qps' parameter, similar to kubelet, to regulate them.

Environment:

• Karmada version:
• Kubernetes version:
• Others:

[zhzhuang-zju]

You'd like to categorize the component's API server access types, with each category having its own rate limiters—is that correct? Have you encountered any specific issues related to this so far?

Just like in the Kubernetes community, where different types of clients have their own rate limiters, especially for events and leader election.

Could you share documentation or relevant code links? I’d like to learn how upstream Kubernetes handles rate limiters, thanks

[RainbowMango]

cc @zach593

[vie-serendipity]

You'd like to categorize the component's API server access types, with each category having its own rate limiters—is that correct? Have you encountered any specific issues related to this so far?

No specific problem. I just think events, carrying additional information, should not share a rate limiter with the scheduling.

Could you share documentation or relevant code links? I’d like to learn how upstream Kubernetes handles rate limiters, thanks

https://github.com/kubernetes/kubernetes/blob/15673d04e30c711a7bb0f0efe6abf4baead1463b/cmd/kube-scheduler/app/options/options.go#L381-L409