More proxy/routing flexibility #IntoTheLua

Feature Suggestions
1

As mentioned here:

I would like to see the Kong experts try their hand at giving community/enterprise users more flexibility around how to proxy/route to destinations. Right now when it comes to gateway proxying we are tied to nginx directives(proxy_pass /upstreams) exclusively and can’t get customized with it without writing something from the ground up as either a plugin or an overwrite to core Kong logic.

I propose a Kong homegrown and improved fork of GitHub - ledgetech/lua-resty-http: Lua HTTP client cosocket driver for OpenResty / ngx_lua. as a different lua driven lib for proxying to give us that lower level control and potential perf benefits. I feel certain it would also help in situations like this we face:

Where I need access to low level options around active connection pooling
"
the pool option on the underlying TCP socket connect call

"
to create keepalive connections on a per hostname basis(which in our case will solve ephemeral port exhaustion issues and other problems we see because right now we can use no keepalive) or some other customized logic that would be trivial to bake in if Kong already had the framework for leveraging a flavor of the opensource lua http libs out there production ready.

I have not studied it too much but I am also curious if there will be other found perf benefits to doing so as well(better throughput results, lower latency etc).

As discussed such would be a big change if Kong just sprung it on people over some major version release but I would propose we have a new config option that lets us pick experimental proxying that would allow people to test newer patterns but to be able to quickly toggle back to the old faithful patterns if they prove problematic for folks. KONG_PROXY_TYPE = proxy_pass, kong_proxy or something for an in house feel. Then if results are positive and everything goes smoothly in later iterations you default from say proxy_pass to kong_proxy . Ofc the first trick is figuring out how to integrate the other libs and how to configure its settings to behave closely inline with what proxy_pass offers in its current configuration.

But ultimately I see it as a big plus because then nothing stands in the way of tweaking the low level connection behaviors between Kong and APIs. My other concerns would be a few potential issues around how websocket connections would work if that other lib was leveraged(or would we lose that feature of nginx if we used something besides proxy_pass, or can that http lib support a websocket call too, I am not exactly sure). One of those kinda features I would love to help test/benchmark compare to help determine if its worth pursuing but if I were to try to implement I would probably do wrong :laughing: .

I do plan on writing a crappy plugin just to give it a go and short circuit the transaction before proxy_pass in the access phase and see how that works at just a basic level in a month or two as I get some free time for it.

2 Likes