導語 | 5G網路下，多接入邊緣計算（MEC）應運而生。結合TKEStack強大的叢集管理能力和異構計算資源管理能力，騰訊打造了一個功能完備的邊緣計算PaaS平臺TMEC，提供了高精確度定位、視訊處理、無線網路QoS控制和5G切片等多種特色業務能力，很好地支撐了車路協同、5G雲遊戲、視訊直播等應用。本文是騰訊雲技術專家楊勇&何猛老師在「雲加社群沙龍online」的分享整理，希望與大家一同交流。
一、5G典型應用場景及其挑戰
1. 從自動駕駛說起
自動駕駛在國際是非常熱的話題，業界的標準分成了不同的等級，有的分成了5級、有的分成了6級。
如上圖所示，國家工信部相關規範將自動駕駛等級標準定義為6級。目前國內的廠家和國際的一些廠家，絕大部分處於處於L2或者L3的水平。騰訊也有自動駕駛相關的產品，目前有數百人的團隊從事自動駕駛等相關產品和技術的研發工作。
從實踐落地的角度看，自動駕駛汽車商用的成熟性目前來看並不高，這中間存在很多問題，其中技術、成本和安全是阻礙自動駕駛產品規模商用的主要因素。
2. 自動駕駛技術和挑戰
典型的自動駕駛車輛涉及到硬體和相關軟體的系統性挑戰。主要包括以下四個方面：
第一是高精地圖，其中包括釐米級精度、豐富的路標資料和三維重建能力。
第二是多感測器，其中包括攝像頭、鐳射雷達、毫米波雷達、超聲感測器、慣導和衛星天線等。
第三是環境建模及智慧決策，其中包括多感測器融合感知、道路和區域識別、環境模型構建、智慧預測和決策等。
第四是車身控制，其中包括車輛自動控制、駕駛策略執行及規劃。
總體來看，在目前的水平之下，整個自動駕駛車輛因為要安裝多種感測器、工控機及系統控制軟體，成本比較高昂，而且鐳射雷達等感測器的使用壽命也比較有限。業內人士曾經估算過，自動駕駛車輛的成本不會低於20萬美元，這極大阻礙了自動駕駛汽車產品大規模商用落地。
3. 三大重點因素
即使自動駕駛車輛配備了這麼多的專業感測器和其它專業裝置，在一些異常情況下還是不能很好的解決實際路況上出現的一些安全問題，包括特斯拉在內的自動駕駛汽車曾出現多次交通事故，導致財產損失和人員傷亡。
比如，在超視距的情況下，車載感測器包括雷達或者攝像頭檢測不到轉彎前方的車輛，或者從街角對面駛過來一個車輛，就很容易發生交通事故。
剛才也提到了從成本的角度來講，自動駕駛車輛的成本是非常高昂的。
另外從出行效率角度來講，作為交通管理部門或城市市政管理部門，提升交通出行效率是他們主要工作目標之一。但自動駕駛車輛在道路上行駛的時候，考慮安全因素，會相應採取一些比較保守的策略。
比如說它的行車速度可能會比較低，同時在發生異常事故的時候，它會減速或者停車避讓，這就使得整個交通的效率並不能得到有效的提升。
4. 車聯網的技術實現C-V2X
綜合以上因素業界提出了 C-V2X 這個概念，這裡面的 C 是蜂窩網路的意思， V2X 的全稱是 vehicle to everything，就是說，基於蜂窩通訊的 V2X 技術，使得車輛和道路所有參與方都能進行實時的資料交換，通過這種資訊交換，來進一步提升包括車輛和其它參與方的安全性，同時提升出行效率。
我們看到 V2X 主要包括四種場景：
第一個是 V2V（車輛對車輛），它主要解決一些車輛之間的可能發生的一些異常狀況，比如說車輛碰撞事件；
第二個是 V2I，就是車輛和路邊基礎設施，比如紅綠燈等，通過車輛和紅綠燈的資料交換來及時提醒車輛減速或者保持一定車速，引導車輛通過綠波帶，既能提升行車安全，也可以提升車輛出行效率。
第三個 V2N，通過和通訊網路的互動來為駕乘人員提供一些個性化資訊服務。
第四個 V2P，通過和行人之間的資料交換，來為行人或非機動車發出一些安全提醒。
C-V2X 的目標總體上涵蓋資訊服務、交通安全、交通效率和輔助自動駕駛，它的目標之一就是把單車解決不了的問題移到路端去解決，通過路側裝置和車輛之間的 C-V2X訊息互動來進一步輔助自動駕駛，提升交通安全能力，提升道路出行效率，形成“聰明的車”和“聰明的路”。
5. 單車智慧到雲端智慧
那麼按照“聰明的車”到“聰明的路”的想法，我們是不是可以將完全依靠自動駕駛車輛本身所具備的智慧決策能力給它遷移到雲端上去實現？這樣還可以大幅降低車輛的購置成本，而且因為雲端有高效能、可擴充套件的計算能力，可以做很多車端勝任不了的計算任務。
另外我們知道，現在自動駕駛汽車在車端要做大量的基於計算機視覺或者雷達資料的路況實時分析，這種高效能運算在車輛計算單元上的處理，其準確性等方面還有待提升，如果能移到雲端去做，準確性可能會提高很多，而且雲端還可以做很多複雜的算術和邏輯運算。
但是這裡有一個問題，即雲端計算存在的時延問題。自動駕駛智慧決策的時延要求非常高，如果移到雲端去計算，整個資料鏈路拉長勢必造成時延的增加，這就可能給自動駕駛業務帶來嚴重的影響。例如車輛在高速公路上以120公里/小時的速度行駛，每秒鐘就能行駛 30 多米，時延增大就可能會引發嚴重的交通事故。
所以移到雲端是個不錯的想法，但它又帶來了時延方面的負面因素，這種情況就為邊緣計算的部署提供了一個契機。也就是，把雲端那些計算任務移到路側的邊緣計算平臺上來進行，通過在路側的基礎設施上部署邊緣計算平臺和車聯網的應用，從而對車輛進行實時的智慧提醒和決策。
在靠近網路接入的路側基礎設施上進行邊緣計算，它的好處是非常明顯的。第一，計算能力大幅提升，有利於準確度的提升；第二，不需要佔用過多的核心網或者骨幹網路頻寬；第三，可以有效降低時延，在網路的邊緣側只要通過基站就可以直接將訊息分發給路上的終端，資料傳輸路徑比網際網路到無線核心網再到無線接入網的路徑短了很多，這就是邊緣計算在車聯網中應用的背景。
二、多接入邊緣計算平臺及其關鍵技術
1. MEC在5G網路中的位置
邊緣計算在車聯網裡面會發揮著重要作用，目前我們看到各地關於 C-V2X 的新基建建設專案，重點的內容就是 C-V2X應用 和 MEC 服務的建設和部署。
上圖展示了無線網路的架構圖及MEC在網路中的位置，左邊是一些終端，通過5G基站接入5G核心網路，最終抵達網際網路上部署的各種業務。其中核心網分為上面的控制面裝置CCF和下面的使用者面裝置UPF。
控制面有很多的功能實體，這些功能都是 5G 網路專用的核心網網元。MEC需要部署在邊緣UPF附近，通過本地分流能力將手機使用者的業務請求引導到MEC上，由MEC上部署的應用為其提供服務。
比如說，通常情況下手機訪問英特網上的業務，其訪問路徑是經基站裝置到邊緣UPF，再經本地UPF匯聚後進入因特網，最後到達雲主機，這條路徑比較長。
而在邊緣計算場景下，業務部署在邊緣UPF附近的MEC上，資料傳輸路徑明顯短了許多。當使用者訪問一個邊緣應用的時候，我們通過本地分流將使用者的請求直接引導到部署在基站側的 MEC 上，這樣它的流量就在靠近網路邊緣被處理了，既不佔用後端的核心骨幹網路的頻寬，同時又能降低手機訪問網路業務的時延，優勢顯而易見。
2. 騰訊邊緣計算TMEC平臺
（1）系統架構
在這種背景下，騰訊提出了邊緣計算 TMEC 解決方案。
整個解決方案分成三個層次，最上面是業務層，是TMEC支援的主要的邊緣應用，比如雲遊戲、視訊直播、智慧出行、智慧影視、智慧製造等。我們看到這些業務絕大部分都和視訊相關，這是因為視訊在網路中佔的頻寬非常大，邊緣計算可以很好地解決視訊相關應用對網路頻寬的佔用，同時保證手機端的使用者體驗。
中間層是平臺層，我們知道騰訊雲有非常豐富的中介軟體服務，可以為上層應用提供豐富且可靠的基礎業務支撐能力。
最下是基礎層，它是 TMEC 平臺的基礎支撐，我們採用騰訊雲自研的容器平臺TKEStack來實現。
下面簡單介紹幾個TMEC上部署的特色業務能力。
（2）5G業務能力
TMEC 一個重要的特色業務能力就是 5G 業務能力。
要實現5G業務在邊緣計算裝置上的部署，必須支援5G網路流量從 UPF分流到邊緣計算站點。因而，引流是MEC平臺的基本功能，通過與核心網的互動，將終端發給核心網的資料流量依據MEC業務的要求分流到MEC站點並分發給MEC業務處理。
如上圖所示，3GPP標準定義了引流功能的實現。目前引流有多種方案，比較成熟的是基於上行分類器UL CL的引流方案，目前騰訊已經和多個裝置廠家進行了對接，實現了從核心網UPF網元到MEC 流量的引導。
TMEC還支援 5G QoS 和網路切片能力，可以為部署在 TMEC上的應用提供一個可靠的無線通訊 QoS 保障。網路切片是 5G 重要特徵，TMEC支援為邊緣應用建立專門的網路切片，來進一步保證應用的服務質量。目前這些工作騰訊已經在現網和裝置廠家及運營商之間進行了對接。
（3） 視訊處理能力
視訊類應用是邊緣計算典型的應用場景。TMEC提供有高質量的視訊轉碼能力，它是基於使用者感興趣區域ROI的視訊編碼技術，通過這個技術可以在不影響使用者體驗質量的情況下，將位元速率降低30%以上。
3. TKEStack
（1）TKEStack在TMEC架構中的位置
從上圖中可以看到，TKEStack是屬於基礎平臺層的解決方案。基礎平臺層主要解決的問題是為上層業務提供計算資源支撐，解決上層業務的各個服務在服務生命週期內的對計算資源、儲存資源、網路的需求問題。
隨著容器技術的發展，容器化的服務可以在叢集上自由的遷移，服務的可靠性和穩定性得到了更好的保障，同時也帶來了一些問題，比如：容器如何編排？編排框架上手難度較大，如何部署和維護？如何節省服務依賴的日誌、告警、網路元件的部署維護成本？多個k8s叢集如何管理等等問題，TKEStack正是這樣一個解決此類問題的容器雲平臺。
（2）TKEStack基礎平臺層
部署安裝：
在ToB業務場景裡面臨的第一個問題就是部署更新問題。針對TKEStack平臺部署，我們提供了一個 tke-installer 的工具，工具一鍵安裝後提供一個部署平臺的Web頁面，使用者在Web頁面上填寫各種平臺配置後即可搭建一個global叢集用於執行TKEStack平臺。
平臺部署後為使用者提供了一個Web頁面，使用者通過管理員使用者登入到平臺後進行業務叢集的建立和管理等等。同時平臺支援各種擴充套件外掛，使用者可以根據需要在自己的業務叢集或者global叢集一鍵安裝，對叢集功能進行擴充套件。
異構資源虛擬化：
隨著AI的興起，由於需要大量的矩陣乘加計算，X86計算資源已無法滿足程式對算力的需求，異構計算硬體慢慢普及開來，如：NVIDIA GPU、intel VPU、NPU等等，異構計算資源往往無法像CPU一樣進行分時虛擬，目前TKEStack已經支援了Nvidia GPU 和Intel VPU，後續還會陸續增加對atlas、寒光的支援。
運維報警：
通常情況下，程式出現問題，都是反饋到功能上，然後再由程式開發者層層排查才能解決，在沒有獨立的日誌監控系統情況下，日誌檢視往往要先到執行這個服務的伺服器上排查，這個過程非常麻煩，在實時性要求較高的環境裡基本不可接受，否則就要安裝一套日誌監控系統，開發者要花費精力調研、搭建、維護日誌監控系統，TKEStack 整合了日誌和監控報警等功能，通過擴充套件外掛形式，一鍵部署，解決了上層平臺的日誌報警需求。
（3）TKEStack 能力介紹
上面我們簡單介紹了TKEStack的主要功能，接下來我們詳細介紹一下TKEStack的各項能力。
安裝部署：TKEStaCk頁面上通過幾步按鈕就可以部署一個k8s叢集，安裝各種平臺外掛，比如日誌 採集、網路、儲存等。
租戶管理 ：TKEStack提供了租戶和使用者兩層的許可權管理。租戶層，使用者可以通過劃分不同的租戶將平臺切分成多個平面，各個租戶之間互相隔離，適用於不同部門的不同業務依賴的資源各自獨立的場景。使用者層，同一個租戶平面裡可以建立各種使用者，不同使用者可以管理各自的業務，使用自己的業務下的資源建立k8s負載。
原地升級：服務生命週期裡，部署成功後下一個問題就是升級更新了，正常k8s上的負載升級是先建立一個新的pod然後銷燬舊的pod，在資源緊張情況下，容易導致升級失敗，同時無法支援同一個負載下多版本共存，TKEStack的TAPP外掛通過一個自定義的CRD，允許使用者可以獨立操作一個TAPP負載下的每一個POD，比如給單個Pod升級、重啟等等。
GPU管理：提供一鍵安裝 GPU 和 Nvidia 相關依賴能力，統一管理由不同型號 GPU 伺服器組建的異構容器計算叢集；Nvidia GPU，通過劫持cuda呼叫，實現了一卡多用，多容器共享同一張卡，還具備良好的隔離能力。針對intel VPU的host-device模式的計算資源，通過bridge形式將device和host置於的同一網路平面，解決device節點的網路問題，讓device節點正常加入k8s叢集進行資源排程。
運維中心：平臺具備高可用和可擴充套件性的細粒度監控告警系統，在此基礎上已經支援平臺審計、平臺事件、平臺告警及告警記錄查詢、日誌檢索等功能，滿足使用者各種監控告警需求。
多種網路模式：TKEStack支援underlay和overlay兩種模式的k8s網路方案，underlay模式下支援將容器網路和物理網路打通，比如騰訊公有云上，k8s容器和cvm 的vpc打通，容器使用起來更類似於一臺cvm，支援使用者使用已有的負載均衡對容器內的服務進行負載均衡，overlay模式下改良了原有的flannel，通過ip封包，降低了封包損耗，提升了網路效率。
（4）TKEStack功能圖譜
TKEStack作為一個基礎平臺層解決方案，目前在叢集管理、業務管理、應用管理、認證授權、映象倉庫、監控告警、日誌、擴充套件元件等方面都提供了各種各樣的功能。
在產品形態上，TKEStac分為平臺管理和業務管理，平臺管理控制檯為使用者提供叢集、倉庫、監控告警、擴充套件元件方面的管理，滿足使用者的叢集和平臺運維需求，業務管理控制檯為使用者提供業務資源、日誌、監控功能，滿足業務使用者的資源使用需求，同時許可權上的劃分增強了平臺的可用性。
TKEStaCk 功能圖譜
（5）TKEStack支援TMEC採用不同的部署模式
在TMEC方案中，TMEC有兩種部署模式，中心化部署和邊緣自治部署。
中心化部署情況下，在雲端中心部署TMEC管控平臺和TMEC業務服務，管理邊緣節點上的TMEC服務，這種模式下邊緣的節點和雲端中心處於同一個業務叢集。
邊緣自治部署模式下，分為雲端叢集和邊緣叢集，雲端和邊緣分別部署整套的管控平臺和TMEC業務服務，TMEC管控平臺之間進行跨叢集通訊。
TMEC使用者通過TKEStack的控制檯入口統一管理邊緣叢集和中心叢集，實現TMEC服務的部署更新和維護。
4. 應用場景
（1）雲遊戲
雲遊戲將遊戲渲染放在伺服器上進行，並將渲染完畢後的遊戲畫面壓縮後以視訊流的方式通過網路傳送給使用者。
在雲遊戲模式下，客戶端的遊戲裝置並不需要昂貴高階處理器和顯示卡，而只需具備基本 的視訊解壓能力和遊戲操作能力。
雲遊戲時代的到來，將會使玩家即便沒有高配置的遊戲硬體系統，也能暢玩高質量的3A 遊戲大作。雲遊戲能解決使用者硬體配置要求過高、遊戲包頻繁更新、遊戲外掛等問題，無需冗長的遊戲下載，實現即點即玩。
（2）多視角直播
多視角觀賽即使用者可以從多個角度來觀看同一場比賽，而不再限制於導播給出的單路畫面，比如籃球迷除了可以觀看正常的球場側方視角外，還可以從籃架下方、場邊VIP席等多個角度自由體驗籃球魅力。
利用TMEC部署邊緣應用，可以分別構建場館內多視角直播平臺和多視角直播分發平臺。既可以為演播人員提供本地快速編輯、 渲染、和極速分發等能力，也可以為終端使用者提供穩定、優質、低時延的觀看體驗。
三、 基於TMEC的車路協同實踐
1. 基於TMEC構建的V2X車聯網平臺
基於TMEC構建了一個車聯網 V2X 平臺，如下圖所示。底層是路側的基礎設施，在平臺層，提供多種V2X應用服務能力，為上層的應用開發和執行提供支撐。
2. 雲端V2X資訊處理：公路部署方案
上圖展示了典型的應用部署場景。車輛直接和路側的無線基站或者 RSU通訊，路側攝像頭和雷達等感測器資料送到路側MEC計算，然後通過無線基站或者 RSU 把道路的一些異常事件下發給車輛或行人。
3. 騰訊車路協同產品的特色
（1）面向應用的整合與定製
根據應用需求，聚合第三方能力，可利用既有道路資訊化設施，支援深度定製。
（2）廣泛的C端觸達能力
內建騰訊C端（微信、QQ及地圖等）觸達能力，充分發揮騰訊連結優勢，快速提升車路協同滲透率。
（3）高效的雲-網-邊協同
無線網路與資料中心融合，相容DSRC、C-V2X、4G及5G等多種網路，智慧排程管理邊緣應用，實現邊緣雲和中心雲的高效互動。
（4）靈活輕量化異構部署
輕量化支援物理機、虛擬機器、容器等異構部署環境，減少資源消耗，降低業務遷移難度，提升部署效率。
（5）強大的微服務治理能力
服務動態載入，區域感知，智慧熔斷，全天候監控能力，保證業務智慧執行，支援10萬+服務規模。
（6）完善的端到端安全能力
提供包括主機安全、網路安全、應用安全、通訊安全在內的全套安全解決方案。
4. 車路協同開放平臺
整個產品方案涉及到一個龐大的產業鏈，因而產業生態的建設是需要騰訊和各個廠家合作伙伴一起來完成的。目前在 4G 和 5G 網路上我們和業界主流的廠家都有合作，也做了大量的對接工作，和中國的三大運營商在現網也做了大量的測試驗證工作。
另外像車廠、車載終端、路測裝置廠家和軟體解決方案廠家，我們都歡迎他們參與平臺生態建設中來。
四、5G網路多接入邊緣計算展望
通過參與5G和行業標準、理論研究和實踐驗證，騰訊未來網路實驗室在 5G 和邊緣計算應用方面也積累了一些經驗，同時我們也在思考一些遇到的問題。
首先是 5G 標準的滯後和網路大規模建設需求之間的矛盾。我們看到3GPP 5G 網路標準一再推遲，R16、R17 網路標準沒有正式釋出，這就導致網路側的互通側缺乏標準介面定義。所以我們在和 5G 網路的裝置廠家去做對接的時候，需要大量的定製化開發，這對邊緣計算產品在現網的落地也提出了比較大的挑戰。
其次，整個生態目前參與方還是非常多的，大家的利益有很多互相交錯的地方。比如說電信運營商、電信裝置商和網際網路廠商在邊緣計算方面都會有自己的方案，而這些方案存在很多的衝突，包括邊緣計算基礎設施、邊緣計算平臺和網路等。如何保證各自的利益，是一個很有挑戰性的問題。
最後，業務方向選擇的問題。邊緣計算可以支撐To B業務和To C業務，BAT最早一直是做 To C業務的，做 To B 主要就是華為、中興這些裝置廠商和其它一些專業廠商。現在大家都在做 To B業務，競爭越來越激烈。然而 To B專案相對 To C 來說，從專案交付難易程度、利潤等各方面都存在挑戰。邊緣計算作為一個當下的熱點，催生出很多初創公司，對於這些公司，選擇 To B還是 To C ，同樣具有很大挑戰性。
Q&A
Q：該平臺c/c++開發是否有優勢？語言選型有推薦的嗎？
楊勇：TMEC裡面有一個微服務開發框架，它基於騰訊開源專案Tars構建，Tars支援各種語言的，包括 C、C++、Go、Python、Java和js 等等這種常見的語言它都支援，坦白來講 C++ 做一些高效能應用是非常有優勢的，但是C++的開發效率相對其它語言還是比較有挑戰性。
Q：這要真正的落地，這日誌維護是不是都是億級別的啊？
楊勇：日誌的儲存一般會採用兩級儲存，即邊緣雲端儲存和中心雲端儲存，日誌量會比較大，但是有方案可以解決。
Q：邊緣計算跟之前的 P2P 技術有什麼異同？
楊勇：我想這應該是兩個不同層次的問題，邊緣計算主要還是要解決在靠近使用者接入的位置為應用提供服務， P2P 主要還是解決使用者之間的資料共享和傳輸問題。
Q：邊緣計算，通訊協議是要多家機構商定和制定嗎?安全方面有一些什麼具體措施防止資訊洩露或被破壞？
楊勇：實際上通訊協議是個大概念，我不知道這裡邊指的通訊協議是指的哪一塊的協議，如果說是和 5G 網路對接的協議，目前一般都是按照 3GPP 的標準來的，因為標準相對比較滯後，所以現在很多廠家都自己定義了介面，比如說 QoS、 5G網路切片、本地分流等這些介面，都是我們跟廠家和運營商一起合作協商來制定的。3GPP 的標準出來之後，應該逐漸會向標準去靠攏的。
Q：客戶端需要什麼標識才能通過 UPF 路由到邊緣雲？
楊勇：按照廠家規範的功能，如果要把終端發往核心網的流量分流到本地的邊緣雲來，目前一般情況下都是按照IP五元組資訊來定義本地分流策略，比如說可以根據IP地址、埠號和協議型別等，我們目前和裝置廠家對接也都是按照這些策略來做的，因為絕大部分的應用它的協議和埠都是明確的，當然這些策略也可以支援動態的修改。
Q：請問這個方案裡面的upf以及5gc控制面是用運營商建的？還是你們自建的？
楊勇：是運營商建的，都是運營商現網的裝置，TMEC是作為在 3GPP 5G標準裡面定義的AF 的角色去和5G的核心網網元互動，來實現本地分流的。
Q: 5G是車聯網的強依賴嗎？目前4G的話能支援部分功能嗎？
楊勇：應該說 5G 和車聯網是密不可分的，但是部分功能 4G網路 也是可以的，比如說我們就和一個裝置廠家對接了在 4G 網路下的本地分流功能。只有分流功能具備了，這個邊緣計算平臺才能在上面部署業務，才能為移動使用者提供邊緣服務。在4G網路中由核心網網元SGW把流量送到TMEC平臺來。
Q：邊緣計算的計算載體是什麼？
楊勇：移動邊緣計算它實際上是邊緣雲和5G網路接入技術的一個結合，所以要說它的計算載體的話，主要是與雲端計算相關的一些產品和技術，然後上面再疊加一些5G網路相關的能力。實際上3GPP和ETSI定義的MEC，叫多接入邊緣計算，它不僅僅支援 5G 網路，包括 WiFi和固定網路，都涵蓋在 MEC 的概念裡。
Q：我們是做視訊分析，道路感知，事件檢測等，目前也落地了一些車路協同案例，怎麼加入你們的開放生態？
楊勇：剛才也講到了，整個產業鏈比較龐大，我們確實目前也是找了好多的合作商合作伙伴，每家都有自己的優勢。我們也歡迎相關廠家參與我們的生態建設。如果感興趣的話，可以聯絡雲加社群小助手，小助手會協助聯絡對接部門。
Q：Overlay網路是不是退出歷史舞臺了？
何猛：個人不認同此觀點，Overlay和Underlay屬於兩種不同的模式，適用於不同的場景，由於IPV4資源有限，Overlay可以方便的組建區域網，不消耗使用者IP資源，網路拓撲簡單問題排查方便，在AI、大資料的等對算力要求較高，對網路效能無太大要求的場景下還是有很大優勢的。
Q：聽到TKEStack介紹裡有部署k8s叢集。請問一下，我們們有沒有在傳統k8s做一些適配邊緣計算的工作？之前看到騰訊有做邊緣容器相關工作，不知道TKEStack是否支援部署呢？
何猛: 目前公有云容器服務下已經提供邊緣叢集功能，針對弱網、低資源等問題引入了新的解決方案，以後會選擇合適的時機在獨立部署版落地。
Q：TKEStack相較同行競品其優勢在哪裡，除了車聯網的探索之外，TKEStack還可以用在哪些領域？
何猛: TKEStack是一個通用的容器雲平臺，在使用上並不侷限於某一個行業或者是某一個領域，可以應用於這種車聯網，也可以應用於大資料 AI ，除基礎的容器雲平臺功能外，TKEStack在產品形態方面，為使用者提供業務許可權管理、對接已有的第三方許可權系統能力，在k8s叢集擴充套件方面，提供GPU虛擬化、TAPP原地升級等功能，特別是GPU虛擬化，cuda 劫持方案是一個原理上簡單，實現上很優雅的方案。
Q：容器相關的GPU和儲存方面產品在TKEStack裡面有具體實現嗎？
何猛: 平臺部署後可以在擴充套件外掛裡安裝GPUManager外掛，部署後按GPUManager的說明建立GPU負載即可體驗。TKEStack和GPUManager目前都已在github上開源，有好的想法歡迎提Issue和PR。
Q：在邊緣計算中，關注很多是負載均衡和訪問延遲方面的研究，請問目前騰訊平臺是如何設計的？
何猛：目前邊緣計算的方案已經在公有云上線，有這方面需求的可以體驗一番，目前還沒有開源，等方案更加成熟之後會在獨立部署場景落地。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
