Skip to content

KEP 1645: add more conflict condition on asymetrical traffic #5706

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
MrFreezeex wants to merge 1 commit into
base: master
Choose a base branch
from
+7 −2
Open

KEP 1645: add more conflict condition on asymetrical traffic #5706

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
9 changes: 7 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 @@ -489,7 +489,10 @@ a hint to influence the `IPs` and `ipFamilies` of the ServiceImport object.
The exact mechanism for determining those fields is implementation-defined.
If `ipFamilies` is set on the ServiceImport object, it must not have duplicated
families (for instance `ipFamilies: [IPv4, IPv4]` is not valid) and the IPs
should eventually be in the same order as what is defined in `ipFamilies`.
should eventually be in the same order as what is defined in `ipFamilies`. If
conflicting `ipFamilies` are found among the constituent Services, implementations
must raise an `IPFamilyConflict` condition when this might result in network
traffic reaching only a subset of the backends depending on the IP protocol used.

Also note that even in a dual stack cluster regular Services are by default SingleStack
which might default to IPv4 or IPv6 depending on the cluster configuration and there
Expand Down Expand Up @@ -1020,7 +1023,9 @@ The conflict will be resolved by assigning precedence based on each
A derived service will be accessible with the clusterset IP at the ports
dictated by child services. If the external properties of service ports for a
set of exported services don’t match, the clusterset service will expose the
union of service ports declared on its constituent services.
union of service ports declared on its constituent services and raise a `PortConflict`
conflict condition. In that case, network traffic must be directed only to endpoints
Copy link
Contributor

@lauralorenz lauralorenz Dec 3, 2025

Choose a reason for hiding this comment

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

In sentence for how IPFamilies should be handled above, its directed that the implementer "may" raise a conflict, while this one I'm commenting on here which is for ports says they "will". This line about ports is also more strict on what must be done for routing ("must be directed only") vs how it is described above for IPFamilies ("might result in network traffic reaching only a subset"). Is the difference in how these are treated on purpose? Based on what I saw from the notes from when we discussed in SIG-MC (ref) I think they should both mandate that the conflict raise should be required but how the implementation routes should be implementation defined.

Copy link
Member Author

@MrFreezeex MrFreezeex Dec 3, 2025

Choose a reason for hiding this comment

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

Ah yes indeed, I used "may" for IPFamilies because the exact handling is all implementation defined but since there is a "when" in the sentence which may not apply to some implementations it seems fine to change the "may" by a "must" and some implementations won't need to care about that at all. We would most likely not be able to check that in the conformance tests though but that's a separate concerns from the KEP anyway!

from constituent services that actually expose the targeted port.

Like regular services, the resulting ports must respect two rules:
- Have no duplicated names (including unnamed/empty name)
Expand Down