This article is based on reporting originally published by Data Center Knowledge. Quotes are attributed to Joe Beda, Principal Engineer at VMware and co-creator of Kubernetes.
VMware Contributes Contour to CNCF
The Cloud Native Computing Foundation (CNCF) has accepted Contour, a Kubernetes Ingress controller originally developed by Heptio and later stewarded by VMware, as an incubation-level project. The move places Contour alongside Kubernetes and Envoy — two projects it depends on — under CNCF’s neutral governance umbrella.
Joe Beda, one of the original developers of both Kubernetes and Contour, and now a Principal Engineer at VMware, explained the rationale: contributing the project to CNCF signals to outside developers that Contour’s roadmap will not be dictated by any single vendor.
What Is Contour?
Contour is an open-source Kubernetes Ingress controller that uses Envoy as its underlying data-plane proxy. It acts as a management server and control plane for Envoy, translating Kubernetes Ingress and HTTPProxy resources into Envoy routing configuration.
Compared to the native Kubernetes Ingress specification, Contour offers:
- Advanced traffic routing — fine-grained path and header-based routing rules beyond what the standard Ingress API provides.
- HTTPProxy CRD — a custom resource that extends Ingress semantics with multi-team, namespace-scoped delegation.
- Dynamic configuration updates — Envoy’s xDS API allows configuration changes without restarting the proxy.
- TLS management — integration with cert-manager and support for client certificate validation.
Beda described how Contour fits into the broader Kubernetes ecosystem:
“Getting Kubernetes, whether from upstream or through a distribution, is kind of like getting a Linux kernel. A Linux kernel is great, but it’s like an engine without the rest of the car. Kubernetes is the same way. The core of Kubernetes is great, but you need to have a bunch of other components around it to really adapt it to the rest of your world and make it useful. Contour, from our point of view, is one of those things that really helps to take Kubernetes and make it work in a customer’s environment.”
— Joe Beda, Principal Engineer, VMware
History: From Heptio to VMware to CNCF
Contour was originally created in 2017 by Heptio, a Kubernetes-focused startup co-founded by Joe Beda and Craig McLuckie — both original co-creators of Kubernetes at Google. When VMware acquired Heptio in late 2018, it inherited the project and continued active development.
VMware subsequently incorporated Contour as an add-on component for Tanzu Kubernetes Grid, its enterprise Kubernetes distribution. Despite this commercial integration, VMware chose to donate the project to CNCF rather than keep it proprietary or under sole vendor control.
Why Neutral Governance Matters
The timing of the donation was partly influenced by industry friction around open-source governance. In October 2019, Google drew criticism when it announced it would retain control of Istio and Knative — two prominent Kubernetes-adjacent open-source projects — rather than donate them to a foundation, despite earlier expectations to the contrary. This created hesitation among contributors who feared that code and direction could be unilaterally controlled by the originating company.
Beda addressed this concern directly:
“We want to be able to grow the community. I think when something is tightly controlled by a single company, it gives other companies pause when they want to contribute. Having a neutral home means that everybody can bring their ideas and their code, and not be afraid that somebody else is going to run off with it or move it in a direction that is not in the interest of the wider community.”
— Joe Beda, Principal Engineer, VMware
A Symbiotic Relationship with Kubernetes Ingress Development
Beyond governance, Beda pointed to a practical technical benefit: having Contour inside CNCF positions it as a reference implementation for the next iteration of the Kubernetes Ingress API, which is actively being evolved by the Kubernetes Network SIG.
“As Kubernetes develops the next version of Ingress, having a sister project in the CNCF that’s looking to implement that as soon as possible is going to make both of those projects more successful, because building that next version of Ingress without having a reference implementation is a recipe for disaster. And having Contour adopting and helping to shape new features is good for the Contour project.”
— Joe Beda, Principal Engineer, VMware
This mirrors how other CNCF projects benefit from co-location: shared governance reduces duplicated effort, aligns release timelines, and encourages cross-project contributors.
Incubation Status: What It Means
CNCF operates a three-tier project maturity model: Sandbox → Incubating → Graduated. New projects typically enter at the Sandbox level. Contour was accepted directly at the Incubating level, reflecting its maturity, production adoption, and active contributor base at the time of donation.
To reach incubation status, a project must demonstrate:
- Use in production by multiple independent organizations.
- A healthy contributor community beyond the originating company.
- A clear versioning and release process.
- Adherence to CNCF’s due diligence criteria.
Key Takeaways for DevOps Teams
- Contour is now CNCF-governed, meaning roadmap decisions are made collaboratively, not unilaterally by VMware.
- It remains a viable Ingress controller for teams running Envoy-based infrastructure who need more than the baseline Kubernetes Ingress API offers.
- Its CNCF membership should increase confidence in long-term project viability and community support.
- Teams using Tanzu Kubernetes Grid will continue to see Contour supported as an integrated component.
- Contributions from non-VMware organizations are now explicitly encouraged under the new governance model.
For DevOps engineers evaluating Kubernetes Ingress solutions, Contour’s move to CNCF reduces vendor lock-in risk and aligns it more closely with the upstream Kubernetes project’s evolution.