Design question: weight calculation logic

[ryanwuer]

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

What do you think about this question?:

Environment:

• Karmada version: v1.13.0
• Kubernetes version: v1.19.3
• Others:

I try to schedule a replicaset to two K8s, the replicas is 2, the PropagationPolicy is like below:

    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - a
            weight: 2
          - targetCluster:
              clusterNames:
                - b
            weight: 1

As a result, there're a replicaset with replicas of 2 scheduled to a, and none scheduled to b, does this meet design pattern?

I guess the logic is:

a= 2/(2+1) * 2 = 1.333 -> 2
b= 2 - 2 = 0

What i actually expect is 1 for a and 1 for b. At least 1 replica is given to workloads scheduled by karmada. Is that reasonable?

[zhzhuang-zju]

As a result, there're a replicaset with replicas of 2 scheduled to guiyang-test-1, and none scheduled to guiyang-test-2, does this meet design pattern?

@ryanwuer Thanks for reporting this. In fact, the relevant scheduling logic is almost the same as what you guessed. The details are as follows:

Updated:

remain = 2
a= 2/(2+1) * 2 = 1.333 -> 1
remain = 1
b = 1/(2+1) * 2 = 0
remain = 1

# begin assigning the rest replicas
a ++  -> 2
remain --  -> 0
# break as no rest replicas

When the replicas is small or when the weight of a certain cluster is too high, it is indeed possible that the replicas in a certain cluster is zero.

[ryanwuer]

Is it necessary or reasonable to make sure each target cluster has at least one replica? What do you think?

[zhzhuang-zju]

If we ensure that each target cluster has at least one replica, this constraint may conflict with the static weight. For example, suppose the total number of replicas is 50 and there are three target clusters with weights: a 99, b 1, c 1. If each target cluster is guaranteed at least one replica, the final number of replicas should be: a 48, b 1, c 1. In this case, the proportion of cluster a is 0.96, which differs significantly from the set ratio of 99/101.

[ryanwuer]

But it has the same problem if using current logic, which will make b's and c's real ratio be 0 other than 1.

remain = 50
a= 99/(99+1+1) * 50 = 49.009 -> 50
remain = 0
b = 1/(99+1+1) * 0 = 0
remain = 0
c = 1/(99+1+1) * 0 = 0

[ryanwuer]

@RainbowMango What do you think of this issue?

[RainbowMango]

What i actually expect is 1 for a and 1 for b. At least 1 replica is given to workloads scheduled by karmada. Is that reasonable?

I want to know the real-world use case behind this.

[ryanwuer]

We have two K8s, A and B. A's resources are twice as much as B's. So we set a default weight config -> a:2,b:1.
It's normal in most cases because most workloads have more than 3 replicas. A and B can be used at the same time.
But there're some workloads that have only two replicas. Then these workloads will lose the advantage of fault tolerance guaranteed by multiple zone/K8s.

[ryanwuer]

Any updates for this issue?

[zhzhuang-zju]

@ryanwuer Sorry for the late reply. @RainbowMango is attending KubeCon China this week, so he may not have time to check messages promptly.

[zhzhuang-zju]

It would be better if you could add an agenda to the community's regular meeting, and we can discuss it with the attendees together.

[ryanwuer]

It would be better if you could add an agenda to the community's regular meeting, and we can discuss it with the attendees together.

I've added an item here, is that all?

[zhzhuang-zju]

I've added an item here, is that all?

Yeah~ the meeting will be held at 2:30 pm next Tuesday.

[RainbowMango]

It sounds like a reasonable use case to me. Having a chat at the community meeting would be great!
We can figure out the priority of this and discuss the plan.