Introducing Contour: Routing Traffic to Applications in Kubernetes

This article is based on an announcement originally published on thenewstack.io, written by Nick Young, Staff Engineer at VMware and Contour Technical Lead.

What Is Contour?

Contour is an open-source Kubernetes ingress controller that routes external traffic to applications running inside a cluster. It is simple to deploy, highly scalable, and purpose-built for the single task of ingress — without the complexity of a full service mesh.

Under the hood, Contour deploys Envoy as a reverse proxy and load balancer, and communicates with it using the Envoy xDS API for fully dynamic configuration updates. This means you can change routing rules without restarting the proxy — a critical capability in production environments.

CNCF Incubation: A Significant Milestone

Originally created in late 2017 by engineers at Heptio, Contour reached version 1.0 in late 2019. By the time of this announcement, it had grown to a community of 600+ Slack members, 300+ contributors, 90+ committers, and five maintainers. Production adopters included enterprises such as Adobe, Kinvolk, Kintone, PhishLabs, and Replicated.

Based on that proven production usage and community maturity, the Cloud Native Computing Foundation (CNCF) accepted Contour directly as an incubating project, bypassing the sandbox stage. Incubation status signals that a project has demonstrated sustainable governance, a healthy contributor base, and alignment with the broader cloud-native ecosystem.

For users and organizations evaluating Contour, CNCF incubation provides an important assurance: the project operates under vendor-neutral governance, meaning no single company controls its roadmap. Any contributor can help shape the project’s direction.

Why Contour? A Focused Approach to Kubernetes Ingress

Kubernetes offers many ways to handle ingress traffic, including service meshes such as Istio or Linkerd. However, deploying a service mesh to solve a pure ingress problem introduces significant operational overhead — additional control plane components, sidecars on every pod, and a steep learning curve.

Contour’s design philosophy is deliberate narrowness: do one thing and do it well. Key capabilities include:

• Dynamic configuration updates: Route changes propagate to Envoy without downtime or restarts.
• Multi-team cluster support: Designed with multitenancy in mind, enabling different teams to manage their own ingress rules safely within a shared cluster.
• Advanced load balancing: Leverages Envoy’s rich set of load balancing algorithms and health-checking strategies.
• Security-first design: TLS termination, certificate management integration, and isolation between tenants are first-class concerns.
• Service mesh compatible: Contour can operate alongside a service mesh if your architecture requires it, but does not require one.

This focused scope makes Contour an approachable on-ramp for teams that need reliable ingress today and want room to grow into more sophisticated routing patterns over time.

How Contour Works

Contour introduces a custom resource called HTTPProxy (formerly IngressRoute), which extends the standard Kubernetes Ingress object with richer capabilities — including delegation of routing authority between namespaces, which is critical for safe multi-team deployments.

The architecture has two main components:

1. Contour (control plane): Watches Kubernetes API objects (Ingress, HTTPProxy, Services, Endpoints) and translates them into Envoy configuration via the xDS gRPC API.
2. Envoy (data plane): Receives configuration from Contour and handles all actual traffic forwarding, TLS termination, and load balancing.

Because the control plane and data plane are separated, each can be scaled and updated independently, improving resilience.

Roadmap Highlights

At the time of the CNCF incubation announcement, the Contour team outlined several near-term priorities driven by community demand:

• External authentication support: A long-requested feature allowing Contour to integrate with external identity and access management systems.
• Expanded Envoy configurability: Exposing more of Envoy’s configuration surface through Contour’s API objects.
• Rate limiting support: Protecting upstream services from traffic spikes and abuse.
• Official Helm chart: Simplifying installation and upgrades via Helm.
• UDP support exploration: Extending Contour beyond HTTP Layer 7 to support protocols like VoIP and telco applications that rely on UDP.

The team also expressed intent to contribute learnings from Contour back to the broader Kubernetes community — particularly around the next generation of Kubernetes Gateway API, which aims to standardize and extend how traffic routing is expressed across the ecosystem.

Getting Started with Contour

Contour can be deployed to any Kubernetes cluster. The quickest path is using the official manifests or Helm chart (see the project’s documentation for current instructions). A minimal deployment provisions an Envoy DaemonSet or Deployment and the Contour control plane, exposed via a Kubernetes LoadBalancer service.

Once running, you define routing rules using the standard Ingress resource or the more powerful HTTPProxy custom resource. For example, a basic HTTPProxy routing all traffic for example.com to a backend service looks like this:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: example-proxy
  namespace: default
spec:
  virtualhost:
    fqdn: example.com
  routes:
    - conditions:
        - prefix: /
      services:
        - name: my-service
          port: 80

Community and Contributing

The Contour project maintains several channels for community engagement:

• Slack: The #contour channel in the Kubernetes Slack workspace is the primary real-time discussion forum.
• Weekly community meetings: Held on Tuesdays and recorded for those who cannot attend live.
• Mailing list: For announcements, design discussions, and longer-form feedback.
• Office hours: Regular sessions where maintainers are available to answer questions or review pull requests in real time.
• Good First Issues: Tagged issues on GitHub for contributors new to the project.

The project follows a monthly release cadence, ensuring that bug fixes, security patches, and new features reach users regularly without long waits between versions.

For official documentation, source code, and contribution guidelines, visit the Contour project website at projectcontour.io.