VMware Hands Control of Kubernetes Ingress Project Contour Over to CNCF
Source:-datacenterknowledge.com
Joe Beda, one of its creators, said one reason for the move was reassuring non-VMware developers that Contour’s development wouldn’t be steered by a single company.
When the Cloud Native Computing Foundation announced a couple of weeks ago that it had accepted the Kubernetes Ingress controller, Contour, as a project, its decision only made sense. After all, CNCF is already the home for both Kubernetes and Envoy, both necessary for running Contour, as well as about all other software essential to successful conatiner-based cloud-native deployments.
Contour functions as a ‘management server’ for Envoy and serves as the control plane that directs how Kubernetes’ traffic should be managed. In addition, it offers advanced routing features when compared to Kubernetes’ out-of-the-box Ingress specification. DevOps teams like it because it simplifies working with notoriously complex Kubernetes while adding functionality.
Related: What Service Meshes Are, and Why Istio Leads the Pack
“Getting Kubernetes, whether from upstream or through a distribution, is kind of like getting a Linux kernel,” Joe Beda, one of the original developers of Kubernetes and now a principle engineer at VMware, told Data Center Knowledge. “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.”
The project was originally developed in 2017 by Heptio, the Kubernetes-focused company founded by Beda and Craig McLuckie, another original developer of Kubernetes (who also now works for VMware). VMware took control of the project a year later when it acquired Heptio, and now offers it in an add-on pack for Tanzu Kubernetes Grid, the company’s core Kubernetes offering.
Related: Explaining Knative, the Project to Liberate Serverless from Cloud Giants
Beda told us that part of the reason for contributing Contour to CNCF was to reassure developers outside VMware that the project would be developed under an open governance model instead of being under the control of a single entity. This is especially important since Google created something of a brouhaha among open source developers in October, when it announced it was keeping two of its Kubernetes-focused open source projects, Istio and Knative, under its control after having previously promised to move them to a foundation with an open governance model.
“We want to be able to grow the community,” Beda said. “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.”
He added that although all CNCF projects are independent, he expects the move will also help developers with both Kubernetes and Contour going forward.
“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,” he said. “And having Contour adopting and helping to shape new features is good for the contour project.”
Because Countour is a mature project with a high amount of use and a strong developer community, it joins CNCF as an incubation level project instead of entering at the more traditional sandbox level.