github.com/projectcontour/contour@v1.28.2/site/content/posts/2019-09-5-contour-v015.md (about)

     1  ---
     2  title: Leader Election and Configuration Files with Contour v0.15
     3  image: /img/posts/leader-election.png
     4  excerpt: This blog post covers key features of the Contour v0.15 release including leader election and the Contour configuration file.
     5  author_name: Steve Sloka
     6  author_avatar: /img/contributors/steve-sloka.png
     7  categories: [kubernetes]
     8  # Tag should match author to drive author pages
     9  tags: ['Contour Team', 'Steve Sloka', 'release']
    10  date: 2019-09-05
    11  slug: contour-v015
    12  ---
    13  
    14  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.
    15  
    16  ![img](/img/posts/leader-election.png)
    17  *Overview of leader election.*
    18  
    19  ## Leader Election
    20  
    21  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.
    22  
    23  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.
    24  
    25  Leader election is currently opt in. In future versions of Contour, we plan to make leader election mode the default.
    26  
    27  For more information, please consult the [documentation on upgrading][1].
    28  
    29  ## Contour Configuration File
    30  
    31  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. 
    32  
    33  Here’s an example spec from a Kubernetes Deployment manifest:
    34  
    35  ```yaml
    36  containers:
    37   - args:
    38     - serve
    39     - --incluster
    40     - --enable-leader-election
    41     - --xds-address=0.0.0.0
    42     - --xds-port=8001
    43  ```
    44  
    45  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.
    46  
    47  Sample configuration file:
    48  
    49  ```
    50  apiVersion: v1
    51  kind: ConfigMap
    52  metadata:
    53    name: contour
    54    namespace: heptio-contour
    55  data:
    56    contour.yaml: |
    57      # should contour expect to be running inside a k8s cluster
    58      # incluster: true
    59      #
    60      # path to kubeconfig (if not running inside a k8s cluster)
    61      # kubeconfig: /path/to/.kube/config
    62      #
    63      # disable ingressroute permitInsecure field
    64      # disablePermitInsecure: false
    65      tls:
    66        # minimum TLS version that Contour will negotiate
    67        # minimumProtocolVersion: "1.1"
    68      # The following config shows the defaults for the leader election.
    69      # leaderelection:
    70        # configmap-name: contour
    71        # configmap-namespace: leader-elect
    72  ```
    73  
    74  ## More new features in Contour v0.15
    75  
    76  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.
    77  
    78  We recommend reading the full release notes for [Contour v0.15][2] as well as digging into the [upgrade guide][3], which outlines some key changes to be aware of when moving from v0.14 to v0.15.
    79  
    80  ## Future Plans
    81  
    82  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. 
    83  
    84  If you are interested in contributing, a great place to start is to comment on one of the issues labeled with [Help Wanted][4] and work with the team on how to resolve them.
    85  
    86  We’re immensely grateful for all the community contributions that help make Contour even better! For version v0.15, special thanks go out to:
    87  
    88  - [@DylanGraham](https://github.com/DylanGraham)
    89  - [@so0k](https://github.com/so0k)
    90  - [@mattalberts](https://github.com/mattalberts)
    91  
    92  [1]: {{< param github_url >}}/blob/v0.15.0/docs/upgrading.md#enabling-leader-election
    93  [2]: {{< param github_url >}}/releases/tag/v0.15.0
    94  [3]: {{< param github_url >}}/blob/v0.15.0/docs/upgrading.md
    95  [4]: {{< param github_url >}}/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22