Kubernetes是以應用為中心的技術架構和思想，以一套技術體系支持任意負載，運行于任意基礎設施之上；向下通過底層基礎資源統一調度及編排容器鏡像的標準化應用，屏蔽基礎設施差異，實現向上;實現應用負載的自動部署；向外突破了中央云計算的邊界，將云計算能力無縫擴展到邊緣和站點，快速構建了云-邊緣一體化基礎設施。
將云原生技術從中心擴展到邊緣，不僅可以實現云邊緣的基礎設施技術架構大一統，還可以實現業務的云邊自由編排部署。但相比Kubernetes在中央云的革命性創新，在邊緣場景上優勢明顯，同時劣勢也非常致命。在邊緣資源有限、網絡不穩定等特殊情況下，需要根據不同的業務場景選擇不同的Kubernetes邊緣解決方案。
1. Kubernetes架構及邊緣化的挑戰
z.itpub.net/zitpub.net/JPG/2022-04-02/459110636EF5C0230E983FC495D0AD83.jpg">從技術架構來看，Kubernetes是典型的分布式架構，Master控制節點是集群“大腦”，負責管理節點，調度Pod以及控制集群運行狀態。Node工作節點，負責運行容器（Container），監控/上報運行狀態。在邊緣計算場景存在以下比較明顯的挑戰：
狀態強一致且集中式存儲架構，屬于中心云計算的大成產品，基于大規模的池化資源的編排調度實現業務持續服務。
Master管控節點與Worker工作節點通過List-Watch機制，實現狀態任務實時同步，但是流量流量較大，Worker工作節點完全依賴Master節點持久化數據，無自治能力。
Kubelet承載太多邏輯處理，各種容器運行時各種實現的兼容，還有Device Plugin硬件設備驅動，運行占用資源高達700M；對資源有限的邊緣節點負擔太重，尤其是低配的邊緣設備。
邊緣計算涉及的范圍大，場景復雜，沒有統一的標準；Kubernetes開源社區的主線版本并沒邊緣場景的適配計劃。
2. Kubernetes邊緣化運行方案
針對中心云計算及邊緣計算這種云邊分布式架構，需要將Kubernetes適配成適合邊緣分布式部署的架構，借助Kubernetes的優勢，彌補Kubernetes的不足，通過多集群管理實現統一管理，實現中心云管理邊緣運行，整體分為三種方案：
集群 Cluster：將Kubernetes標準集群下沉至邊緣，優點是無需Kubernetes做定制化研發，同時可以支持Kubernetes多版本，支持業務真正實現云邊架構一致；缺點就是管理資源占用多。方案比較適合區域云/中心云，邊緣計算/本地計算以及規模較大的產業邊緣場景。
單節點 Single Node：將Kubernetes精簡，部署在單節點設備之上，優點與集群 Cluster方案一致，缺點Kubernetes能力不完整，資源的占用會增加設備的成本，對業務應用無法保證云邊一致的架構部署運行，是一個中庸方案，沒有解決實際問題。
邊緣節點 Remote Node：基于Kubernetes二次開發增強擴展，將Kubernetes解耦適配成云邊分布式架構的場景，中心化部署Master管理節點，分散式部署Worker管理節點。
3. Kubernetes邊緣容器的碎片化
總的來說，邊緣容器的碎片化嚴重，導致構建邊緣計算平臺時難以抉擇。從技術架構來看，幾個邊緣容器產品架構是有差異，總的架構思路主要是將Kubernetes解耦成適合云邊，弱網絡及資源稀缺的邊緣計算場景，本質上沒有太大差異；從產品功能來看，幾個邊緣容器產品功能基本一致，基本上都是云邊協同，邊緣自治，單元化部署功能等。
4. 構建云邊一體化云原生平臺
圍繞Kubernetes容器平臺，構建云邊一體化云原生基礎設施平臺能力，是邊緣計算平臺的最佳選擇，通過云端統一的容器多集群管理，實現分散式集群統一管理，同時標準化Kubernetes集群規格配置：
標準集群（大規模）：支持超過400個節點的大規模集群，配置為ETCD + Master 3臺 8c16G，Prometheus + Ingress 5臺 8C16G， N * Work節點；主要是業務規模較大的云原生應用運行場景；
標準集群（中等規模）：支持超過100個節點以內的集群，ETCD + Master + Prometheus 3臺 8c16G，N * Work節點；主要是業務規模中等的場景；
邊緣原生容器集群：在云端部署集群管理節點，將邊緣節點單獨部署業務現場，支持運行單業務場景的應用，比如IoT物理設備接入協議解析應用，視頻監控分析AI算法模型等業務場景。
按照業務場景需求選擇最優容器集群方案，其中邊緣容器集群方案，與其他集團方案差別較大，其他集群依然保持中心云集群服務一致，基礎資源集中并且池化，所有應用共享整個集群資源；而邊緣容器集群Master管理節點集中部署，共享使用；Worker節點都是分散在業務現場，按需自助增加，自運維且獨占使用。
當前邊緣容器碎片化嚴重，短時間很難有大一統的開源產品，邊緣原生容器集群的集成，長期來看，建議通過標準的Kubernetes API來集成，這種兼容所有邊緣容器的中庸方案。
一致性是邊緣計算的痛點，在邊緣增加一個Cache即可實現斷網特殊情況的邊緣自治，同時可以保證正常網絡情況的數據一致；還有就是Kubelet比較重的問題，隨著Kubernetes放棄Docker已經開始精簡；同時硬件更新迭代較快，相比少量硬件成本，保持Kubernetes原生及通用性為大。其實更希望Kubernetes社區本身提供適配邊緣化方案，同時考慮為Kubelet增加緩存機制。
5. 業務應用的云邊管運協同
基于中心云的分布式業務應用架構，與云邊分布式協同業務應用架構本質上是有很大的差別。在中心云更多的是基于DDD業務領域，將復雜的業務系統拆分成一個個相對獨立的服務，整體構建一個松耦合的分布式應用；但是在云邊分布式場景下，更多的強調的是集中式管控運營，分散式運作支撐；將管理運營系統集中在云中心，實現中心式管控；將支撐業務實時運作的應用分散至邊緣，實現低延遲快速響應。
從業務應用來看，財務/經營，計劃/管理兩層屬于管控運營類的應用，就是需要通過中心云統一匯聚，實現集中化強管控；對延遲不敏感，對安全，大數據分析能力等要求較高；控制，傳感/執行，生產過程三層屬于運作支撐類應用，也可以優先考慮中心云；如果業務場景對延遲敏感，才考慮通過邊緣計算能力，實現分散式低時延響應；
從請求響應來看，對時延不敏感（50ms以上）都有限考慮部署在中心云計算及云化的邊緣產品（CDN）實現；對延遲敏感（小于10ms），運營商骨干網完全無法支持的，考慮建設邊緣計算平臺，同時業務面臨不小的投入及人員；
說的比較抽象，就用實體物流領域為例，對于物流領域，經典的OTW系統（OMS訂單的管理系統，WMS倉庫管理系統，TMS運輸管理系統）；其中OT就屬于典型的管理運營系統，所以建議部署在中心云，通過中心云數據匯聚，實現拼單拆單，多式聯運等跨區域業務；W是倉庫管理系統，管理四面墻的任務，屬于運作支撐應用，并且倉庫一般都有一些自動化設備，就可以考慮將W部署在邊緣。
6. 總結
突破中心云計算的邊界，將云原生Kubernetes從中心拓展至邊緣力，構建云邊一體化基礎設施。面向業務,不僅統一了廣域邊緣側分布式的應用運行時，同時實現了應用的中心化管理和邊緣側運行的云邊協同。面向運維,業務的自動化運維、高可靠性保障，降低邊緣應用的運維工作量，提升邊緣計算業務創新效率。總的來說，Kubernetes云原生是一個龐大且復雜的體系，將整個體系下沉至邊緣，面臨很大挑戰與困難；業務應用想要真正踐行邊緣的云原生體系，需要從理念、系統設計、架構設計等多方面來公關實現，才能充分發揮邊緣的優勢及價值。云原生，邊緣計算兩個領域都在發展，國家也對場景化邊緣計算建設提出更高的要求，未來已來，共同期待。
參考資料：1.邊緣計算社區：2020十大邊緣計算開源項目2.紅帽：Edge computing with Red Hat OpenShift3.運營商邊緣計算網絡技術白皮書（2019）
509006974