KEP 1645: slightly relax the managed by requirements on EndpointSlices

Relax a bit the sentence about EndpointSlice marked as not managed by
the endpointslice controller as some EndpointSlice might be actually
managed by the endpointslice controller directly. For instance Cilium
implementation currently uses the default endpointslice controller to
manage the EndpointSlice from the local cluster.

The sentence below still implies that imported EndpointSlice must be
managed by a MCS-API controller which means that this mixed scenario can
be conformant while still keeping a strong guideline for EndpointSlice
managed by a MCS-API controller.

Signed-off-by: Arthur Outhenin-Chalandre <[email protected]>

Author: MrFreezeex

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

@@ -880,9 +880,10 @@ When a `ServiceExport` is created, this will cause `EndpointSlice` objects for
 the underlying `Service` to be created in each importing cluster within the
 clusterset, associated with the derived `ServiceImport`. One or more
 `EndpointSlice` resources will exist for the exported `Service`, with each
-`EndpointSlice` containing only endpoints from a single source cluster. These
-`EndpointSlice` objects will be marked as managed by the clusterset service
-controller, so that the endpoint slice controller doesn’t delete them.
+`EndpointSlice` containing only endpoints from a single source cluster. An
+`EndpointSlice` created by an mcs-controller must be marked as managed by the
+mcs-controller, not the default `EndpointSlice` controller to avoid any conflicts
+between the controllers.
 
 When a service is un-exported, the associated EndpointSlices will be deleted.
 The specific mechanism by which they are deleted is an implementation detail.