GEP-3792: Off-Cluster Gateways #3851
Conversation
Signed-off-by: Flynn <[email protected]>
Signed-off-by: Flynn <[email protected]>
k8s-ci-robot
added
release-note-none
k8s-ci-robot
added
the
size/L
k8s-ci-robot
added
the
approved
| proxy. This is simple to reason about, easy to manage for sidecar meshes, and | ||
| will presumably be an important implementation mechanism for the foreseeable | ||
| future. Some cloud providers, though, are moving the proxy outside of the | ||
| cluster, for various reasons which are out of the scope of this GEP. Chihiro |
There was a problem hiding this comment.
Could you elaborate on one or two of those reasons? It would help to have use cases. I'm not clear on the purpose of this as a part of Gateway API since it seems to not be doing service networking.
There was a problem hiding this comment.
I'll defer this one to @robscott, @keithmattix, and @mikemorris, who are all working with cloud providers who're looking at doing this. I may or may not be able to correctly summarize their reasons.
I personally tend to believe that it is easier to reason about Kubernetes Gateways if, y'know, they run in Kubernetes. Shockingly, I have been unable to convince major cloud providers that they should change their plans due solely to my opinion. 😇
There was a problem hiding this comment.
A primary reason is that off-cluster gateways can be used to offer a cleaner "managed" experience, where a "logical" gateway can scale much easier without requiring users to be responsible for managing underlying compute/memory resources, potentially be consolidated onto purpose-built infrastructure hardware or networking, offer alternative billing models (like per request instead of trying to estimate needed compute costs), integrate more seamlessly into other cloud product offerings, etc
|
Thanks @kflynn! In my opinion this PR is sufficiently complete to continue on in v1.4. I'd usually go ahead and merge, but there are some great questions from @candita that were recently added, and I don't want to lose those. So will LGTM and leave hold. Feel free to remove once remaining questions are resolved. /lgtm |
k8s-ci-robot
added
the
lgtm
|
Yes, I'm okay with merging as provisional for now, as long as we don't lose the outstanding comments. Maybe if the changes are too full on, we can record them in an in-document TODO and then merge this? |
shaneutt
left a comment
shaneutt
left a comment
There was a problem hiding this comment.
Looks good to merge as Provisional.
/approve
/lgtm
However there are a few lingering comments with concerns, we should create a "TODO" list of sorts under the graduation criteria enumerating these concerns to point out that we need to address them prior to any further graduation.
/hold
After those are documented, we are good to release the hold and merge.
Signed-off-by: Flynn <[email protected]>
k8s-ci-robot
removed
the
lgtm
shaneutt
left a comment
shaneutt
left a comment
There was a problem hiding this comment.
Looks like comments are largely resolved, we have some extra graduation criteria, and there are no reviews that are blocking. We appear to be ready to move forward as Provisional.
/approve
/lgtm
/unhold
If anyone reviewing this does have a lingering concern that we missed, please feel free to create a follow-up PR adding anything you feel is missing to the GEP.
k8s-ci-robot
added
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kflynn, LiorLieberman, robscott, shaneutt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* GEP-3792 Signed-off-by: Flynn <[email protected]> * Wordsmith feature name. Signed-off-by: Flynn <[email protected]> * Address review feedback. Signed-off-by: Flynn <[email protected]> --------- Signed-off-by: Flynn <[email protected]>
10 participants
/kind gep
What/Why/Who for off-cluster Gateways being able to usefully participate in on-cluster meshes.
Fixes #3792.