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

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

## 30秒瞭解什麼是邊緣計算？邊緣計算為什麼重要？

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

![img](https://main.qcloudimg.com/raw/e34072c2621e31ecdddc9ef1f71e8af2.jpg)

圖片：邊緣計算技術作為5G網路架構中核心，智慧化改造趨勢分析

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

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

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

![img](https://main.qcloudimg.com/raw/90de49596073b1374a93b9d81ac10245.jpg)

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

• **安全隱私問題。**應用和資料是企業的核心資源，隨著越來越多的行業網際網路化，如何保證應用和資料的可靠性、安全性是企業最關心的議題之一。

• **技術新需求問題。**隨著技術的發展，單靠資料中心已經很難滿足需求。

典型場景包括：

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](https://main.qcloudimg.com/raw/4066ce151a9c118623fa5869bf80c757.jpg)

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

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

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

相關文章

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

相關文章

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