部署控制平面组件

构建并设计了控制平面后，您将需要确切确定如何部署其组件。 在这里，您可以选择将控制平面与数据平面共置一处以集中控制平面。 这里还有一个中间立场：部署与控制平面位于同一位置的某些组件，并使某些组件保持集中。 让我们来看看。

在Istio服务网格项目中，控制平面组件的部署和运行与数据平面分开进行集中管理。 也就是说，数据平面与应用程序一起运行，并处理所有应用程序流量，并通过gRPC流上的xDS API与控制平面进行通信。 控制平面组件通常在其自己的名称空间中运行，并且理想情况下应防止意外使用。

Gloo项目遵循类似的部署模型。 控制平面组件与数据平面分离，而Envoy数据平面使用xDS gRPC流传输来收集有关侦听器，路由和集群等的配置。您可以使用Gloo部署与数据平面代理位于同一位置的组件，但这就是泄气。 我们将稍后讨论一些权衡。

最后，我们来看一下将控制平面组件与数据平面共同部署的情况。 在Contour项目中，默认情况下，控制平面组件与数据平面一起部署，尽管可以选择拆分部署 。 Contour实际上使用杠杆CRD或Ingress资源进行配置，因此所有配置文件的处理和监视都在Kubernetes中进行。 但是，xDS服务与数据平面共同部署（同样，默认情况下，您可以拆分它们）。

当eBay为部署Envoy构建其控制平面时 ，他们还将其控制平面的部分（发现部件）与数据平面进行了联合部署。 他们基本上编写了一个控制器来监视CRD，Ingress和Service资源，然后生成配置映射。 然后，这些配置映射将由与Pod一起运行的discovery容器消耗，并提供给Envoy。

我应该分开控制飞机吗？

各种方法各有利弊。 Gloo团队认为，对于大多数用例而言，将控制平面分隔开是正确的选择，但您可能出于某些优化或不足的理由而将某些组件共置一处。

如果说Envoy是L7网络的心脏和灵魂，那么控制平面就是大脑。 在以下方面，控制平面必然具有不同的特性：

• 安全性–如果您的数据平面以某种方式受到威胁，您将遭受重创； 您绝对不希望通过让控制平面受到威胁而放弃对其余应用程序和网络的控制来加剧情况。 此外，控制平面可能正在处理密钥，证书或应与数据平面分开存放的其他机密的分发。
• 缩放–您可能最终将以不同的方式缩放数据平面和控制平面。
• 分组–您可能在数据平面中具有不同的角色和职责； 例如，您的边缘可能有数据平面Envoy，与用于微服务的共享代理池和可能部署的任何sidecar代理相比，它们需要的安全性和网络状态有所不同。 控制平面与数据平面位于同一位置，这使得保持数据和配置分离更加困难
• 资源使用情况–您可能希望根据组件来分配或限制某些资源使用情况。 例如，您的数据平面可能比控制平面（控制面板可能需要更多的内存）要占用更多的计算资源，并且您将使用不同的资源限制来履行这些角色。 将它们分开可以为您提供更多的细粒度资源池选项，而不仅仅是将它们组合在一起。 此外，如果控制平面和数据平面并置并争用相同的资源，则可能会获得难以诊断的奇数尾部延迟。
• 部署/生命周期–您可能希望独立于数据平面修补，升级或以其他方式维护控制平面
• 存储–如果您的控制平面需要任何类型的存储，则可以在不分离数据平面的情况下进行单独配置（如果分离出组件）
• 状态–了解控制平面的状态

由于这些原因，将控制平面保持在臂长且与数据平面分离是有意义的。

带走

考虑构成控制平面的运行时组件，并希望将它们部署在分离的体系结构中。 协同定位可能是有道理的，但不要为此过早优化。

翻译自: https://www.javacodegeeks.com/2019/02/control-plane-envoy-deployment-tradeoffs.html