Skip to content

KEP 1645: add traffic distribution and internal traffic policies fields #5588

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+23 −2
Open

KEP 1645: add traffic distribution and internal traffic policies fields #5588

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 23 additions & 2 deletions keps/sig-multicluster/1645-multi-cluster-services-api/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,8 @@ tags, and then generate with `hack/update-toc.sh`.
- [Service Port](#service-port)
- [Headlessness](#headlessness)
- [Session Affinity](#session-affinity)
- [Internal Traffic Policy](#internal-traffic-policy)
- [Traffic Distribution](#traffic-distribution)
- [Labels and Annotations](#labels-and-annotations)
- [Test Plan](#test-plan)
- [Graduation Criteria](#graduation-criteria)
Expand Down Expand Up @@ -481,8 +483,9 @@ ensure that a name is shared by multiple services within the namespace if and
only if they are instances of the same service.

Most information about the service, including ports, backends, topology and
session affinity, will continue to be stored in the `Service` objects, which
are each name mapped to a `ServiceExport`. This does not apply for labels and
session affinity, internal traffic policy, and traffic distribution
will continue to be stored in the `Service` objects, which are each name
mapped to a `ServiceExport`. This does not apply for labels and
annotations which are stored in `ServiceExport` directly in `spec.exportedLabels`
and `spec.exportedAnnotations`. Exporting labels and annotations is optionally
supported by MCS-API implementations. If supported, annotations or labels must
Expand Down Expand Up @@ -575,6 +578,12 @@ type ServiceImportSpec struct {
SessionAffinity corev1.ServiceAffinity `json:"sessionAffinity"`
// +optional
SessionAffinityConfig *corev1.SessionAffinityConfig `json:"sessionAffinityConfig"`
// +optional
InternalTrafficPolicy *corev1.ServiceInternalTrafficPolicy `json:"internalTrafficPolicy,omitempty"`
// The possible TrafficDistribution values should match what can be similarly
// defined in a Service, see https://kubernetes.io/docs/concepts/services-networking/service/#traffic-distribution
// +optional
TrafficDistribution *string `json:"trafficDistribution,omitempty"`
}

// ServicePort represents the port on which the service is exposed
Expand Down Expand Up @@ -1026,6 +1035,18 @@ Session affinity affects a service as a whole for a given consumer. The derived
service's session affinity will be decided according to the conflict resolution
policy.

#### Internal Traffic Policy

Internal traffic policy affects a service as a whole for a given consumer. The derived
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@MrFreezeex MrFreezeex Oct 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

@mikemorris mikemorris Oct 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Member Author

@MrFreezeex MrFreezeex Oct 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

service's internal traffic policy will be decided according to the conflict resolution
policy.

#### Traffic Distribution

Traffic distribution affects a service as a whole for a given consumer. The derived
service's traffic distribution will be decided according to the conflict resolution
policy.

#### Labels and Annotations

If supported, exporting labels and annotations would affect a `Service` as a whole
Expand Down