Why Enroute ?

Enroute is a generic control plane to drive one or a fleet of envoy proxies. Enroute can work as a Kubernetes Ingress Controller, a Standalone API Gateway or a control plane to drive multiple Envoy proxies.

Enroute is not dependent on kubernetes but integrates with kubernetes depending on the use-case.

While there are other Kubernetes Ingress Controllers and Proxies, Enroute is focused on the API Gateway use-case using Envoy.

How does Enroute drive Envoy?

Enroute populates the cache of an xDS server that feeds Envoy. This Envoy can be running either at Kubernetes Ingress or Standalone.

How can I interface Enroute?

Enroute can be driven using simple REST APIs or a GraphQL client or Kubernetes CRDs or enroutectl CLI tool. Depending on the use-case and flexibility required, there are several options to program Enroute.

How stable is Enroute?

Enroute is fairly stable and is used in production today. Enroute leverages existing stable open source projects to build upon them.

The data path component is an unmodified vanilla Envoy proxy.

The control plane consists of an xDS server derived from Contour project.

How is Enroute different from Contour?

When we started building Enroute, we had a couple of options for a stable xDS server. One of them was an xDS server from Contour. We chose this implementation because of extensive test cases with this xDS server.

While Contour is built for generic Kubernetes Ingress use-cases, Enroute is focused on API gateway use-cases and features. Also Enroute has a more universal approach, it can be run standalone, can manage a fleet of Envoy proxies and does not need Kubernetes. It can also function for traditional API gateway use-cases where the control plane drives one proxy. At the same time, it can work at Kubernetes Ingress API Gateway to feed the xDS cache to drive Envoy proxy.

Enroute maintains a consistent configuration model across Standalone and Kubernetes Ingress. It’s configuration model is different as compared to Contour. The config model uses Filters/Plugins as an extension mechanism (like Envoy) to add functionality at global or route level.

How is Enroute different from Service Mesh?

Meshes typically are optimized for east-west traffic management and zero trust using mTLS. Enroute today supports functionality typically associated with North-South gateways.

It is easy to extend mesh functionality to Enroute by adding mTLS functionality. Once implemented, Enroute's capability to drive and configure multiple Envoy proxies allows the capability to program mTLS depending on the use-case to drive zero-trust.

Enroute does not have a built in secret store or an identity provider. Enroute is built to integrate with external identity and secret providers. Enroute is built for bring-your-own-(identity/secret store/environment)

How can you integrate Enroute with a cloud provider?

Enroute is built to integrate with external cloud service discovery. While different cloud have different discovery mechanisms, Enroute provides APIs to populate services (or upstreams). Cloud discovery performed on a platform of choice can be used to automatically insert Enroute for L7 API Gateway use-cases.

Similarly it provides configuration capability to import secrets from a secret store into Envoy.

Application logic can then be inserted with artifacts and services discovered from the environment in which Enroute is running



We’d like to acknowledge the following amazing projects - Hasura , Contour , Envoy Proxy , Labstack Echo