gateway-api
gateway-api copied to clipboard
kubernetes-sigs
GEP: add HTTPRoute Mesh Binding proposal
What type of PR is this? /kind feature /kind gep /area mesh
What this PR does / why we need it:
Proposes an approach for service owners to configure service mesh traffic routing rules using an HTTPRoute with a Kubernetes Service resource as a parentRef.
Which issue(s) this PR fixes:
Fixes #1294
Does this PR introduce a user-facing change?:
NONE
Adding the document here for posterity. I've collected a set of concerns and suggestions for the current HTTPRoute mesh binding proposal. Tl;dr is I believe that remodeling the definition of a Kubernetes service to split into a frontend and backend is inherently the wrong approach, and we should follow suit with what the multicluster services API is doing by finding another mechanism to register DNS entries and a ClusterIP. More specific reasoning in the document below.
https://docs.google.com/document/d/1yPvLQLTuokU73x_59BKShozBe1fA13xbwaZAWNgjBIg/edit
/hold
The actual file needs to be renamed from site-src/geps/gep-1424.md to site-src/geps/gep-1426.md before merging, but I don't want to break any comments accidentally.
@robscott @howardjohn would appreciate a final review at this point!
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: howardjohn, mikemorris, shaneutt
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [shaneutt]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@steeling I did add a specific goal in response to your feedback, I understand we may disagree on the expected UX/behavior, but it should at least be explicitly stated as a goal now, rather than an assumption.
- SHOULD NOT require downstream "consumer" services to update configuration or DNS addresses for traffic to follow "producer" mesh routing rules configured by upstream services.