【從0到1學習邊緣容器系列1】之 邊緣計算與邊緣容器的起源


對於雲計算大家已經耳熟能詳了,邊緣計算又是一種什么玩法以及存在哪些挑戰呢?

筆者特別拜訪專家,整理了系列文章,和大家從0到1來學習邊緣計算的技術。

30秒了解什么是邊緣計算?邊緣計算為什么重要?

根據邊緣計算產業聯盟的定義,邊緣計算是在靠近物或數據源頭的網絡邊緣側,融合網絡、計算、存儲、應用核心能力的開放平台,就近提供邊緣智能服務,滿足行業在敏捷聯接、實時業務、數據優化、應用智能、安全與隱私保護等方面的關鍵需求。邊緣計算將計算、網絡、存儲、帶寬等能力從雲延伸到網絡邊緣的新型架構模式,其能效友好、帶寬充足、延遲低等特性很好地補充了集中化計算模式遇到的問題。

img

圖片:邊緣計算技術作為5G網絡架構中核心,智能化改造趨勢分析

30秒看完邊緣計算集中式的3大難題

隨着信息技術的發展,計算資源模式由單一的集中化變成了往集中化和邊緣化兩個方向的分化,集中化即當前如火如荼的雲計算,邊緣化即最近幾年興起的邊緣計算。雲計算給世界帶來的變革大家有目共睹,但有了雲計算為什么還需要邊緣計算呢?這就需要一起來了解集中式的雲計算中遇到的問題:

PUE 問題。PUE(Power Usage Effectiveness)電源使用效率,是評價數據中心能源效率的指標。集中式數據中心耗電量巨大,屬於高耗能產業,不符合綠色能源、節能減排理念,其規模和數量受政策限制。根據 IDC 統計,全球數據中心數量在 2015 年達到頂峰,然后開始逐年下降,預計 2021 年會比 2015 年降低 15%。

img

數據來源:數據中心白皮書數據及預測、光大證券研究所

安全隱私問題。應用和數據是企業的核心資源,隨着越來越多的行業互聯網化,如何保證應用和數據的可靠性、安全性是企業最關心的議題之一。

技術新需求問題。隨着技術的發展,單靠數據中心已經很難滿足需求。

典型場景包括:

1)物聯網技術,大量的智能終端位於網絡邊緣,集中計算模式不能滿足所有應用場景;

2)移動互聯網技術的發展,5G 為移動互聯網注入了巨大的能量,集中計算模式滿足不了直播、游戲、音視頻等應用在帶寬、延遲等方面的需求。

30秒了解邊緣計算發展現狀

目前邊緣計算研究領域主要集中在:計算模型、體系結構、信息安全等方面。

• 計算模型主要有:霧計算、移動邊緣計算、智能邊緣計算等,涵蓋物聯網、無線通信網、移動互聯網等領域。

• 體系結構有:ETSI 參考架構、MEC 架構、ECC 參考架構、SWoT 架構、AI-EC 架構。

目前邊緣計算研究熱點主要是延遲敏感、實時性要求高的場景,如:

雲基礎設施 2.0。國內外各大雲廠商逐漸從 “中心雲” 模式轉換到 “雲計算 + 邊緣計算”模式,細化出多種行業雲:金融雲、游戲雲、直播雲、教育雲等。

物聯網。隨着 IoT 規模的快速增長,越來越多的數據無法直接上傳到雲中心,在設備側完成數據存儲、分析、處理將越來越重要

工業互聯網。工業互聯網的本質和核心是把設備、生產線、工廠、供應商、產品和客戶緊密地連接融合起來,從而提高效率,推動整個制造服務體系智能化。

• CDN。CDN 本質上是在靠近用戶的位置分發內容,邊緣計算可以讓 CDN 離用戶更近,提供更低時延、更大帶寬的服務。

• 5G。國家標准組織 ETSI 認為移動邊緣計算 MEC 是一種將基站和互聯網業務深度融合的技術,可以靈活地在物理網絡切分出邏輯網絡以滿足復雜多變的應用需求。

15秒掃完邊緣計算帶來的挑戰

與強勁的市場需求矛盾的是,邊緣計算目前尚沒有一套成熟的技術體系,存在的問題包括:

• 缺失技術標准和規范

• 沒有統一的體系結構

