Remove derived mcs

Signed-off-by: zishen <softwarebtg@163.com>

docs/proposals/mcs/remove-derived-mcs.md

@@ -0,0 +1,109 @@
+# Remove "derived-" prefix of MCS 
+
+## Summary
+
+As mentioned in [issue-2384](https://github.com/karmada-io/karmada/issues/2384), currently karmada uses ServiceExport, ServiceImport and other CR to form mcs-controller and manage multi-cluster services. But in the cluster where the service is not located, we need to use a different IP or a service name with a "derived-" prefix to access. We hope to reduce this difference so that different clusters can use the same domain name to access the same service.
+
+## Motivation
+
+Currently, in different cluster members of Karmada, if you need to access the same service across clusters, you need to use different ip or domain names with a "derived-" prefix to access. This will increase the complexity of the user's use. We hope that users can use the same domain name to achieve cross-cluster access.
+
+### Goals
+
+* Keep the original access method. Avoid the need to make modifications to the customer's system after the upgrade.
+* Added the use of a unified domain name for cross-cluster access. The domain name is the access domain name of the cluster where the service resides.
+
+### Non-Goals
+
+none
+
+## Proposal
+
+### User Stories
+
+According to the current Karmada's  [mcs configuration](https://karmada.io/docs/userguide/service/multi-cluster-service) , if the service is currently in member1, the user needs to access the service in member1, needs to use the domain name: "serve.default.svc.cluster.local", and the domain name in member2 will be: "derived-serve.default.svc.cluster.local". As a result, when customers use the service, they need to add the prefix "derived-" to access the domain name of the service. This brings additional inconvenience. So I hope to be able to:
+
+1. Provide a unified access method across clusters.
+
+2. The original access method remains unchanged. So that existing business can also work normally.
+
+### Notes/Constraints/Caveats (Optional)
+
+1. The coredns version must be v1.9.3 or above, otherwise the multicluster feature is not supported
+
+### Risks and Mitigations
+
+
+
+## Design Details
+
+### API change
+
+none
+
+### Components change
+
+Both the cluster where the service resides and the client cluster need to modify coredns.
+
+For the compilation and configuration methods of the multicluster plug-in, please refer to: https://github.com/coredns/multicluster
+
+Here we take the "clustered.local" domain as an example to introduce the permissions and corefile configuration of coredns.
+
+* Add multicluster processing rules in corefile in coredns
+
+```shell
+kubectl edit configmap coredns -n kube-system
+ ....
+   Corefile: |
+    .:53 {
+        errors
+        health {
+           lameduck 5s
+        }
+        ready
+        multicluster clustered.local
+        kubernetes cluster.local in-addr.arpa ip6.arpa {
+           pods insecure
+           fallthrough in-addr.arpa ip6.arpa
+           ttl 30
+        }
+        prometheus :9153
+        forward . /etc/resolv.conf {
+           max_concurrent 1000
+        }
+        cache 30
+        loop
+        reload
+        loadbalance
+    }
+...
+```
+
+* RBAC permissions need to add read permissions to serviceimports
+
+kubectl edit clusterrole system:coredns
+
+```shell
+...
+- apiGroups:
+  - multicluster.x-k8s.io
+  resources:
+  - serviceimports
+  verbs:
+  - list
+  - watch
+```
+
+
+
+### Test Plan
+
+- All current testing should be passed, no break change would be involved by this feature.
+- Add new E2E tests to cover the feature, the scope should include:
+  - Workload propagating with scheduling type `Duplicated`.
+  - Workload propagating with scheduling type `Divided`
+  - Failover scenar
+
+
+
+## Alternatives