Guidance for Building a Control Plane for Envoy Part 5: Deployment Tradeoffs

Once you’ve built and designed your control plane and its various supporting components, you’ll want to decide exactly how its components get deployed. You’ll want to weight various security, scalability, and usability concerns when settling into what’s best for your implementation. The options vary from co-deploying control plane components with the data plane to completely separating the control plane from the data plane.

There is also a middle ground here as well: deploy some components co-located with the control plane and keep some centralized. Let’s take a look. In the Istio service-mesh project, the control plane components are deployed and run separately from the data plane.

This is very common in a service-mesh implementation. That is, the data plane runs with the applications and handles all of the application traffic and communicates with the control plane via xDS APIs over gRPC streaming. The control-plane components generally run in their own namespace and are ideally locked down from unexpected usage.

The Gloo project, as an API Gateway, follows a similar deployment model. The control-plane components are decoupled from the data plane and the Envoy data plane uses xDS gRPC streaming to collect configuration about listeners, routes, endpoints, and clusters, etc. You could deploy the components co-located with the dataplane proxies with Gloo, but that’s discouraged.

We’ll take a look at some of the tradeoffs in a bit.

Source: medium.com