• 邊緣設備異構嚴重

• 邊緣設備數量龐大、分布廣闊

• 服務質量保障

邊緣容器誕生帶來的希望之光

容器技術是最近幾年發展勢頭很好的技術之一,相比物理機和虛擬機,容器技術非常輕量級,並且具有如下優點:部署簡單、支持多環境、啟動時間更短、易擴容、易遷移,比較常見的容器技術有 Docker 和 Containerd。這些特點很好地解決了 “邊緣設備異構嚴重” 這一問題。

但是在管理主機數量規模較大的業務場景時,單機容器管理方案往往力不從心。Kubernetes 是當前最流行的容器編排和管理系統,它實現了一套高效的應用管理、應用自修復、資源管理、線上運維和排障機制,並且形成了監控告警、服務網格、日志及調用鏈分析、CI/CD 等方面的一系列生態。這些有助於解決 “缺失技術標准和規范”、“沒有統一的體系結構”、“服務質量保障”、“管理成本高”等方面的問題。

然而,Kubernetes 原本是針對集中式資源管理場景設計,簡單地應用到邊緣計算場景會遇到諸多不適應,導致系統不穩定甚至在某些場景下運行不起來。

邊緣容器的目的就是通過解決 Kubernetes 所有不適應邊緣計算場景的點,實現使用集中式的 Kubernetes 來管理分散的邊緣設備。

邊緣容器也遇到了挑戰

通常來說,為了管理上的方便集群控制中心都是集中式設計、部署在指定地區,或者為了保障高可用有選擇性地部署在某幾個地區。目前較常見情況是控制中心部署在雲廠商雲端中心機房(公有雲)或者用戶中心機房(私有雲);邊緣設備位於邊緣雲機房、移動邊緣站點、用戶現場設備。

為了讓 Kubernetes 更好地用於邊緣計算場景,我們有必要整理出邊緣計算場景的主要特性

雲邊弱網絡。控制中心和邊緣設備之間網絡較復雜,因特網、以太網、5G、WIFI 等形態均有可能,網絡質量差次不齊沒有保障。

邊緣設備之間網絡情況復雜。邊緣設備之間有可能是局域網,也有可能位於不同的地區、相互不通。

邊緣設備資源緊張。相對而言,邊緣計算設備從邊緣雲、移動邊緣站點、用戶現場設備,單個設備的硬件資源逐漸變少。其中用戶現場單設備內存有可能不到 1G。

邊緣服務管理要求復雜。在中心雲機房,應用可以根據節點資源擇優部署;而在邊緣場景,應用部署需要考慮網絡和地域等屬性。

1分鍾講述管理邊緣容器的方案

業界目前有多種邊緣容器管理的解決方案,騰訊雲針對私有雲和公有雲分別推出 tinykube 和 TKE@edge。這里主要介紹公有雲TKE@edge整套方案致力於保持對原生 Kubernetes 功能及其生態完全兼容、以盡量少的改動達到讓原生 Kubernetes 支持邊緣計算場景的目標。

整體架構如下:

img

TKE@edge 整體是雲端管控架構,Master 位於中心,邊緣節點全部是 worker 節點。雲邊引入 tunnel 和 hub 兩個通信組件,支持身份認證和數據加密;雲端引入兩個自研的 Controller:serviceGroup-Controller、observer-Controller;邊端引入 store 和 observer;用戶集群 master 組件運行在雲端 metacluster 基礎集群,用戶集群數據統一保存在雲端 Etcd 集群;使用者可通過 TKE@edge 控制台或者在本地使用 kubectl 工具直接管理自己的集群,也可以基於 TKE@edge 之上二次開發管理平台。

TKE@egde解決了邊緣容器什么問題

雲邊弱網絡。hub 組件的核心作用是解決邊到雲弱網絡問題,該組件代理了邊緣節點上所有核心組件向 apiserver 發起的請求,並且將關鍵數據持久化保存在本地。當雲邊網絡異常時,節點側依然可以使用這些數據,避免因雲邊弱網絡原因引起業務異常。另外,邊緣弱網絡很容易觸發 Kubernetes 驅逐機制,引起不符合預期的 Pod 驅逐動作,TKE@edge 首創分布式健康檢測機制可以智能地識別驅逐時機,保障系統在弱網絡下正常運轉。

