Expanded pods can still be scheduled to notready clusters

[CharlesQQ]

What would you like to be added:

karmada/pkg/scheduler/framework/plugins/tainttoleration/taint_toleration.go

Lines 61 to 62 in 8c7607e

	if bindingSpec.TargetContains(cluster.Name) {
	return framework.NewResult(framework.Success)

For clusters where pods already exist, cluster taint constraints will be ignored.

Why is this needed:
Expanded pods should not be scheduled to notready clusters

[RainbowMango]

I can't get details info about why it is needed, just sharing my understanding of NoSchedule taints.

Echo the definition of Taint Effect No Schedule here:

// Do not allow new pods to schedule onto the node unless they tolerate the taint,
// but allow all pods submitted to Kubelet without going through the scheduler
// to start, and allow all already-running pods to continue running.
// Enforced by the scheduler.
TaintEffectNoSchedule TaintEffect = "NoSchedule"

For Kubernetes, new pods won't be scheduled onto nodes if they cannot tolerate a taint on those nodes.
For Kubernetes, new applications won't be scheduled onto clusters if they cannot tolerate a taint on those clusters.

In Karmada, a cluster will be marked with NoSchedule taints if it becomes unreachable, it doesn't make sense for the scheduler to make the decision that propagate applications or pods to that cluster.

[CharlesQQ]

By default，for a new RB object, taint_toleration plugin will,new applications won't be scheduled onto clusters if they cannot tolerate a taint on those clusters; However, If the application is already running on a tainted cluster, If the application is already running on a tainted cluster and pod expansion occurs, the tainted cluster will not be filtered; as a result, the pod may be expanded on this cluster.