經過Kubernetes實現邊緣計算的3種選擇

導語：企業對邊緣計算有不一樣的見解，但不多有人排除他們未來將應用程序組件部署到邊緣的可能性，特別是對於物聯網和其餘低延遲應用程序。

許多組織還認爲Kubernetes是在邊緣計算環境中運行容器的理想機制，尤爲是那些已經爲知足其雲和數據中心需求而採用了容器編排系統的公司。

在邊緣計算中使用Kubernetes的:3個通用規則是：

規則1：避免使用缺少資源池的邊緣模型，由於Kubernetes在這些環境中不會提供任何真正的好處。這是由於Kubernetes專爲管理集羣中的容器部署而設計，也就是說集羣是一種資源池。

規則2：將邊緣Kubernetes視爲更普遍的Kubernetes部署中的特殊用例。

規則3：除非存在大量的邊緣資源池，不然請避免使用專門爲邊緣託管設計的Kubernetes工具。

除了這3個通用規則外，還有三個主要的部署選項能夠在邊緣環境中運行Kubernetes和容器。

選項1：公有云

在此模型中，公有云提供商託管邊緣環境或者該環境是公有云服務的擴展。

此選項的典型用例是加強雲前端中的交互性。在這種狀況下，邊緣是公有云的擴展，而且組織的Kubernetes部署實踐應適合雲提供商的產品。雲提供商對邊緣計算的支持可能涉及與提供商的公有云服務集成的本地邊緣設備，例如Amazon Snowball。

公有云邊緣託管幾乎老是經過將雲託管選項之一（VM，容器或無服務器功能）擴展到邊緣來支持，這意味着Kubernetes不會將邊緣視爲單獨的集羣。這種方法很容易實現，但可能須要Kubernetes託管策略（例如親和力，污點和容忍度）將邊緣組件定向到邊緣資源。當心; 若是邊緣計算的目標是減小延遲，請不要讓邊緣資源與它們控制的元素相距太遠。

在邊緣計算架構中，數據在網絡外圍進行處理-儘量靠近其原始源。

選項2：數據中心外的服務器設施

這種方法涉及在組織本身的數據中心外部的一個或多個服務器設施中進行邊緣部署。

該邊緣模型的主要用例是工業物聯網，其中存在大量的邊緣處理要求-至少足以證實將服務器放置在工廠和倉庫等位置是合理的。在這種狀況下，有兩種選擇：將每一個邊緣託管點視爲一個單獨的羣集，或者將邊緣託管僅視爲主數據中心羣集的一部分。

在邊緣託管支持各類應用程序的狀況下（這意味着每一個邊緣站點都是真正的資源池），請考慮使用專門的Kubernetes發行版，例如KubeEdge，它針對以邊緣爲中心的任務進行了優化。肯定您的邊緣應用程序是否與數據中心Kubernetes部署緊密結合，以及在某些狀況下邊緣和數據中心是否會備份其餘應用程序。

在許多邊緣部署中，邊緣幾乎充當僅運行專用應用程序而不運行資源池的客戶端。在這種狀況下，可能不須要集成Kubernetes集羣。不然，請考慮使用Kubernetes聯合身份驗證做爲統一邊緣和數據中心策略進行部署的方法。

選項3：專用器具

在這種狀況下，邊緣模型由一組專用於工廠或加工設施的專用設備組成。

許多專用的邊緣設備基於ARM微處理器，而不是基於以服務器爲中心的Intel或AMD芯片。在許多狀況下，這些設備與IoT設備緊密相連，這意味着每一個邊緣設備都有本身的傳感器和控制器社區來管理。這裏的應用程序不是可變的，所以整體上來講，不管是容器化仍是專門用於Kubernetes部署，收益都較少。該模型最多見的用例是智能建築。

非服務器邊緣設備一般與爲較小的設備佔用空間而設計的Kubernetes版本相關聯，例如K3s。可是，某些專用邊緣設備可能根本不須要編排。若是設備能夠同時或分別運行多個應用程序，或者這些設備中的一組託管協做應用程序組件，則能夠考慮使用K3來協調部署。若是這兩個條件都不成立，則根據須要將應用程序簡單地加載到具備本地或網絡存儲的設備上。

在某些狀況下，應用程序的邊緣組件與數據中心中運行的應用程序組件緊密結合。這可能須要管理員同步部署邊緣和數據中心組件，並在二者上使用通用的編排模型。在這種狀況下，要麼將邊緣元素合併到主數據中心羣集中，而後使用策略將邊緣組件託管定向到正確的位置，要麼將邊緣分離爲單獨的羣集，而後經過聯盟對其進行部署和編排。

最終肯定，容器和業務流程是有效使用資源池的工具。對於邊緣計算模型在邊緣建立小型服務器場的企業而言，Kubernetes和邊緣計算是很好的合做夥伴，與主要的Kubernetes部署聯合的，單獨的，特定於邊緣的Kubernetes策略是個好主意。

若是邊緣環境更加專業，可是仍然必須結合主要應用託管資源（不管是在雲仍是數據中心中）進行部署和管理-將邊緣做爲一種主機類型適合現有的Kubernetes部署。若是邊緣是專業的而且在很大程度上是獨立的，則考慮徹底不在邊緣計算中使用容器。