{"id":88735,"date":"2019-02-22T16:00:55","date_gmt":"2019-02-22T14:00:55","guid":{"rendered":"https:\/\/www.javacodegeeks.com\/?p=88735"},"modified":"2019-02-23T16:58:40","modified_gmt":"2019-02-23T14:58:40","slug":"control-plane-envoy-deployment-tradeoffs","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2019\/02\/control-plane-envoy-deployment-tradeoffs.html","title":{"rendered":"Guidance for Building a Control Plane for Envoy – Deployment Tradeoffs"},"content":{"rendered":"

Deploying control plane components<\/h2>\n

Once you\u2019ve built and designed your control plane, you\u2019ll want to decide exactly how its components get deployed. You have some choices here from co-locate control plane with the data plane all the way to centralize your control plane. There is a middle ground here as well: deploy some components co-located with the control plane and keep some centralized. Let\u2019s take a look.<\/p>\n

In the Istio service-mesh project, the control plane components are deployed and run centralized and managed separately from the data plane. 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.<\/p>\n

The Gloo project 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, and clusters, etc. You could deploy the components co-located with the dataplane proxies with Gloo, but that\u2019s discouraged. We\u2019ll take a look at some of the tradeoffs in a bit.<\/p>\n

Lastly, we take a look at co-deploying control plane components with the data plane. In the Contour project, by default, control plane components are deployed with the data plane though there is an option to split up the deployment<\/a>. Contour actually uses leverages CRDs or Ingress resources for its configuration, so all of the config-file handling and watching happens in Kubernetes. The xDS service, however, is co-deployed with the dataplane (again, that\u2019s by default \u2013 you can split them).<\/p>\n

When eBay built their control plane for their deployment of Envoy<\/a>, they also co-deployed parts of their control plane (the discovery pieces) with their data plane. They basically wrote a controller to watch CRDs, Ingress, and Service resources and then generate config maps. These config maps would then be consumed by the discovery<\/code> container running with the Pod and served to Envoy.

<\/div> <\/div><\/p>\n
\"Deployment<\/figure>\n
\"Deployment<\/figure>\n

Should I keep control planes separated out?<\/h2>\n

There are pros and cons to the various approaches. The Gloo team<\/a> believes keeping the control plane separate is the right choice for most use cases, but that there could be optimization or extenuating reasons why you may co-locate some of the components.<\/p>\n

If Envoy is the heart and soul of your L7 networking, the control plane is the brains. The control plane necessarily will have different characteristics when it comes to:<\/p>\n