GEP: Service Mesh in Gateway API
What would you like to be added: Due to the overlap in surface area between the Gateway API's routing primitives and many service mesh implementations, it would be generally beneficial to the Kubernetes community for the Gateway API to provide/support patterns and/or new resources for service mesh functionality.
Why this is needed: While attempting to scope out #1291 and #1294, it became apparent that more higher level context was needed to first answer the "what" question. Both of those issues are intrinsically tied to implementation details, so it is useful to first have a GEP that describes what service mesh interoperability in Gateway API is trying to accomplish.
/area mesh
/assign
Let's leave this open until the GEP reaches a more complete state, probably "implemented".
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale /lifecycle frozen
This will stick around until something is implementable
I think this should be able to be closed soon with https://github.com/kubernetes-sigs/gateway-api/pull/2873 moving GAMMA to Standard for Gateway API v1.1
/cc @shaneutt @robscott
Yes, given that this GEP is now a Memorandum, I think it makes sense to close this out.