In fact, we often consider the function expansion of API gateway for our PaaS platform. Recently, I start to look into the API gateway products. In this blog, I will briefly introduce the function and give some considerations for the future development. I hope to be able to attract more ideas. I would like readers to share their prospects for API gateways.
The current API gateways in our PaaS system are
Istio Inagress Gateway and
Kubernetes Community Ingress.
There are a few additional functions for these two implements, and we just use them to expose the interface.
We only use the grayscale and traffic forwarding, and the authentication and rate limit do not rely on them at all.
The Ingress NGINX Controller we use is created by Kubernetes Community which based on OpenResty.
Due to some reasons, we need to use Istio Ingress Gateway. It works just like Ingress, but need to use Gateway and VirtualService to configure.
# An ingress Gateway describes a load balancer operating at the edge of the mesh that receives incoming HTTP/TCP connections
Well, An API gateway could not just expose the service, but also have the ability to control the traffic, including authentication, rate limit, and so on. A good gateway also need to allow user add their own plugins.
Kong use OpenResty as its backend, and it has a plugin system. also support Python, Golang plugins.
I appreciate its interactive logic, when you have multiple domains, each domain can set its own enabled plugins and their configuration. It is a mature commercial product, so the usability is still very strong, but unfortunately it does not support Wasm yet.
Istio use Envoy as it’s backend, and support wasm plugins.
Currently, you can’t add a plugin for a single
VirtualService, and it only supports the IngressGateway selector. If you want many plugins, its logic is controlled by
proiority, the interaction is very complex.
I have done some brief research on several possible solutions. It’s possible to have implementation strategies for all the solutions I posted here.
In terms of interaction logic and usability alone, I don’t think there’s much to optimize, the only thing I find difficult is the inability to use Wasm type plugins.
A few methods:
- Just like Kong’s Golang or Python plugin use rpc to call wasm plugin
- Use Lua to implement a wasm vm, run Wasm code directly
- Wasm embed into OpenResty, here is a solution: https://github.com/api7/wasm-nginx-module
IMHO, I assume this is the latter two that the Kong team will consider. I have used the Python plugin, it seems a little hard to use and introduce some maintenance issues. The latter two are more easy to maintain and may have better performance.
If we want to use Istio as an API gateway, we need to use VirtualService to configure the route rules. Use annotations to configure the plugins like Kong is enough.
Why we want lua The plugin environment in kong is Almost all Lua plugins are certified for enterprise level, and if they can be used directly in Istio+Envoy, I believe many users will be willing to use Envoy as a gateway.
There are two methods to support Lua plugin:
Convert Lua to wasm, according to the information I have gathered, there is no ready-made compiler, you need to write it from scratch
Recently, there is a project named
ridercreated by Netease team that supports running Lua code in Envoy. It means we can emulate the Kong’s PDK to use its plugins
In my blog, there are many articles about PaaS systems and I’m currently maintaining a PaaS system. I will give a solution from a PaaS user’s point of view. The two above solutions need us to update the ingress controller and the istio. What’s worse, we need to write some code to support the new features. A simple project could wait for the solution, but we can’t, we need to meet the user’s factual needs.
If we want to have a functional API gateway for every apps. The good solution is to add our own sidecar like Istio, but only for the the API traffic.
This sidecar could import user config with kind of
Wasm, and these configs could be placed in the git repo.
And consider this method:
- Performance, sidecar with pod easy to exntend and theoretically it has the same performance as Istio’s
- Extensibility, we gave the power for use to controll their traffic more precisely.
The technology itself is not good or bad, only suitable or unsuitable.
For PaaS platform, scalability and simple interaction logic are important. There are thoundouds of apps in our PaaS system with kinds of demands. We cannot hope to extend the platform functionality by using Istio’s description files exclusively, but always provide a solution that works.
For my personal view, when I use K8s to hold a few small projects, I would like to have some functionality plugged in. I’m interested in Wasm plugin support.
In my spare time, I would consider improving Istio’s controller with a better interaction logic.
I’d like the reader consider this article as a research report about the API gateway. I hope you could share some ideas and thoughts with me.