With the release of Envoy Gateway 0.2, you may be wondering what’s happening in this part of the ecosystem, where things are headed, or maybe just wondering what Envoy Gateway (EG) even is. In this post, Tetrate’s Matt Turner explores all this and more.
How do network requests get into your Kubernetes cluster from the outside? Chances are you’re using an ingress controller: a set of HTTP reverse proxies that transit traffic into the cluster, and an operator that controls them. You might be using something like Ambassador or Contour, Traefik or HAproxy. You might be using your cloud provider’s solution, or just the “default” Nginx Ingress. Or you might be using a more full-featured “API Gateway” (of which more later) like Tyk or Kong, or have a separate gateway in another layer in front of your Kubernetes ingress, like AWS’s API Gateway, or an on-prem F5. Suffice to say, there are many options to choose from.
Why We Need a New Ingress Controller
As you might have experienced, a lot of these options are limited in various ways. Many of them are based on older technologies, like Nginx, HAproxy, or even Apache. Those have properties that are undesirable in a cloud-native environment, like dropping in-flight connections on config changes (Ambassador published a comparison if you want to dive in). Cloud providers’ offerings do tend to be based on more modern gubbins (like their magic SDNs), but the flip side is that they can lock you in. How? Currently you specify the configuration for all the different options with just one K8s API: Ingress. This resource is very much a lowest-common-denominator, so almost any setting you want to configure requires an operator-specific annotation, rather than being a first-class field.
There’s also just a lot of them, so choosing the right one can be tricky. Even the de facto standard, nginx-ingress, is one of at least two controllers based on nginx, and not even the official one!
Envoy Gateway: the Foundation for Future Gateway Development
To add to the choices, and perhaps the confusion, there’s a new controller in town: Envoy Gateway, or EG. As the name suggests, this is a gateway (ingress controller) based on the Envoy proxy. It’s a community project, hosted under the Envoy GitHub organization. It’s not the first Envoy-based ingress; the popular Contour and Ambassador projects, and more, are already built on Envoy. But the developers of those projects and more are coming together to contribute to EG, and both Ambassador and Contour have said they’ll rebase onto the Envoy Gateway code in due time. (That said, we at Tetrate are undeniably proud of our leadership role in this project).
Envoy itself is battle-tested as an ingress proxy, sidecar proxy, and is lined up to replace Google’s GFE.
Show Me the Code!
If you’d like to get hands-on before reading more, I’ve written a sister post to this one with detailed instructions to set up EG yourself, or if that’s not practical, I’ve included all the commands’ output from my machine so you can see what would happen.
A Gateway to APIs
Envoy Gateway in its simplest form—the system you may just have set up—dutifully forwards requests into its cluster. It routes them based on their HTTP host and path, and it can also do so based on other headers. Every cluster needs this, and it’s great to see that Envoy Gateway can already do this just six months into development. (To learn more about Envoy Gateway, see Gateway to a New Frontier.)
Advanced Features Beyond Basic Ingress
However, many organizations need a lot more than this basic, albeit Layer 7, routing. Needing things like a WAF, schema validation of bodies, bot-blocking, and more, many people reach for an API Gateway. We see a lot of organizations deploy a separate API Gateway in front of their ingress controller. However an API Gateway can replace the ingress controller, as it can also do the “basic” functions of routing and traffic observability. They can offer these features because they’re built from the same proxies as are ingress controllers, e.g. Kong is based on nginx. API Gateway products are slickly marketed, but if you really think about what an API Gateway is, it’s an HTTP proxy with a set of additional capabilities (the WAF, etc that I mentioned before). That’s not to say they don’t add any value – the features they offer are myriad and powerful – but there’s a common baseline of features, and common code that implements it.
Dynamic Extensibility with Wasm
Thus, Envoy Gateway is perfectly positioned to evolve into a full-featured API Gateway. Envoy actually already sports some of the more advanced features, including JWT validation, OIDC auth flows, and rate limiting. Plus Envoy is dynamically extensible; it can have plugins loaded without restarting, meaning more features can easily be added on demand. Those plugins are provided as WASM bytecode, meaning they can be written in any language that compiles to WASM (Tiny Go, Rust, et al.), rather than just the scripting languages supported by other proxies. The community is starting to write these plugins: caching will probably be first to land, and the Coraza project is a relatively mature mod_security-style WAF, written in Go, which can compile to WASM and be used in Envoy proxies today.
Gateway API Encourages Extension
The other big barrier to extension and competition in the ingress controller market was the API. Vendor-specific annotations (or entirely new vendor-specific APIs) were needed, which were clunky and prevented cross-compatibility. By contrast, Envoy Gateway is configured by Gateway API, a set of resources in the gateway.networking.k8s.io API group. This could be the subject of its own blog, but the short version is that this API will eventually replace the Ingress resource. Its core is already much more flexible and expressive than Ingress, and it’s designed to grow and be extensible in a manageable way. This will allow it to evolve into a first-class model of all north-south traffic control, from basic routing to advanced API management features. This in turn will expose all the features that Envoy Gateway has, in a standard, vendor-agnostic way, letting people use them without jumping through hoops or worrying about lock in. EG hopes to support these new parts of the Gateway API in its 0.3 release in March 2023.
A Common, Best-of-Breed Base for Future Gateway Development
Envoy Gateway is motivated by this increasing focus up the stack at API gateway features: “basic” ingress is becoming commoditised, so the community is pooling its resources and expertise to create a common, best-of-breed base for future gateway development. The contemporaneous availability of the new Gateway API for it to implement was very convenient, and the 0.2 release of EG marks the availability of full support for the currently-defined Gateway API core types.
The work to expand that to model advanced use-cases has already begun, with JWT auth config being designed now and others to follow. Work has also started on the plugins themselves (e.g., Coraza, a Golang WAF taking after the ubiquitous mod_security). While these both have a long way to go, I’m personally very excited to see where this all goes in the next year or two.
A Gateway to Service Meshes
You may be thinking that there’s already a class of products that support features like OIDC authentication and rate limiting: service meshes. This is true; the most prominent mesh, Istio, deploys a set of proxies for ingress in its default configuration. Istio now supports the Gateway API (just like EG does) to configure that ingress. We at Tetrate are excited by this convergence: organizations can now adopt Envoy Gateway to get going simply and quickly. Envoy Gateway does a fine job of managing this north-south traffic, and running it will teach them the performance and operational characteristics of Envoy in production. When those organizations are ready to take control of their service-to-service, aka east-west traffic, they can deploy Istio, already familiar with the main underlying component (Envoy). While they’ll probably choose to use Istio ingress gateway (to keep their control-plane count down to one), their existing Gateway API resources will continue to work. Being based on Envoy as well, Istio’s ingress can also take any API-Gateway-style plugins that had been loaded into EG. All of which should make for a very easy path to adding the power of a service mesh when it becomes necessary.
A Unified Gateway API for Both Ingress and Service Mesh
What’s more, a working group has been set up to coordinate the overlap between gateways and meshes: the GAMMA Initiative. GAMMA stands for Gateway API for Mesh Management and Administration, which is an insight into the direction the Gateway API is going to take; the plan is for it to start modeling service mesh concerns, i.e., east-west traffic, too. GAMMA will make sure that EG and meshes work well together, and will focus on Gateway API unifying to cover both ingress and mesh. We’re excited about how this will unlock easy and gradual mesh adoption for many organizations, based on a product-agnostic API, which is good for all.
Wrapping Up
Hopefully this post has been a useful tour of the current ingress landscape, and a good introduction to the new standard API, Gateway API, and the reference implementation, Envoy Gateway.
If you want to follow the development of EG you can can join the #gateway channel in the Envoy slack, and check out the commits and issues at https://github.com/envoyproxy/gateway. The project has a roadmap for the next couple of releases, with v0.3.0 aiming for March 2023.
If you want to take Envoy Gateway for a test drive, I’ve written a companion tutorial with step-by-step instructions for getting it up and running.
###
If you’re getting started with Istio and Envoy, check out Tetrate Academywhere you’ll find a ton of free courses, on-demand workshops, as well as Tetrate’s Certified Istio Administrator exam.
For the easiest way to install, manage, and upgrade Istio, check out our open source Tetrate Istio Distro (TID). TID is a vetted, upstream distribution of Istio—a hardened image of Istio with continued support that is simpler to install, manage, and upgrade.
