add EP-10611 #10674
add EP-10611 #10674
Conversation
lgadban
force-pushed
the
law/ep-rename-upstream
branch
from
42654db to
1b4826d
Compare
design/10611.md
Outdated
|
|
||
| AWS Lambdas and GCP Cloud Run services are examples of backends that have no native representation in Kubernetes, thus a standalone resource to represent them makes complete sense. | ||
|
|
||
| Static/external hosts theoretically have a way to be expressed via K8s as `Service` of `ExternalName` type, although this usage is not supported in Gloo Gateway (and now, kgateway) mostly due to lack of user demand. Additionally, there are some caveats with ExternalName services that may discourage use if there is a viable alternative. In this case, using the `Upstream` resource also makes sense. |
There was a problem hiding this comment.
there are some caveats with ExternalName services
what are the caveats?
There was a problem hiding this comment.
See the 'Caution' section here: https://kubernetes.io/docs/concepts/services-networking/service/#externalname
I'll add this reference into the EP.
design/10611.md
Outdated
| The `Upstream` name and concept are well-established for GG users but the current API does not completely fit the semantics and idioms of the K8s Gateway API. | ||
|
|
||
| The first "layer" of defining various backend types that do not have a native K8s representation is still relevant & important within K8s Gateway API, with the exception of not needing to support native `Services`. | ||
| In fact, this is the [primary extension point](https://gateway-api.sigs.k8s.io/concepts/api-overview/#extension-points) for supporting non-K8s backends. |
There was a problem hiding this comment.
"this is the primary extension point" - do you mean backendRefs?
There was a problem hiding this comment.
"This" being a custom type that backendRefs can refer to.
I'll clear this wording up.
|
|
||
| ## Proposal | ||
|
|
||
| **Rename the `Upstream.kgateway.dev` type to `Backend.kgateway.dev`.** |
There was a problem hiding this comment.
are there pros / cons to having a single Backend resource vs having a separate resource per backend type, e.g. AwsBackend, GcpBackend, etc?
There was a problem hiding this comment.
There is definitely some discussion that can be had on this, in fact this might be relevant to the AI Gateway feature that is actively being worked on.
However I think it should be considered out of scope for this EP as I am primarily focused on the naming of the existing type, which is currently 'monolithic' API. The 'monolithic' style also currently applies to our policy APIs (e.g. RoutePolicy) so changing that should be a larger discussion.
That isn't to say that in the (near) future we may want to have discrete resources to represent the various backend types. In fact it may actually be preferable to go down this path but we should probably capture that in a separate EP.
There was a problem hiding this comment.
No description provided.