search

karmada-io / karmada

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

[Feature] Support merge GetDependensis result #5121

Open Vacant2333 opened 3 weeks ago

Vacant2333 commented 3 weeks ago

What would you like to be added: I hope Karmada can merge the results of defaultInterpreter and customizedInterpreter.

Ref: https://github.com/Vacant2333/karmada/blob/3232c52d57b331d7120eeaac9386b848197475df/pkg/resourceinterpreter/interpreter.go#L277

Why is this needed: As a user, when I submit a vcjob/pod/deployment, I have my own additional controller that creates an extra associated resource, PodGroup, for vcjob/pod/deployment. I want to deploy it to the target cluster along with the main resource. I understand that the PropagateDeps feature can achieve this, but we cannot explicitly associate the PodGroup with the main resource. When the PodGroup is created, it only marks the resource it is associated with in the annotation. Therefore, we have thought of two methods:

  1. When creating the PodGroup, simultaneously create a ResourceBinding for this PodGroup and supplement it with RequireBy to achieve simultaneous scheduling to the same cluster.
  2. Use the ResourceInterpreterCustomization method to modify the results of GetDependencies to include our PodGroup.

The first solution seems feasible, but I believe it can only be a temporary solution, so our focus is mainly on the second solution. For the second solution, once we set the ResourceInterpreterCustomization for pod/deployment, it will replace the Default Interpreter, which we do not want. What we need is to add a PodGroup to the results of the DefaultInterpreter.

Thanks! Can guys give me some comments about this feature?

XiShanYongYe-Chang commented 3 weeks ago

@Vacant2333, thanks for your user case.

I think you're referring to the InterpretDependency hook point. It may not be necessary for other interpreters to merge results.

The current feasible method is to implement the defalut interpreter again when the user customizes the InterpretDependency interpreter behavior. This is really bad for user experience. I think it is a point that can be optimized iteratively.

What do you think? @chaunceyjiang @yike21 @RainbowMango @whitewindmills

Vacant2333 commented 3 weeks ago

@Vacant2333, thanks for your user case.

I think you're referring to the InterpretDependency hook point. It may not be necessary for other interpreters to merge results.

The current feasible method is to implement the defalut interpreter again when the user customizes the InterpretDependency interpreter behavior. This is really bad for user experience. I think it is a point that can be optimized iteratively.

What do you think? @chaunceyjiang @yike21 @RainbowMango @whitewindmills

Yes, I think this is an area that can be optimized. If I need to modify the Pod’s GetDependensis, then I need to obtain the results from karmada’s defaultInterpreter and also add my own results.

XiShanYongYe-Chang commented 3 weeks ago

@Vacant2333 Perhaps we can discuss this topic at the community meeting.

XiShanYongYe-Chang commented 2 weeks ago

Hi @Vacant2333 how about discussing this issue at the regular community meeting next Tuesday?

Vacant2333 commented 2 weeks ago

Hi @Vacant2333 how about discussing this issue at the regular community meeting next Tuesday?

OK! thank u!