search

karmada-io / karmada

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

add workload annotation propagationpolicy.karmada.io/cluster #4440

Open CharlesQQ opened 4 months ago

CharlesQQ commented 4 months ago

What would you like to be added: add Annotation：key=propagationpolicy.karmada.io/cluster, value is cluster name Annotation must be added before call Interperter Retain InterpreterOperation

Why is this needed: interperter webhook server need to know cluster that workload belong to

chaunceyjiang commented 4 months ago

+1

How about cluster.karmada.io/name: ClusterA ?

CharlesQQ commented 4 months ago

+1

How about cluster.karmada.io/name: ClusterA ?

I have no objection about this

XiShanYongYe-Chang commented 4 months ago

+1 This annotation allows users to better handle resource templates when extending the resource interpreter.

chaunceyjiang commented 4 months ago

I can try to fix this issue.

/assign

XiShanYongYe-Chang commented 4 months ago

Can you mention it at tomorrow's community meeting?

CharlesQQ commented 4 months ago

Can you mention it at tomorrow's community meeting?

sure

RainbowMango commented 4 months ago

The annotation seems to indicate a destination decision that is supposed made by the scheduler. That is concerning.

interperter webhook server need to know cluster that workload belong to

Can you explain in more detail? Why the webhook need to know cluster info?

chaunceyjiang commented 4 months ago

Why the webhook need to know cluster info?

The problem we encountered: We only need to retain the modifications of the member clusters in specific clusters, but this interface cannot distinguish which member cluster the current resource is to be distributed to.

Therefore, our current approach is to use an OP to annotation resources with the name of the cluster.

https://github.com/karmada-io/karmada/blob/adef1e59748e1e1d31cb75fffe406b5dd69a66d7/pkg/resourceinterpreter/interpreter.go#L51-L54

XiShanYongYe-Chang commented 1 week ago

Cluster information can provide more judgment basis for user-defined extension. Can we continue to promote this issue? @RainbowMango

weidalin commented 1 week ago

Cluster information can provide more judgment basis for user-defined extension. Can we continue to promote this issue? @RainbowMango

Providing the following annotation can provide users with stronger extensions

cluster.karmada.io/name: ClusterA

Alternatively, providing the target cluster name in the ctx context can also achieve the same results

func (e *atmscmInterpreter) Handle(ctx context.Context, req interpreter.Request) interpreter.Response {
   targetCluster:= ctx.Value("targetCluster").(string)
   ...
}

Or provide target cluster name in interpreter.Request

func (e *atmscmInterpreter) Handle(ctx context.Context, req interpreter.Request) interpreter.Response {
   targetCluster:= req.TargetCluster
   ...
}