CNCF Adds Contour Ingress Controller as Incubation Project
The Cloud Native Computing Foundation (CNCF) this week announced Contour, a high-performance ingress controller for Kubernetes clusters, has become an incubation level project.
Originally developed by Heptio, which was acquired by VMware, the Contour ingress controller is designed to make it easier to manage routing as applications access a Kubernetes cluster.
Michael Michael, maintainer of the Contour project and director of product management at VMware, says Contour differs from other ingress controllers in that it better isolates application traffic flow between applications that otherwise contend for the same bandwidth.
Contour is deployed on top of Envoy proxy server and load balancing software. It is easier to deploy than other ingress controllers because it only requires IT teams to write few scripts, he says, noting administrators can delegate access to wildcard TLS certificate more securely using Contour.
Envoy is already a graduated CNCF project so organizations that have embraced Envoy can readily adopt Contour as a control plane, Michael adds. Organizations using Contour in production environments include Adobe, Kinvolk, Kintone, PhishLabs and Replicated. Adobe has adopted Contour as its ingress controller for “Project Ethos,” a multi-tenant platform based on Kubernetes.
The Contour team also plans to enable support for Envoy features rate limiting, authentication and access log service, Michael notes. In addition, the Contour team is committing to ensure compatibility with Kubernetes Service application programming interface (APIs) and routing services that will be backed into future updates of Kubernetes.
Right now, there 329 contributors and 91 committers to Contour. Now that it is part of the CNCF, Michael expects the size of the Contour community to increase substantially.
In many regards, networking issues involving Kubernetes clusters are just starting to be addressed. Kubernetes as an open source project may have just turned 6; however, it’s clear there are still many enterprise IT issues that still need to be addressed, including improving the multi-tenant capabilities of the platform via additions such as the Kubernetes Service API and Contour.
Of course, many IT teams are just as inclined to deploy only one application per cluster, which enables them to manage as units of deployment. That approach makes it easier to manage IT infrastructure within the context of a single application use case. In fact, Michael notes that as a deployment unit clusters have become much more like cattle than pets.
Regardless of the IT strategy employed, it will not be long before IT teams are managing fleets of Kubernetes clusters across an extended enterprise network. An ingress is only one element of that overall equation; however, as the size of the application environments deployed on those Kubernetes clusters grows, many IT teams will begin to appreciate just how much of a difference having an ingress controller that scales can really make.
