KEP 1645: add traffic distribution and internal traffic policies fields

[MrFreezeex]

• One-line PR description: Add traffic distribution and internal traffic policies fields on ServiceImport to match Service API

• Issue link: Multi-Cluster Services API #1645

• Other comments: Note that the traffic distribution is also a string/not a enum in Service API, see this: https://github.com/kubernetes/kubernetes/blob/4a1558c545ecbed18b6d6fc69f3d842f9bc491e3/pkg/apis/core/types.go#L5135

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MrFreezeex
Once this PR has been reviewed and has the lgtm label, please assign skitt for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/sig-multicluster/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lauralorenz]

Triage notes:

• There is some nuance in the underlying SIG-Network KEP about what the field is, discussed in the accompanying PR in apis: conformance: add traffic distribution and internal traffic policies fields kubernetes-sigs/mcs-api#131 (review)
• We seem ok to push this through here and address the follow on SIG-Network KEP mentioned above later (since it may be that additional options will land that would also be lifted in the ServiceImportSpec)

[zhiying-lin]

Could you please clarify that how consumers define traffic distribution within the multi-clusters?

Are we going to reuse the existing Internal Traffic Policy and TrafficDistribution in the service? I feel it's confusing as these fields define how the traffic to be routed within the cluster itself, not about multi-clusters env.

[MrFreezeex]

Will try to find if there are places where we can say that but yes this is from the Service field and PreferSameAZ could works across clusters (different clusters using the same AZ) and if not it's still valuable to prefer something in the local cluster and then fallback to the rest of the endpoints whether they are in a different clusters or not (which would be true for preferring the same host also)

[mikemorris]

We might want to additionally consider a KEP for extending the enum to include PreferSameRegion? IDK how useful that might be in practice, or if PreferSameZone would be more optimal in most cases...

[MrFreezeex]

Possibly yes, my larger proposal is that we let the trafficDistribution from the Service prefer endpoint (without a "s") from the EndpointSlices while aside of that we could prefer a group of EndpointSlice based on what clusters they are from with a field in the ServiceExport. And this would be very well compatible with a PreferSameRegion on the traffic distribution but it would most likely need a full SIG-network driven kep that would also involve updating EndpointSlice to add the region info there somehow.

The main idea here is to mainly try to propagate the user intent from existing fields (and values) and later on (in dedicated KEP and most likely by working/getting advices from SIG-Network folks) we could very well extend the existing traffic distribution field or add some new fields somewhere that would either work alongside trafficDistribution or be mutually exclusive somehow.

[mikemorris]

Both of these additions would likely benefit from including links to the definition/values in Service docs.