部署控制平面組件

構建并設計了控制平面后，您將需要確切確定如何部署其組件。 在這里，您可以選擇將控制平面與數據平面共置一處以集中控制平面。 這里還有一個中間立場：部署與控制平面位于同一位置的某些組件，并使某些組件保持集中。 讓我們來看看。

在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

總結

以上是生活随笔為你收集整理的为特使建立控制平面的指南-部署权衡的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。