邊緣設備之間網絡情況復雜。復雜性表現在一個集群內的節點極可能分布在多個邊緣局域網內(通常稱為節點或者站點,site,為避免與 Kubernetes 集群中的節點一詞混淆,后面均稱站點),意味着同一站點內的節點之間可達,站點之間的節點之間通常不可達,這會影響集群內服務之間的調用。TKE@edge 首創 serviceGroup 資源,該資源支持用戶指定服務之間流量拓撲策略,實現按策略訪問。

• 邊緣設備資源緊張。原生 Kubernetes 中主要是 Master 組件資源消耗較大,節點側資源消耗並不多。TKE@edge 采用雲端管控架構,讓 Master 組件部署在資源豐富的中心側,邊緣側只運行 kubelet、kube-proxy 等資源消耗少的組件,邊緣側只需要較少資源即可滿足條件。

• 邊緣服務管理要求復雜。集群內包含多個站點時,通常希望在每個站點部署一整套微服務,理論上我們可以通過給每一個服務在每一個站點分配不同的名字來實現目的,實際上這么操作會帶來兩方面的問題:1)服務名太多難以管理;2)同一服務在不同站點名字不同,難以通過服務名訪問;3)當增加或者撤銷站點時需要人工添加和刪除對應的 yaml,這無疑會帶來管理災難。TKE@edge 首創 serviceGroup 能自動完成上述操作,大大降低管理困難。

TKE@edge閃閃發光的亮點

• serviceGroup。能解決邊緣設備之間網絡復雜及邊緣服務管理困難問題。客戶只需要使用 ServiceGroup 提供的 DeploymentGrid 和 ServiceGrid 兩種 TKE@edge 自研的 Kubernetes 資源,即可一鍵將服務部署到所有邊緣站點中,同時還能保證服務在各站點的實例數量、提高應用在每個站點的高可用。

• hub。實現關鍵數據本地持久化,保障系統在弱網絡下正常運轉。即使節點與 Master 斷網的情況下應用也不受影響,並且可以做到節點重啟后應用自動恢復。

• observer。分布式健康檢測機制,可以識別邊緣節點健康情況,智能識別應用驅逐的時機。

• tunnel。雲邊隧道機制,允許從雲端登錄容器、查看日志、往容器上傳下載文件。對於無公網地址的設備,該功能可以明顯提升運維效率。

• 定制網絡組件。站點整體與雲端失聯情況下服務正常運行,並且允許邊緣節點發生重啟。

高可用

• Master 組件。托管於騰訊雲有 SLA 保證、並且有騰訊雲 TKE 團隊運維;Master 組件支持自動擴縮容,可根據集群壓力自動調整實例數量,以滿足業務需求。

• 邊緣節點和站點。目前可以做到邊緣端運行微服務時,邊緣站點整體與管控端掉線的情況下業務不受影響,掉線期間允許計算資源發生重啟。

• 業務應用。保證站點內業務 Pod 可用數量,支持一個服務在同一節點上運行多個 Pod。

易用性

• 監控告警。支持集群和Pod級監控告警,維度包括 CPU、內存、網絡,告警方式有電話、短信、微信、郵件

• 邊緣資源管理。一鍵添加、刪除邊緣節點(限騰訊雲邊緣計算資源)

• 應用管理。一鍵部署、更新、刪除應用,Helm 應用打包管理(規划中)

• 界面化操作。目前集群管理、節點管理、Workload 和常用 Kubernetes 資源管理、日志和事件查詢等均可以通過 Web 界面完成,大大降低使用門檻。(產品目前是白名單開放,使用前請在騰訊雲官網上申請加白名單)

• CICD。支持使用藍盾,支持 Coding 系統(規划中)

幫扶運維

• 雲端登錄邊緣應用容器內部,雲端往/從容器內部傳輸文件

• 雲端查看業務日志、事件

• 應用日志采集(規划中)

結束語

邊緣容器是一個非常新的方向,充滿了困難和機會,TKE@edge 也還在不斷探索, 對邊緣計算和邊緣容器感興趣或有好的想法建議,趕緊加群吧。

希望同樣對邊緣計算感興趣的你與我們一起在邊緣計算的浪潮中成長,不是后浪,也不是前浪,就做弄潮兒。

【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多干貨!!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM