You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have thousands of app developers who are able to define a Kubernetes Ingress object, along with annotates to express the TLS certificate that should be automatically provisioned and used for that ingress (e.g. pretty typical ingress-nginx + cert-manager setup). To look at Gateway API, we need some way for developers to express their hostname(s), paths that map to their service, AND certifications that should be used.
This project's decision to remove TLS configuration from individual HTTPRoute objects means these TLS termination details must be expressed at the Gateway level.
This pushes adopters toward making lots of Gateway's and treating them as a developer detail (see #2665. But a Gateway is generally associated with physical infrastructure and has management / financial cost. It's in the realm of the infra provider. We run a few (public, private). It doesn't make sense for the app developer to manage Gateway's even in Gateway API's own docs, it contrasts with the original goal of dedicated roles/personas.
Consequently, this pushes people toward messy, not-yet-baked concepts like trying to "merge" gateway's or push for TLSRoute to have termination abilities as workarounds. I struggle to explain to our teams what it really means to be merging gateways, its so abstract and removed from the original problem.
For all their flaws, Ingress + annotations were well adapted to user needs. An ingress controller might have a default TLS cert, but individual ingress objects (e.g. routes in Gateway API) could express their desired TLS termination behaviors. And it looks like early API Gateway had this right too. Infra teams operate cert provisioning infrastructure, but expressing per-route/ingress termination behaviors very much belongs on the application developer side.
Have folks at massive scale adopted Gateway API and found ways to address this challenge?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We have thousands of app developers who are able to define a Kubernetes Ingress object, along with annotates to express the TLS certificate that should be automatically provisioned and used for that ingress (e.g. pretty typical ingress-nginx + cert-manager setup). To look at Gateway API, we need some way for developers to express their hostname(s), paths that map to their service, AND certifications that should be used.
This project's decision to remove TLS configuration from individual
HTTPRoute
objects means these TLS termination details must be expressed at theGateway
level.This pushes adopters toward making lots of
Gateway
's and treating them as a developer detail (see #2665. But aGateway
is generally associated with physical infrastructure and has management / financial cost. It's in the realm of the infra provider. We run a few (public, private). It doesn't make sense for the app developer to manage Gateway's even in Gateway API's own docs, it contrasts with the original goal of dedicated roles/personas.Consequently, this pushes people toward messy, not-yet-baked concepts like trying to "merge" gateway's or push for TLSRoute to have termination abilities as workarounds. I struggle to explain to our teams what it really means to be merging gateways, its so abstract and removed from the original problem.
For all their flaws, Ingress + annotations were well adapted to user needs. An ingress controller might have a default TLS cert, but individual ingress objects (e.g. routes in Gateway API) could express their desired TLS termination behaviors. And it looks like early API Gateway had this right too. Infra teams operate cert provisioning infrastructure, but expressing per-route/ingress termination behaviors very much belongs on the application developer side.
Have folks at massive scale adopted Gateway API and found ways to address this challenge?
Related:
Beta Was this translation helpful? Give feedback.
All reactions