Leader Election and Configuration Files with Contour v0.15

Steve Sloka
Steve Sloka
September 05, 2019

In the previous release of Contour, a split deployment model was improved to secure communication between Envoy and Contour. Now, with our latest release, Contour v0.15, leader election is available to ensure that all instances of Envoy take their configuration from a single Contour instance.

img Overview of leader election.

Leader Election

Each instance of Contour configures a connection to the Kubernetes API server in order to watch for changes to objects in the cluster. Contour is concerned with Services, Endpoints, Secrets, Ingress, and IngressRoute objects. Having multiple readers to the Kubernetes API is fine (and is implemented in many different components); however, since Contour updates the status of an IngressRoute object, multiple writers (that is, multiple instances of Contour) can cause issues when each one of them attempts to update the status. Additionally, it’s possible that each instance of Contour processes events from Kubernetes at a different time, causing different configurations to be passed to Envoy.

In leader election mode, only one Contour pod in a deployment, the leader, will open its gRPC endpoint to serve requests from Envoy. All other Contour instances will continue to watch the API server but will not serve gRPC requests. Leader election can be used to ensure that all instances of Envoy take their configuration from a single Contour instance.

Leader election is currently opt in. In future versions of Contour, we plan to make leader election mode the default.

For more information, please consult the documentation on upgrading.

Contour Configuration File

Contour has previously supported configuration options to be passed via command-line arguments to the Contour process. Changes to these parameters meant updating the deployment spec.

Here’s an example spec from a Kubernetes Deployment manifest:

 - args:
   - serve
   - --incluster
   - --enable-leader-election
   - --xds-address=
   - --xds-port=8001

Now with v0.15, a configuration file can specify configurations that apply to each Contour installation. However, per-Ingress or per-Route configuration continues to be drawn from the objects and CRDs in the Kubernetes API server.

Sample configuration file:

apiVersion: v1
kind: ConfigMap
  name: contour
  namespace: heptio-contour
  contour.yaml: |
    # should contour expect to be running inside a k8s cluster
    # incluster: true
    # path to kubeconfig (if not running inside a k8s cluster)
    # kubeconfig: /path/to/.kube/config
    # disable ingressroute permitInsecure field
    # disablePermitInsecure: false
      # minimum TLS version that Contour will negotiate
      # minimumProtocolVersion: "1.1"
    # The following config shows the defaults for the leader election.
    # leaderelection:
      # configmap-name: contour
      # configmap-namespace: leader-elect

More new features in Contour v0.15

Version 0.15 includes several fixes. It patches several CVEs related to HTTP/2 by upgrading Envoy to v1.11.1. To help with the number and frequency of configuration updates sent to Envoy, Contour now ignores unrelated Secrets and Services that are not referenced by an active Ingress or IngressRoute object.

We recommend reading the full release notes for Contour v0.15 as well as digging into the upgrade guide, which outlines some key changes to be aware of when moving from v0.14 to v0.15.

Future Plans

The Contour project is very community driven and the team would love to hear your feedback! Many features (including IngressRoute) were driven by users who needed a better way to solve their problems. We’re working hard to add features to Contour, especially in expanding how we approach routing.

If you are interested in contributing, a great place to start is to comment on one of the issues labeled with Help Wanted and work with the team on how to resolve them.

We’re immensely grateful for all the community contributions that help make Contour even better! For version v0.15, special thanks go out to:

Join the Contour Community!

  • Join the Contour Community Meetings
    • For Australia time zones:
      • Every first and third Tuesday at 6:30 PM Eastern Time / 3:30 PM Pacific Time / Wednesday at 9:30 AM Australian Eastern Time.
    • For Americas time zones:
      • Every second and fourth Tuesday at 1 PM Eastern Time / 10 AM Pacific Time
    • Join the mailing list to get an automated invitation to the meeting. This is a low-volume list that is only used for release announcements.
  • Get updates on Twitter (@projectcontour)
  • Chat with us in #contour on the Kubernetes Slack
  • Collaborate with us on GitHub
Related Content
Announcing Contour v1.13.0
Announcing Contour v1.12.0
Ready to try Contour?

Read our getting started documentation.