Contour 0.1: Envoy-Powered Ingress Controller Arrives

Introduction

On June 15, 2018, Heptio (later acquired by VMware) released Contour 0.1, the first version of an Envoy-powered ingress controller for Kubernetes. While NGINX Ingress dominated the landscape, Contour offered something different: Envoy’s performance and features combined with Kubernetes-native CRDs for advanced routing.

What made Contour 0.1 notable wasn’t just “another ingress controller”—it was the first to fully embrace Envoy’s xDS APIs and demonstrate that ingress could be more than simple host/path routing. Contour’s IngressRoute CRD model enabled delegation, weighted routing, and TLS management that felt native to Kubernetes.

Why Contour?

• Envoy Performance: Leverages Envoy’s battle-tested data plane for high-throughput, low-latency routing.
• CRD-Based Configuration: IngressRoute resources provide declarative, version-controlled routing rules.
• Advanced Features: Supports canary deployments, traffic mirroring, and header-based routing out of the box.
• TLS Management: Integrates with cert-manager for automatic certificate provisioning and renewal.

Core Concepts

IngressRoute CRD

Contour introduces the IngressRoute custom resource, extending Kubernetes Ingress with:

• Delegation: Root IngressRoute resources can delegate to other IngressRoute resources in different namespaces.
• Weighted Routing: Split traffic across multiple services with configurable weights.
• Header/Prefix Matching: More expressive routing rules than standard Ingress.
• TLS Configuration: Per-route TLS termination with SNI support.

Architecture

• Contour Controller: Watches Kubernetes API for IngressRoute resources and Services.
• Envoy DaemonSet: Runs Envoy proxies that receive configuration via xDS APIs.
• xDS Protocol: Contour generates Envoy configuration and pushes it via the xDS (Discovery Service) protocol.

Getting Started

Install Contour:

kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

Create an IngressRoute:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: webapp
  namespace: default
spec:
  virtualhost:
    fqdn: webapp.example.com
    tls:
      secretName: webapp-tls
  routes:
  - match: /
    services:
    - name: webapp
      port: 80

Key Features (0.1)

1. IngressRoute CRD: Declarative routing configuration with delegation support.
2. Envoy Integration: Full xDS API support for dynamic configuration updates.
3. TLS Termination: Per-route TLS with automatic SNI routing.
4. Traffic Splitting: Weighted routing across multiple backend services.
5. Header Routing: Route based on HTTP headers, not just paths.

Comparison with NGINX Ingress

Use Cases

• Multi-Tenant Clusters: Delegation allows teams to manage their own IngressRoute resources.
• Canary Deployments: Weighted routing enables gradual traffic migration.
• Header-Based Routing: Route traffic based on user agent, region, or custom headers.
• TLS Automation: Integrate with cert-manager for automatic Let’s Encrypt certificates.

Operational Considerations

• Envoy Resource Usage: Envoy’s performance comes with higher memory usage than NGINX; plan accordingly.
• CRD Learning Curve: Teams familiar with Ingress annotations need to learn IngressRoute syntax.
• Delegation Complexity: While powerful, delegation can make routing harder to trace; document ownership.
• Upgrade Path: Contour 0.1 is early software; expect API changes in future releases.

Common Patterns

• Root and Leaf Routes: Use root IngressRoute for TLS termination, delegate to leaf routes for path-based routing.
• Traffic Splitting: Gradually shift traffic from old to new service versions using weighted routing.
• Multi-Namespace: Delegate routing decisions to application teams while maintaining central TLS management.

Limitations (0.1)

• Early Software: 0.1 is an initial release; expect bugs and API changes.
• Documentation: Early documentation may be incomplete; rely on examples and community.
• Ecosystem: Fewer third-party integrations compared to NGINX Ingress.
• Ingress Compatibility: Contour supports standard Ingress resources but IngressRoute is recommended.

Looking Ahead

Contour 0.1 established the foundation for:

• Gateway API Support: Future versions would align with Kubernetes Gateway API standards.
• Performance Improvements: Continued Envoy optimizations and connection pooling.
• Policy Engine: Introduction of HTTPProxy for more advanced routing features.
• Multi-Cluster: Support for federated ingress across multiple clusters.

Summary

Contour 0.1 proved that ingress controllers didn’t have to choose between performance and Kubernetes-native configuration. By combining Envoy’s data plane with CRD-based routing, it created a foundation for advanced edge routing that would evolve into one of the leading ingress solutions for Kubernetes.