[MCS] Remove "derived-" prefix of MCS

[lihui920913]

What would you like to be added: Remove "derived-" prefix of MCS， so user can use the same k8s service name in other k8s clusters.

Why is this needed: Karmada is supposed to offer one-cluster view. However user need to change there application settings when using MCS.

Maybe there could be an validation to refuse the ServiceImport object when there has been a same-name service in the target cluster.

[GitHubxsy]

Consider providing feature switches. Allows users to associate endpointslices with the original service. @RainbowMango @XiShanYongYe-Chang

[XiShanYongYe-Chang]

Consider providing feature switches. Allows users to associate endpointslices with the original service.

+1

But the current issue seems to be pointing to something else.

[bivas]

Following a discussion in Karmad'a community Slack channel

I've tested the following flows to support the service import idea:

1. Deployment and Service are created on cluster member1 and the Service imported to cluster member2 using ServiceImport
2. Deployment and Service are created on cluster member1 and both propagated to cluster member2. Service from cluster member1 is imported to cluster member2 using ServiceImport

Scenario 1

Service from member1 is available in member2. The service can be accessed inside member2 as an ordinary Service with the name foo.myspace.svc.cluster.local . The import process doesn't prefix the service with derived- prefix but still uses import- for the EndPointSlice

Scenario 2

Service from member1 has a conflict when attempting to import to member2. I changed the controller to avoid this collision and ignore the Service creation and only create the EndPointSlice (still prefixed with import-). Cluster member2 has the following:

• Service with the name foo
• 2 EndPointSlice
  • First EndPointSlice is accessing the local Deployment running in member2
  • Imported EndPointSlice pointing to the remote Deployment running in member1 When I attempt to access the service in cluster member2 using foo.myspace.svc.cluster.local the requests go round robin between local and remote services (member1 and member2).

The way that I implemented this flow is what can be referred to as local-and-remote service discovery. The options could be:

1. Local only - in case there's a local service by the name foo Karmada never attempts to import the remote service and doesn't create the EndPointSlice
2. Local and Remote - this is the scenario I implemented. Users accessing the foo service will reach either member1 or member2
3. Remote only - in case there's a local service by the name foo Karmada will remove the local EndPointSlice and will create the EndPointSlice pointing to the other cluster (e.g. instead of resolving member2 cluster is will reach member1)

My tested code is missing a lot of the conflict resolution logic and I just created it as a highly tailored PoC. This implementation aligns with the KEP-1645 guidelines and adapts concepts from liqo and submariner for service import.

[XiShanYongYe-Chang]

Hi @bivas, I'm very sorry for not keeping track of the progress and responding to your reply for such a long time. Recently, I have been busy with other things which caused a delay in this matter.

I think your testing and practice are great. Remove the "derived-" prefix from the service, which will be a very user-friendly action and bring us many benefits.

Can we further advance this plan? Would you like to propose a proposal so that we can further promote the implementation of this plan in the Karmada community?

Apologies again for my delayed response.