Contour 0.7 aims at easing traffic control in the container world

Heptio Contour

Heptio’s engineering team has released v0.7 of its Ingress controller Contour into the wild, which should make handling cloud native traffic easier and reduce bandwidth, amongst other things.

For those new to the wonderful world of containerisation, Ingress is the name of a resource in Kubernetes. It consists of rules and configurations for routing external HTTP and HTTPS traffic to internal services. Ingress controllers come from different organisations and projects, NGINX to name a popular example, and are described as daemons that are deployed in Kubernetes pods and watch the endpoint of an API server associated with Ingress for updates of said resource. Contour differs from alternative offerings by using the Envoy project as a reverse proxy and load balancer for example.

The new version of the controller supports the annotation ingress.class, which can be used to separate traffic – production from development for example – by specifying where in a cluster incoming traffic should go. It also lets its users rewrite the prefix of a path, which gives them a way to route application URLs at a different path than the one exposed at the reverse proxy layer. This might interest ops working with legacy applications for example.

Contour 0.7 comes with enabled Gzip compression for all responses, which should reduce bandwidth and therefore speed up load times. HTTP requests are now timestamped with a special header, so that New Relic and datadog users have a way of timing the end-to-end latency of requests. Speaking of which, the controller is now also able to work with TLS/1.3 and HTTP/1.0 requests.


Ops wanting to upgrade to Contour 0.7 will have to update their Envoy version as well, since the new release only works with v1.7. This is due to a change in the xDS wire format of Contour.

The current release is the first since the company introduced an altered architecture to the project. Back in September Heptio put out a version which added a form of abstraction to the layer that once was responsible for translating Kubernetes objects into their Envoy equivalents. Newer versions use objects describing web app deployment to generate a directed acyclic graph. Therefore Contour isn’t tied to the data models of Kubernetes and the Envoy edge and service proxy anymore and open to alternative ways of describing deployment.

In future versions, Heptio plans to find ways for Contour to update the status section of an Ingress object, which might become an issue if multiple Ingress controllers are used within a cluster. Other items on the to do list include the expansion of the IngressRoute specification shipped with Contour 0.6 and measures to stay up to date with upgrades to Envoy, the envoy-data-plane, and the RPC framework gRPC.

- Advertisement -