CNCF Ingress Options and Developer Workflow: Emissary-Ingress and Contour

If you are a developer or platform builder working with Kubernetes and looking for ingress or API gateway options then this is the post that will get you thinking both about the problem space and your technical options. As much as it is easy just to evaluate technical features, you will also learn that thinking about the impact on your developer workflow is equally important.

Getting Started With the CNCF Landscape

There are obviously a lot of options in ingress space, but a good starting point when choosing which technology to adopt is often the CNCF landscape. Yes, we all know that this can be an “eye chart”, but a pointer to all of the projects within each problem space or technology category in the cloud-native ecosystem is invaluable. 

You can be sure that if you pick a tech solution from the CNCF landscape, a certain amount of due diligence has occurred, both around the technology and also the supporting community and ecosystem (particularly with projects at the incubation level). 

For the Kubernetes Ingress and API gateway space, two projects jump out from the landscape: Emissary-ingress (initially created by us at Ambassador Labs) and Contour (initially created by the Heptio team). Both of these projects are also powered by Envoy Proxy, which is rapidly becoming the de-facto cloud-native proxy.

Let’s explore these two open-source Kubernetes ingress projects in more detail. In particular, we would like to share our thoughts on what criteria you should be thinking about as a developer or platform builder, in addition to the obvious checkbox or “paper eval” feature criteria.

Kubernetes Ingress Criteria: Think Workflows, and Not Just Tech

To start with, as someone who is new to the Kubernetes world and trying to finalize an ingress-controller for your use case, the below-mentioned pointers can help you in making a better-informed decision:

Impact on Your Workflow

This seems to be the most important part of the puzzle. Understanding how the ingress-controller will impact your existing Kubernetes development workflows is critical e.g., whether you will need to modify or redefine your workflows, or if you can seamlessly integrate this into your day-to-day experiences as a cloud-native developer.

Requirements on Advanced Features

Are you good with a lightweight tool just to manage and route your ingress or are you a developer with more requirements who need more advanced capabilities from the ingress-controller, like canary deployments, circuit breakers, authentication, observability, attack mitigation, etc to name a few?

Need for an API Gateway

It is important to understand if only managing Ingress is your call or if you need additional features like a developer portal, rate limiting, security, request, and response transformation that API Gateway-type Ingress Controllers can provide.

The Underlying Architecture 

The “engine” of the Ingress controller is important, and all of the choices come with tradeoffs, e.g. is it an NGINX based solution (Kong, NGINX ingress), an HAProxy-based project (HAproxy, Voyager), or an Envoy-based ingress (Emissary-ingress, Ambassador Edge Stack, Contour, Istio, etc)

Need for Enterprise Support (Commercial Relationships)

Are you happy with an open-source Free version or do need a Paid Enterprise version for better support and your critical applications

Now once you have more clarity on the above points, we can again focus on our topic for the day: Emissary Ingress and Contour Ingress 

Emissary Ingress

Emissary-ingress is an open-source ingress controller and an API gateway. It is built on top of Envoy Proxy and supports a number of ingress use cases, like load balancing, authentication, rate limiting, and observability. Emissary-ingress was initially developed by the team at Ambassador Labs (formerly known as Datawire) and now it is currently an incubating-level project at the Cloud Native Computing Foundation (CNCF). 

Emissary-ingress is completely open-source and exposes all the API endpoints needed for you to plugin modules for rate limiting and authentication etc. Ambassador Edge Stack builds upon Emissary-ingress and provides advanced features “out-of-the-box”. It comes with a free community edition and also a paid enterprise version, and includes several advanced capabilities like canary deployments, circuit breakers, rate-limiting, attack mitigation, etc.

A Mapping for Every Service

Emissary-ingress has been designed to be operated effectively by both platform operators and developers. Often the ops/platform team will configure the core CRDs like Host and Listener, as they also manage domain names and TLS certs etc. The remaining CRDs used for the day-to-day configuration of routing and other cross-functional features are easily understandable by developers. 

Looking to expose a backend microservice in Kubernetes? It’s as easy as creating a Mapping that points from a URL path/prefix to a K8s service:

---

apiVersion: getambassador.io/v3alpha1

kind:  Mapping

metadata:

  name:  my-service

spec:

  prefix: /my-service/

  service: my-service.namespace:8080

Looking to add rate-limiting? This uses a similar CRD-based approach and can easily be applied to individual routes and Mappings.

As each CRD can be stored in separate YAML files, it’s easy to control this in a decentralized fashion. You can store the configuration in the most useful place for you as a developer i.e. you can include all of a service’s Mappings in a folder within the microservice code repo.

Contour

Contour is another open-source Kubernetes ingress controller providing a control plane for Envoy edge and service proxy. It is built on top of Envoy Proxy and supports a number of ingress use cases.

Contour was created at Heptio in 2017 to get around limitations in the standard Kubernetes Ingress specification. It then became part of VMware when the organization acquired Heptio in 2018. Contour is currently an incubating project at the CNCF.

Centralized Routing

Contour uses the HTTPProxy for routing and configuring backend access. You can find an example in the project’s documentation:

# httpproxy-multiple-paths.yaml

apiVersion: projectcontour.io/v1

kind: HTTPProxy

metadata:

  name: multiple-paths

  namespace: default

spec:

  virtualhost:

    fqdn: multi-path.bar.com

  routes:

    - conditions:

      - prefix: / # matches everything else

      services:

        - name: s1

          port: 80

    - conditions:

      - prefix: /blog # matches `multi-path.bar.com/blog` or `multi-path.bar.com/blog/*`

      services:

        - name: s2

          port: 80

There is a lot of similarity with the Emissary-ingress’ approach, with the main difference being the typical approach of defining all of the routes in a single HTTPProxy stanza. This is great for centralized control for the platform team, but not so convenient for independent microservice teams making rapid iterations to URL paths and backend services.

Emissary Ingress and Contour: Key Technical Features

In the above sections, we’ve tried to highlight one of the different decisions for each of the projects that may impact a developer’s workflow. We know features are important too, and so here are the highlights for these two projects:

Conclusion 

Emissary Ingress and Contour are very useful and popular CNCF ingress projects, and a call to pick one of them should be based not only on your application architecture, your experience and expertise within your team, but also the ability for the technologies to support your required developer workflows. 

As an example impact on your developer workflow, the balance between the need for centralized governance for the operations team and decentralized workflow for developers is something not to be underestimated when deciding between ingress solutions.

This is a wrap, and we encourage you to share your views and thoughts with us in the comments below.