frequently asked questions
Why Enroute ?
Enroute is built as a light weight controller that can be deployed anywhere - on premise, on the cloud, in greenfield and brownfield deployments. While enroute can be run outside kubernetes, it can also be run inside one as an ingress controller or to run a gateway mesh. Enroute provides a way to install network function in all these environments.
As a monolithic application gets split, so does the network application delivery function. This has given rise to multiple proxies deployed along an application delivery path, with each one running a part of network function - be it security, tracing, canary or something else. An architecture that provides a mechanism to manage these proxies while allowing fine grained attachment of network function to them is critical. Enroute fills this gap.
Enroute vs 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.
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)
Enroute can be used for hyper scale-out architectures or adding a la-carte observability, rate-limiting, canary as a side-car
How does Enroute simplify config?
Enroute Standalone provides for a way to program multiple Envoy proxies. It defines well known abstractions like proxy, service, route, upstream and secret. It provides an API to work with these abstractions.
When run as an ingress controller, Enroute has well defined Custom Resource Definitions (CRDs) to drive its configuration. The configuration model is consistent across Standalone gateway, the Gateway SideCar and the CRDs for ingress controller. This consistency of configuration model provides the critical flexibility required to run network function along the application delivery path.
The configuration once defined, can be associated with one or more proxies.
Why do you need the dual plane architecture ?
Enroute is implemented as a control plane that is the central repository for all Envoy config. The data plane component implements the xDS server. The dual plane architecture provides the flexibility to use Enroute for multiple use-cases.
This approach allows Enroute to integrate with cloud infrastructure, discovery services, secret stores and identity providers.
Enroute lets a user track configuration changes over a period of time. Its config backup and restore let developer operations keep track of configuration changes and treat infrastructure as code.
Separation of control plane allows independent managment, upgrade and scaling of components.
How can you integrate Enroute with a cloud provider?
Enroute is built to integrate with external cloud service discovery. Additionally 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
Enroute architecture provides flexibility to deploy it in multiple ways. We describe here the containers that are available to deploy Enroute
- Enroute gateway has control plane and one instance of data plane all packaged as one container.
- Enroute gateway image can run as kubernetes ingress gateway at kubernetes ingress
- Enroute control plane provides the API to configure one or more data planes.
- Enroute data plane connects to the control plane to read config and program itself.
Create kubernetes deployment with
enroute-gw image for kubernetes ingress
######### Create deployment using enroute-gw image ########## apiVersion: apps/v1 kind: Deployment metadata: labels: app: enroute name: enroute namespace: enroute-gw-k8s ... spec: containers: - image: saarasio/enroute-gw:latest imagePullPolicy: Always name: enroute ... --- ########## Create enroute service ########## apiVersion: v1 kind: Service metadata: name: enroute namespace: enroute-gw-k8s ... selector: app: enroute type: LoadBalancer ---
enroute-gw (enroute-cp & enroute-dp named
docker run \ --net=host \ saarasio/enroute-gw:latest
docker run \ --net=host \ saarasio/enroute-cp:latest
Start data plane
proxy-p config on controller
docker run \ -e ENROUTE_NAME=proxy-p \ -e ENROUTE_CP_IP=enroute-controller.local \ -e ENROUTE_CP_PORT=8888 \ -e ENROUTE_CP_PROTO=HTTP \ --net=host \ saarasio/enroute-dp:latest