karmada-io
For the scheduler APIEnablement plugin, scheduled resources are never deleted under any situation
What would you like to be added:
For the scheduler APIEnablement plugin, scheduled resources are never deleted under any situation.
Why is this needed:
The current logic of the APIEnablement plugin is that when the cluster API list is trusted, if the GVK (Group, Version, Kind) of a resource is not in the API list, the cluster will be filtered out. If the previous scheduling result included this cluster, the target resource in the cluster will be deleted.
This handling logic may not be suitable in the following scenario: A user maintains a CRD (Custom Resource Definition) resource in a member cluster and then propagates the CR (Custom Resource) of that CRD through the Karmada control plane. If the user accidentally deletes the CRD resource in the cluster and triggers the scheduler to reschedule the CR resource, even if the user reinstall the CRD resource in the member cluster, the CR resource will not be able to be recreated in the member cluster.
Therefore, to make the user's resources more stable, we can modify the logic of the APIEnablement plugin so that it never deletes scheduled resources under any circumstances.
This proposal attempts to refine PR #5216 to make the APIEnablement plugin more predictable and avoid unexpected removal of workloads.
@yanfeng1992 @whitewindmills any thoughts?
@XiShanYongYe-Chang: GitHub didn't allow me to assign the following users: abhinav-1305.
Note that only karmada-io members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see the contributor guide
In response to this:
In favor of #6462 /assign @abhinav-1305
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
+1 we should rule out the potential risks of APIENABLEMENT. as for the legacy APIENABLEMENT status design, it can be used as an operation and maintenance troubleshooting measure for administrators.
