网站网页直播怎么做,国内网站 备案,网站转化路径,wordpress描述设置部署控制平面组件 构建并设计了控制平面后#xff0c;您将需要确切确定如何部署其组件。 在这里#xff0c;您可以选择将控制平面与数据平面共置一处以集中控制平面。 这里还有一个中间立场#xff1a;部署与控制平面位于同一位置的某些组件#xff0c;并使某些组件保持集中… 部署控制平面组件 构建并设计了控制平面后您将需要确切确定如何部署其组件。 在这里您可以选择将控制平面与数据平面共置一处以集中控制平面。 这里还有一个中间立场部署与控制平面位于同一位置的某些组件并使某些组件保持集中。 让我们来看看。 在Istio服务网格项目中控制平面组件的部署和运行与数据平面分开进行集中管理。 也就是说数据平面与应用程序一起运行并处理所有应用程序流量并通过gRPC流上的xDS API与控制平面进行通信。 控制平面组件通常在其自己的名称空间中运行并且理想情况下应防止意外使用。 Gloo项目遵循类似的部署模型。 控制平面组件与数据平面分离而Envoy数据平面使用xDS gRPC流传输来收集有关侦听器路由和集群等的配置。您可以使用Gloo部署与数据平面代理位于同一位置的组件但这就是泄气。 我们将稍后讨论一些权衡。 最后我们来看一下将控制平面组件与数据平面共同部署的情况。 在Contour项目中默认情况下控制平面组件与数据平面一起部署尽管可以选择拆分部署 。 Contour实际上使用杠杆CRD或Ingress资源进行配置因此所有配置文件的处理和监视都在Kubernetes中进行。 但是xDS服务与数据平面共同部署同样默认情况下您可以拆分它们。 当eBay为部署Envoy构建其控制平面时 他们还将其控制平面的部分发现部件与数据平面进行了联合部署。 他们基本上编写了一个控制器来监视CRDIngress和Service资源然后生成配置映射。 然后这些配置映射将由与Pod一起运行的discovery容器消耗并提供给Envoy。 我应该分开控制飞机吗 各种方法各有利弊。 Gloo团队认为对于大多数用例而言将控制平面分隔开是正确的选择但您可能出于某些优化或不足的理由而将某些组件共置一处。 如果说Envoy是L7网络的心脏和灵魂那么控制平面就是大脑。 在以下方面控制平面必然具有不同的特性 安全性–如果您的数据平面以某种方式受到威胁您将遭受重创 您绝对不希望通过让控制平面受到威胁而放弃对其余应用程序和网络的控制来加剧情况。 此外控制平面可能正在处理密钥证书或应与数据平面分开存放的其他机密的分发。 缩放–您可能最终将以不同的方式缩放数据平面和控制平面。 分组–您可能在数据平面中具有不同的角色和职责 例如您的边缘可能有数据平面Envoy与用于微服务的共享代理池和可能部署的任何sidecar代理相比它们需要的安全性和网络状态有所不同。 控制平面与数据平面位于同一位置这使得保持数据和配置分离更加困难 资源使用情况–您可能希望根据组件来分配或限制某些资源使用情况。 例如您的数据平面可能比控制平面控制面板可能需要更多的内存要占用更多的计算资源并且您将使用不同的资源限制来履行这些角色。 将它们分开可以为您提供更多的细粒度资源池选项而不仅仅是将它们组合在一起。 此外如果控制平面和数据平面并置并争用相同的资源则可能会获得难以诊断的奇数尾部延迟。 部署/生命周期–您可能希望独立于数据平面修补升级或以其他方式维护控制平面 存储–如果您的控制平面需要任何类型的存储则可以在不分离数据平面的情况下进行单独配置如果分离出组件 状态–了解控制平面的状态 由于这些原因将控制平面保持在臂长且与数据平面分离是有意义的。 带走 考虑构成控制平面的运行时组件并希望将它们部署在分离的体系结构中。 协同定位可能是有道理的但不要为此过早优化。 翻译自: https://www.javacodegeeks.com/2019/02/control-plane-envoy-deployment-tradeoffs.html
