Contour Ingress Controller Joins CNCF at Incubation Level
The open source Contour, a high-performance ingress controller for Kubernetes that provides a control plane for the Envoy proxy, joined the Cloud Native Computing Foundation (CNCF) as an incubation level project, skipping over the traditional sandbox level entry point. The project, originally developed in 2017 at Heptio before the company’s acquisition by VMware, displayed a level of usage in the field, support in the community and activity in its ecosystem that warranted skipping the sandbox, said Michael Michael, a director of product management at VMware.
Michael noted that Contour had the added benefit of tightly integrating with other CNCF graduated projects — Kuberenetes and Envoy — and that the project was looking ahead to the future.
“Our goal here [in] being part of CNCF, is we want to be the best ingress controller for Kubernetes,” said Michael. “We want to interface with some of the other projects in CNCF, like Envoy and Kubernetes, to build an ingress controller to meet the needs of customers with a vision towards a future that Service API and the work that’s happening in the community to revolutionize how networking is attached to your different apps that you’re running in a cloud native environment.”
Contour helps to route external traffic to pods by performing two distinct tasks. First, Contour listens to the Kubernetes API for changes to pod specifications to determine traffic routing as scaling occurs, and then it also pays attention to YAML specs regarding pod specifications. Contour then takes this information and configures Envoy to determine the route traffic will take, with Envoy acting in this case as an L7 to L4 proxy.
Beyond that, the project boasts a basic set of features including the ability to be deployed as either a Kubernetes deployment or daemonset, and with support for ingress in multiteam Kubernetes clusters, as well as support for TLS certificate delegation.
Contour 1.0 was released last November during KubeCon San Diego, and Michael called the release “a signal to the community that we’re ready for primetime.”
“We’ve been kind of kicking butt since then. We’ve been having a release pretty much monthly for the last six or seven months. We’re seeing this huge community increase in terms of contributions, our roadmap, our features, so we’re loving it every step of the way. The last few months of Contour have been amazing — ever since we shipped version 1.0, you’re seeing this huge, huge increase in participation, and increase in usage,” said Michael.
Looking ahead at what’s next for Contour, the project plans to add support for Kubernetes Service APIs for routing services across Kubernetes clusters. Michael explained that, currently, Kubernetes ingress has some shortcomings — such as a lack of support for multitenant environments, for TCP and UDP, and for load balancing. The Service APIs, he said, will help identify a specification that everyone can use for ingress in Kubernetes applications.
“Think of Service APIs as the next generation of Kubernetes Ingress, said Michael. “Service API is the work that’s happening in the community, with a lot of the networking folks — including the Contour team — trying to build the next generation of ingress. It’s going to revolutionize how ingress happens in Kubernetes clusters, the same way the CSI revolutionized storage.”
The Cloud Native Computing Foundation and VMware are sponsors of The New Stack.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
