LabelSelector design principle ?

[XMingG99]

My PropagationPolicy looks like this.

apiVersion: policy.karmada.io/v1alpha1
...
spec:
...
  placement:
  clusterAffinity:
    labelSelector:
      matchLabels:
        type: local

Then, when deploying, the cluster with label type: local will be deployed resources. In this case, when I label other clusters without labels, the cluster will also be deployed with the same resources. However, when the cluster with deployed resources has removed its label, the deployed resources of the cluster will not be deleted. What is the consideration here? (Why not delete the deployed resources?)

[RainbowMango]

Then, when deploying, the cluster with label type: local will be deployed resources. In this case, when I label other clusters without labels, the cluster will also be deployed with the same resources.

The resource shouldn't be deployed to cluster without the type: local label. Can you share the reproduce steps?

However, when the cluster with deployed resources has removed its label, the deployed resources of the cluster will not be deleted.

The affinity declaration is a kind of scheduling rule, it takes effect during the first schedule. After the first schedule, Karmada now tends to keep the last schedule result.
In addition, we are still considering adding more controls to re-schedule letting the scheduling result always follow the latest policy rules. I'd like to hear your case in detail. Can you share with us here or community meeting?

[XMingG99]

OK, I think there is some misunderstanding here.

Env:
Karmada v1.3.2
Cluster number: 3 (We can call them clusterA, clusterB and clusterC)

Steps:
step1: Label clusterA and clusterB with type: local
step2: Apply the resourcetemplate and propagationpolicy(replicaSchedulingType : Duplicated, labelSelector: type: local)
After step2, we'll know that the resource will be deployed in clusterA and clusterB, corresponding worker will be created too. And now, we do step3.
step3: Label clusterC will type: local.
After step3, clusterC will be deployed resource, I think this is a good design. Is there a label controller under maintenance？
step4: Unlabel clusterA with type: local
And my original problem is that when we unlabeled the cluster, but the resource will not be deleted. You had resolved my question, thank u.

[RainbowMango]

After step3, clusterC will be deployed resource, I think this is a good design. Is there a label controller under maintenance？

No, Karmada doesn't have a dedicated controller for the label changes. But Karmada scheduler watches all changes for each cluster, including label/annotation, spec, healthy status ..., The scheduler would respond to the changes respectively.