search

karmada-io / karmada

Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration
https://karmada.io
Apache License 2.0
4.43k stars 877 forks source link

Manage Multiple scheduling group individually #3383

Open wlp1153468871 opened 1 year ago

wlp1153468871 commented 1 year ago

What would you like to be added: I hope that the Multiple scheduling group can be managed separately,making it easier for users to use.

Why is this needed: Firstly, supporting multiple scheduling group is a fantastic design that has been very helpful for us.

Additionally, I have two small suggestions:

  1. since our cluster grouping and deployment changes are not too frequent, each scheduling group rule should be configured in a stable manner within each deployment strategy to reduce the risk of errors caused by repetitive configuration without any means to detect differences.
  2. all scheduling group resources are dispersed, which makes it cumbersome to modify multiple deployment strategies when we want to make changes to a scheduling group rule.

User Stories： As a user, I hope that the Multiple scheduling group can be managed separately to reduce the user threshold. For example, private/managed clusters or primary/backup clusters are fixed in real usage scenarios. We recommend that you manage cluster groups separately. Set a fixed cluster as a group and give it a name. When you select a cluster group for application deployment, you can directly select the name of the group. If you need to modify the clusters in this group due to changes in the business scenario, you only need to modify the cluster once in the separately managed part, and then it can be applied to all applications.

I hope to do this part of optimization. If there is no problem, I will create a proposal.

micosjanf commented 1 year ago

Great suggestion, thank you for your feedback.

XiShanYongYe-Chang commented 1 year ago

Thanks for your user stories! I think you're talking about adding a resource to represent the cluster collection, am I right? This behavior may trigger more discussion. /cc @RainbowMango

RainbowMango commented 1 year ago

Firstly, supporting multiple scheduling group is a fantastic design that has been very helpful for us.

Thanks for your feedback.

I guess what you are asking is a new API, like ClusterSet which represents a group of clusters, then you can refer to the ClusterSet in PropagationPolicy for declaring clusterAffinity or clusterAffinities. Am I right?

wlp1153468871 commented 1 year ago

Firstly, supporting multiple scheduling group is a fantastic design that has been very helpful for us.

Thanks for your feedback.

I guess what you are asking is a new API, like ClusterSet which represents a group of clusters, then you can refer to the ClusterSet in PropagationPolicy for declaring clusterAffinity or clusterAffinities. Am I right?

Thank you for your response.

Are you referring to the Kubernetes sig KEP-2149: ClusterId for ClusterSet identification ?

I am not particularly familiar with the details here. Can Karmada currently use or plan to use the API? I did not find any relevant information.

To further clarify my question: HOPE is to separate the rules of each clusterAffinity and then, when editing the PropagationPolicy,and just reference this clusterAffinity rule.

RainbowMango commented 1 year ago

Are you referring to the Kubernetes sig KEP-2149: ClusterId for ClusterSet identification ?

Yes, I guess we can talk about it at the community meeting. I like the idea.