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

對於雲計算你們已經耳熟能詳了，邊緣計算又是一種什麼玩法以及存在哪些挑戰呢？

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

30秒瞭解什麼是邊緣計算？邊緣計算爲何重要？

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

圖片：邊緣計算技術做爲5G網絡架構中核心，智能化改造趨勢分析

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

隨着信息技術的發展，計算資源模式由單一的集中化變成了往集中化和邊緣化兩個方向的分化，集中化即當前如火如荼的雲計算，邊緣化即最近幾年興起的邊緣計算。雲計算給世界帶來的變革你們有目共睹，但有了雲計算爲何還須要邊緣計算呢？這就須要一塊兒來了解集中式的雲計算中遇到的問題：

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

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

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

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

典型場景包括：

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 支持邊緣計算場景的目標。

總體架構以下：

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 也還在不斷探索， 對邊緣計算和邊緣容器感興趣或有好的想法建議，趕忙加羣吧。

但願一樣對邊緣計算感興趣的你與咱們一塊兒在邊緣計算的浪潮中成長，不是後浪，也不是前浪，就作弄潮兒。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！