Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News CNCF Accepts Contour, a Kubernetes Ingress Controller, as an Incubating Project

CNCF Accepts Contour, a Kubernetes Ingress Controller, as an Incubating Project

This item in japanese

The CNCF Technical Steering Committee (TOC) announced that they have accepted Contour as an incubating project. Contour is a Kubernetes Ingress controller that uses the Envoy Layer 7 (L7) proxy as a data plane.

Contour is an Ingress controller for Kubernetes clusters to accept external traffic into the cluster. It works with Envoy by functioning as a 'management server' - in Envoy parlance - effectively working as the control plane that directs how traffic should be managed in the Envoy proxy. Contour is implemented as a Custom Resource Definition (CRD) in Kubernetes and offers advanced routing features compared to the vanilla Kubernetes Ingress specification. Other similar Ingress controllers depend on annotations to provide advanced routing features.

Contour was created at Heptio in 2017 to get around limitations [PDF file] in the standard Kubernetes Ingress specification, and became part of VMware when the latter acquired Heptio in 2018. Contour deploys Envoy as a reverse proxy and load balancer and provides dynamic configuration updates to Envoy.

To get around limitations of the vanilla Kubernetes Ingress spec - which is still in beta, the IngressRoute was created as a Custom Resource Definition (CRD) in Contour. Since then, it has been superseded by another Contour CRD called HTTPProxy. HTTProxy also happens to be in beta, but it adds additional features like TLS configuration for backend services, HTTP header filters and manipulation policies, multiple, weighted upstreams for a single path, traffic mirroring, and configurable load balancing strategies. An HTTPProxy object can include other HTTPProxies - both in the same as well as in different namespaces. The latter feature is meant to address multi-team ingress management, in which different teams are segregated by using namespaces in the same Kubernetes cluster.

Envoy was designed as a "universal data plane", and with this in mind, it provides a set of management APIs meant to be implemented by providers that can implement control plane services. These APIs enable dynamic configuration changes to Envoy. The control plane, among other things, configures the filter chain that Envoy requests pass through. Other efforts to write a control plane for Envoy are Ambassador, and Gloo.

The recommended deployment topology is to deploy Contour as a Deployment and Envoy as a DaemonSet with secure gRPC communication between them. Contour runs as an init container in "bootstrap" mode and writes a config to a temporary volume. The volume is then used by the Envoy container as "bootstrap configuration", which directs Envoy to use Contour as its management server. The management server supplies dynamic configuration at runtime using gRPC to Envoy to make routing decisions. Contour watches for changes in the Ingress, HTTPProxy (the successor to the deprecated IngressRoute), Secret, Service and Endpoint objects using the SharedInformer framework.

In the press release, Chris Aniszczyk, CTO of the Cloud Native Computing Foundation, noted that "Contour is a logical complement to Envoy and makes it easier to consume in a cloud native, multi-team environment".

Contour has been adopted by quite a few organizations and products, some of them being Kinvolk, Replicated, Adobe's Project Ethos, Kintone and PhishLabs. At the time of writing, Contour has had 50 releases so far. The 1.6.1 release of Contour supports Kubernetes versions 1.16 to 1.18 and the source code is hosted on GitHub.

Rate this Article