Replies: 7 comments 33 replies
-
|
Personally, I don't think the adoption friction is the Gateway API itself but rather the market forces of:
#3384 covers 2) so I'll focus on 1). If I were a betting man, I'd wager that the vast majority of the Ingress API (today and historically) comes from ingress-nginx and not by a narrow margin. In fact, right before Gateway API took off, the ecosystem was coalescing around controller-specific CRDs because of Ingress's limitations. Therefore, my conclusion is that Ingress's adoption has nothing to do with UX but rather the absence of needing to choose an implementation. To be blunt: I suspect that Gateway API's adoption will always be somewhat capped because ingress-nginx (not the Ingress API) provides a Kubernetes org-blessed option that no one will get fired for picking. Apologies for the tangent, but TLDR - if the end goal is to increase Gateway API adoption, then this discussion is asking the wrong question IMO |
Beta Was this translation helpful? Give feedback.
-
|
I think the community is divided on this @aojea. I would characterize my own take on this as "we should aim to absorb as many |
Beta Was this translation helpful? Give feedback.
-
exactly my question, how many of those users not need new features and just current Ingress works ... |
Beta Was this translation helpful? Give feedback.
-
|
For many people, current Ingress "works" with a bunch of annotations. The amount of use cases that base Ingress is useful for is not that big. However, I think the GA API guarantees make it clear that base Ingress will be around approximately forever, but if you want more complicated things that require annotations on Ingress, you should really be looking to move to Gateway API. The annotations are the key. |
Beta Was this translation helpful? Give feedback.
-
|
Should we be encouraging to gateway implementations about supporting Ingress then? Because if users do indeed need just a simple api without any of bells and whistles, there shouldn't be much holding us back from a healthier ingress implementation ecosystem |
Beta Was this translation helpful? Give feedback.
-
|
thanks for raising this point @keithmattix. |
Beta Was this translation helpful? Give feedback.
-
I don't think this would have a direct impact on most end-user adoption by proprietary app developers or platform teams (for whom the persona model can be an improvement over a tightly-controlled monolithic ingress - I have not heard distributed app-specific bundled Ingress as a common pattern for these larger organizations). I do think this could be beneficial for open source project owners responsible for bundling and publishing their projects with supplemental resources such as Helm charts who would prefer to minimize additional friction in an onboarding/quick-start setup. |
Beta Was this translation helpful? Give feedback.
-
|
Since one of the main Gateway API differentiators from Ingress is the isolation of concerns between the involved personas, the concept of making the app developer completely unaware of the underlying infrastructure resonates a lot with me. This is what we state in the description of Ana, the app developer, in our documentation:
Since from Ana's point of view Gateway API is pure friction, I do totally agree that we should do as much as we can to reduce that friction as much as possible, and removing the NEED to set Gateway references from the routes, looks a good step forward to me. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, okay, that makes sense and would work okay - because if there's no Gateway, then there's no relationship, and the Route won't be accepted by any implementation. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, exactly. The greater impact given by this proposal is that it'll be no longer possible to have HTTPRoute without ParentRefs. I was pretty sure that ParentRefs is a mandatory field, but it turned out to be an optional one: gateway-api/apis/v1/shared_types.go Lines 220 to 226 in 8285041 |
Beta Was this translation helpful? Give feedback.
-
|
Oh, interesting, I didn't realize we had that set as optional. In the end, I guess it doesn't matter, because if there's no chain of ownership, then it won't be picked up for processing anyway. Note that this does mean that setting a default will need to be done at the parent layer (set a default for the |
Beta Was this translation helpful? Give feedback.
-
|
So essentially what's being proposed is a semantic for a default gateway that exists in the same namespace as the route. That feels fine if, as @mlavacca points out above, we make parentRef mandatory (not sure why it isn't already?). My only concern is whether we'll be having this same conversation in 3 years because users want to have the default gateway live in a different namespace than the route (or some other feature) and we find ourselves trying to make things "easier" again. |
Beta Was this translation helpful? Give feedback.
-
|
I think the goal of this discussion is to understand whether we want to make life easier for potential new users who can get hit by the complexity of Gateway API. My point of view is that no step in that direction has to be precluded a priori. I'd love to discuss all the possible improvements of the API without prejudice, not only feature-wise but UX-wise as well. In case we get to the point when we discuss making users' lives easier when referencing Gateways in different namespaces, I'll be happy to have that discussion, and in case we'll be able to find a solution that makes sense and does not undermine the API design and integrity, well, that's a win to me :) Of course, API principles integrity is paramount, but let's not shy away from exploring potential improvements and evaluating them individually. |
Beta Was this translation helpful? Give feedback.
-
|
It's nice to see this discussion happening and getting engagement. Overall I think @mlavacca is on to something promising: his proposal seems to do a nice job of using the existing machinery and preserving existing semantics, while also giving Ana a helpful default that lets her focus on her business needs rather than forcing her to think about infrastructure. That said, @youngnick has done his usual (depressingly 🙂) good job of pointing out pitfalls. True to form, I shall try to tease these apart by talking about, you guessed it, use cases! 😂
|
Beta Was this translation helpful? Give feedback.
-
|
There are a couple of really interesting things in here that, again, I'd kind of like to separate. @youngnick writes:
This is actually fascinating to me, because I view The To @keithmattix's point about languages, C definitely had a refreshing lack of spooky action at a distance. 🙂 And it had a slew of segfaults, buffer overruns, etc., right? Moving into a world where the developer didn't have to explicitly always type out everything to do with memory absolutely improved the world, even though you can likely still find C veterans who think that Go's garbage collector is too much magic for them to be fully comfortable with. Ultimately, the evolution of languages tends to show that requiring developers to take on the burden of explicitly stating everything pushes them away from using the thing that requires that. I'd like us not to do that here. I also think it's worth noting that defining default semantics is easier on developers in practice than defining default values that show up when you read the resource back: having default values appear on readback makes a lot of CD tools very unhappy (so, for example, right now, AFAIK any developer using ArgoCD must include the |
Beta Was this translation helpful? Give feedback.
-
This resonates very strongly with me, and I think fits very well with the original spirit of the post. I wouldn't say that we've quite managed to build strong consensus on the principle yet, and this comment to me is a helpful highlight on what that principle is. |
Beta Was this translation helpful? Give feedback.
-
|
I'm somewhat persuaded by that idea @kflynn and @shaneutt. I do feel like there's a balancing corollary to that principle though that I can't quite put my finger on, but it goes something like allowing developers to not specify enough (for some value of enough) will push away all other personas down the line. There's a harmony between those two principles that we need to aim for and I think @mlavacca's proposal does seem to be a good step in that direction |
Beta Was this translation helpful? Give feedback.
-
|
@keithmattix I might phrase that concern as "ease of use is important, but magic isn't supportable". You're absolutely right about the balancing act required to get it right -- computing really isn't a field where we often have the luxury of unambiguously correct answers. 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
To be clear, I'm fine with @mlavacca's proposed option above to add a default I hadn't looked into the actual files for a while, and had forgotten where we are at:
To implement @mlavacca's idea, we can specify the default for the This would mean:
The net effect here seems to me to be:
It won't solve the problem of "I want my app to be installed and just work", because someone still needs to provision the Gateway, or edit the added HTTPRoute. So in short, I think that adding a default will help, but it won't solve the problem. I'd definitely like to speak to the Helm developers about options for conventional, standard fields to set a default To be honest, the way I always anticipated this working is that Ian or Chihiro would say "You have |
Beta Was this translation helpful? Give feedback.
-
|
Also, to @youngnick's point about conflict resolution -- the conflict resolution semantics are a huge help, definitely! In practice, you can still do some pretty nasty stompage by applying a route that's more specific, rather than identical. The updated Gateway API workshop for Salt Lake actually shows this: we have a canary GRPCRoute with no To be clear, I think of this as a feature: it makes a lot of things much simpler than they'd otherwise be! It's probably also an area where having something to show the routing table could be a great addition. |
Beta Was this translation helpful? Give feedback.
-
|
Hi all, I tried to catch up a bit, but I am sure I missed a lot of the details. I want to call out what looks to be an assumption that some folks are embedding in their headspace. For some implementations, like nginx, an Ingress object means "attach these routes to THE loadbalancer". But there are other implementations, particularly the clouds, where an Ingress object means "create a new loadbalancer", and those are not subject to the same sorts of attacks. Part of the idea that "Ingress is easier" is that I only have one resource to specify and it's mine and I don't need to worry about other people. For those users, like many Cloud users, Gateway is almost purely friction beyond Ingress. Baby. Bathwater. I know that gateway is primarily aimed at the more sophisticated users, for whom the gateway and the route are managed by different personas, but what we have ended up with makes it almost a non-starter for those smaller users. So what do we think are the proportional sizes of those cohorts? I would hazard a semi-informed guess that 80% or 90% of users have the simple problem. There's an old joke about "making impossible things possible, and easy things hard", which I think applies here. There is, at least hypothetically, and intermediate mode of Ingress. Let's call it "virtual private". I want the simplicity of ingress, with a single resource and everything specified together in one place, but instead of attaching my routes to a single load balancer (with the route stomping problems) or creating me a private load balancer for every single Ingress (with the cost problems), create a "per tenant" loadbalancer. I don't define what "tenant" means, but namespace is often a good approximation. Now, I don't have the route stomping problem, and the cost is managed, though not eliminated. As an app developer, this should happen without me doing anything particular. In fact, I don't even really need to know what the implementation is doing. There might be a single l4 load balancer routing to nginx, or there might be an l4 load balancer for each Ingress, or there might be an l4 load balancer for each namespace. Don't know, don't care. The idea of a "default" gateway, discussed in this thread, is getting toward the same thing, though still using two resources. Can we get that down to 1? What if that one is just a wrapper that automates the creation of the others? |
Beta Was this translation helpful? Give feedback.
-
👏 I appreciate you saying these things, I strongly agree and I'm super glad we're continuing this conversation.
I think "default Gateway" could potentially do some significant reduction of friction. We recently merged a PR which adds ListenerSet as an experimental API. It wouldn't have the same effect as "1 resource", but particularly for clusters where there is one well-known Gateway (reminiscent of how a lot of clusters over the years have worked with classic ingress controllers) which are still very common, having a "default Gateway" by way of "default listeners" across namespaces could help reduce friction as at least in some cases it would be effectively "1 resource" for certain users under certain conditions. However, the "1 resource" mode would be ideal and was my original hope with this discussion: Something that could compose into all our other resources. I am still very much in favor of exploring this further and seeing what we can come up with. I think it's perhaps quite easy in the in-cluster-only case, and maybe we could start exploring there. We just need to make sure we're looking at |
Beta Was this translation helpful? Give feedback.
-
|
I'm fine with a 1-object-that's-decomposed-into-Gateway-API approach, as long as that 1 object has restrictive default behaviors that make it hard for users to end up with the problems that Ingress ended up with (especially that Ian and Chihiro had no way to either know or control, if they wanted to, what Ana was doing). It's pretty important to remember that the people who need that control really, really need it. I'm fine with thinking about how we can head back towards a 1-resource solution, but I'm telling you now, it will need to be a very simple solution, and we will need to commit to keeping it that way, and having a complexity ceiling above which we say "and here's where you switch to the full version". So here's my non-negotiable-if-I-am-involved set of requirements for a 1-record solution:
|
Beta Was this translation helpful? Give feedback.
-
|
On Slack I mentioned to @robscott, @youngnick, and @mlavacca a proposal that is a variation of @mlavacca's proposal for default Gateways. I vaguely feel like we discussed this before at a previous Kubecon, but I didn't see it represented here so I figured I would post it for discussion: The proposal is for Gateway API to provide an optional API hook (it seems like https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/ is potentially a great option, albeit its early) that identifies the default infrastructure and automatically applies defaults to There are interesting problems with this, like how much heavier the effects of deleting a "default implementation" on a cluster can be, and "what happens if you change the default", but I think they're solvable. I think it would be pretty quick to POC somewhere like Kind and test it out. |
Beta Was this translation helpful? Give feedback.
-
|
https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/ is perfect for this use case -- orders of magnitude less operational complexity for use cases like this. Only downside is it is alpha. |
Beta Was this translation helpful? Give feedback.
-
In the post-1.2 world we've been thinking a lot about Gateway API User Experience (UX) and how we can improve that specifically for developers.
As a developer with Ingress you would package your
Deploymentwhich let people know how it was run on Kubernetes, and then packaged yourIngressto describe how it does traffic. This way does not require developers to think much about the infrastructure (e.g. theGateway). The parentRef relationship with Gateways inHTTPRouteis more complicated.The question here is: whether we could significantly improve user experience if we had some mechanism in place such that the developers who publish
*Routeswith their applications did not have to bother with parentRefs.How that ends up looking doesn't concern me nearly as much as whether other people feel similarly. Please let us know: does this resonate with you? Do you think having the "simple ingress experience" more clearly paralleled in Gateway API would significantly increase adoption?
Beta Was this translation helpful? Give feedback.
All reactions