When you’re running services in a Kubernetes cluster, you have a lot of decisions to make and a lot of different capabilities you can choose from.
One capability everyone needs is the ability to get traffic from outside your cluster to the pods running your services inside it. This being Kubernetes and cloud native, you have choices though: How do your hosting method and CNI allow you to get traffic to those service pods?
As a maintainer of Contour, I’m a little biased, but a common way has been to use the Ingress resource and an Ingress controller. However, while the Ingress resource’s lowest- common-denominator design allows users to get started quickly, it runs into problems as you start trying to meet more advanced use cases.
That’s why the Kubernetes project has been working on the Gateway API, an expressive, extensible, role-oriented replacement for both Ingress and Service of Type Load Balancer. That’s also why the team at VMware working on Contour has been contributing to and implementing the new API. We think it’s the future of Kubernetes service networking, and luckily, we’ve found that others feel the same.
Today, we’re announcing that Contour’s VMware maintainers will be the founding members of the new Envoy Gateway project: Project Envoy’s official Service Networking solution based on Envoy and Gateway API. Read the press release here.
Envoy Gateway is a new initiative under the Envoy banner that brings together an exclusive set of popular Envoy-based Ingress providers including VMware (represented by the Contour maintainers), Tetrate (a leading Istio contributor), and Ambassador (maintainers of Emissary) to build a Kubernetes Gateway API reference implementation. This aims to repair the fragmented landscape of Envoy-based Ingress controllers by developing a single cohesive, canonical implementation to be hosted under Project Envoy.
We’re aiming to make it easier for application developers to use Envoy’s power for Ingress traffic; to make Envoy easy to use as a Kubernetes ingress controller; and to reduce existing, redundant efforts around Envoy as an API gateway.
Contour users will notice that the scope of Envoy Gateway has overlap with Contour’s, so it’s reasonable to ask if anything will change as a result of this work.
In short, not much. VMware’s Contour maintainers will refocus Gateway API development towards Envoy Gateway, and of Contour’s Gateway API support, and leave it in its current experimental state, and shift those efforts over to Envoy Gateway. Aside from that, Contour development, releases, and support will continue just as they are now.
As Envoy Gateway and the Gateway API approach parity with Contour’s existing feature set, we may ask the maintainers to review Contour’s direction. But given the large delta between what’s available in the upstream API today and what we have in Contour today, we don’t anticipate any evaluation needed for some time.
Regardless, we will also be working with Envoy Gateway on conversion tooling to help users migrate from the HTTPProxy resource to Gateway API as both Envoy Gateway and the Gateway API mature.
We see this initiative as open source at its best. Companies that would otherwise be competing against each other are now coming together to build out the pieces that we all have in common, so that everyone can benefit.
We’re very excited about the possibilities for massively accelerating Gateway API support in the Cloud Native ecosystem and are happy and honored to be asked to be part of this new initiative from Project Envoy!
To find out more about Envoy Gateway, please see the Envoy announcement blog, the repo on Github, or the #envoy-gateway channel on the Envoy Slack.
Additionally, many of the Envoy Gateway maintainers will be physically present at Kubecon EU 2022 in Valencia, so stay tuned to those channels for more details about in-person meetups.
FAQs
Does this mean that Contour won’t be released anymore?
No. The Contour project is still an independent CNCF project and has its own priorities. VMware will continue feature development on Contour, and the project won’t change its current release cadence and support policy. We’re just going to move VMware’s Gateway API development over to Envoy Gateway instead.
Doesn’t Envoy Gateway make Contour obsolete?
No, for a few reasons:
- Plenty of people are already using Contour, including our HTTPProxy CRD, and we’re committed to making HTTPProxy even better and making sure that Contour users are supported no matter what.
- HTTPProxy includes a lot of functionality that isn’t covered by the Gateway API yet (rate-limiting and auth are a couple of examples), and won’t be for some time. Even before the founding of Envoy Gateway, the goal has always been enriching the Gateway API upstream CRDs and bringing them up to parity with HTTPProxy’s feature set.
But what about at some point in the future?
We can’t see the future or know for sure how everything is going to play out.
But what the VMware Contour team is committing to is this:
- No one will be left behind. As long as users are using Contour, we’ll help maintain and support it.
- For those people who do want to move to the Gateway API and Envoy Gateway, we’ll provide tooling to help convert HTTPProxy resources to Gateway API resources.
- In the event that any of this changes, we’ll communicate with the community and give as much advance notice as possible of any changes.
- Also remember that our support policy says that all Contour versions after 1.19 will be supported for at least one year from the time of their release.
I use Contour and HTTPProxy extensively. What do I need to do?
Right now, nothing! Contour development is continuing as normal and will do so unless something changes.
If you decide at some point that you would like to move to the Gateway API, then we will ensure there’s tooling to help you migrate your config from HTTPProxy to the Gateway API, calling out any features that the Gateway API can’t support yet.
Why participate in this at all?
We see this project as open source at its best and recognition that Contour has been progressing in the right direction in its early adoption of Gateway API. The new project has support from the Envoy project’s leadership, the broad Envoy community, and CNCF, and meets customer requests for a fully supported, CNCF-owned open source infrastructure stack. Contour is already building out Gateway API support using Envoy and xDS, so combining efforts with everyone else should make it easier and faster to deliver real, workable solutions to our users. At the end of the day, it’s all about what you all can do with what we make.
This article may contain hyperlinks to non-VMware websites that are created and maintained by third parties who are solely responsible for the content on such websites
