導語 | 5G網絡下,多接入邊緣計算(MEC)應運而生。結合TKEStack強大的集羣管理能力和異構計算資源管理能力,騰訊打造了一個功能完備的邊緣計算PaaS平臺TMEC,提供了高精確度定位、視頻處理、無線網絡QoS控制和5G切片等多種特點業務能力,很好地支撐了車路協同、5G雲遊戲、視頻直播等應用。本文是騰訊雲技術專家楊勇&何猛老師在「雲加社區沙龍online」的分享整理,但願與你們一同交流。c++
自動駕駛在國際是很是熱的話題,業界的標準分紅了不一樣的等級,有的分紅了5級、有的分紅了6級。git
如上圖所示,國家工信部相關規範將自動駕駛等級標準定義爲6級。目前國內的廠家和國際的一些廠家,絕大部分處於處於L2或者L3的水平。騰訊也有自動駕駛相關的產品,目前有數百人的團隊從事自動駕駛等相關產品和技術的研發工做。github
從實踐落地的角度看,自動駕駛汽車商用的成熟性目前來看並不高,這中間存在不少問題,其中技術、成本和安全是阻礙自動駕駛產品規模商用的主要因素。後端
典型的自動駕駛車輛涉及到硬件和相關軟件的系統性挑戰。主要包括如下四個方面:安全
第一是高精地圖,其中包括釐米級精度、豐富的路標數據和三維重建能力。服務器
第二是多傳感器,其中包括攝像頭、激光雷達、毫米波雷達、超聲傳感器、慣導和衛星天線等。微信
第三是環境建模及智能決策,其中包括多傳感器融合感知、道路和區域識別、環境模型構建、智能預測和決策等。網絡
第四是車身控制,其中包括車輛自動控制、駕駛策略執行及規劃。架構
整體來看,在目前的水平之下,整個自動駕駛車輛由於要安裝多種傳感器、工控機及系統控制軟件,成本比較高昂,並且激光雷達等傳感器的使用壽命也比較有限。業內人士曾經估算過,自動駕駛車輛的成本不會低於20萬美圓,這極大阻礙了自動駕駛汽車產品大規模商用落地。負載均衡
即便自動駕駛車輛配備了這麼多的專業傳感器和其它專業設備,在一些異常狀況下仍是不能很好的解決實際路況上出現的一些安全問題,包括特斯拉在內的自動駕駛汽車曾出現屢次交通事故,致使財產損失和人員傷亡。
好比,在超視距的狀況下,車載傳感器包括雷達或者攝像頭檢測不到轉彎前方的車輛,或者從街角對面駛過來一個車輛,就很容易發生交通事故。
剛纔也提到了從成本的角度來說,自動駕駛車輛的成本是很是高昂的。
另外從出行效率角度來說,做爲交通管理部門或城市市政管理部門,提高交通出行效率是他們主要工做目標之一。但自動駕駛車輛在道路上行駛的時候,考慮安全因素,會相應採起一些比較保守的策略。
好比說它的行車速度可能會比較低,同時在發生異常事故的時候,它會減速或者停車避讓,這就使得整個交通的效率並不能獲得有效的提高。
綜合以上因素業界提出了 C-V2X 這個概念,這裏面的 C 是蜂窩網絡的意思, V2X 的全稱是 vehicle to everything,就是說,基於蜂窩通訊的 V2X 技術,使得車輛和道路全部參與方都能進行實時的數據交換,經過這種信息交換,來進一步提高包括車輛和其它參與方的安全性,同時提高出行效率。
咱們看到 V2X 主要包括四種場景:
第一個是 V2V(車輛對車輛),它主要解決一些車輛之間的可能發生的一些異常情況,好比說車輛碰撞事件;
第二個是 V2I,就是車輛和路邊基礎設施,好比紅綠燈等,經過車輛和紅綠燈的數據交換來及時提醒車輛減速或者保持必定車速,引導車輛經過綠波帶,既能提高行車安全,也能夠提高車輛出行效率。
第三個 V2N,經過和通信網絡的交互來爲駕乘人員提供一些個性化信息服務。
第四個 V2P,經過和行人之間的數據交換,來爲行人或非機動車發出一些安全提醒。
C-V2X 的目標整體上涵蓋信息服務、交通安全、交通效率和輔助自動駕駛,它的目標之一就是把單車解決不了的問題移到路端去解決,經過路側設備和車輛之間的 C-V2X消息交互來進一步輔助自動駕駛,提高交通安全能力,提高道路出行效率,造成「聰明的車」和「聰明的路」。
那麼按照「聰明的車」到「聰明的路」的想法,咱們是否是能夠將徹底依靠自動駕駛車輛自己所具有的智能決策能力給它遷移到雲端上去實現?這樣還能夠大幅下降車輛的購置成本,並且由於雲端有高性能、可擴展的計算能力,能夠作不少車端勝任不了的計算任務。
另外咱們知道,如今自動駕駛汽車在車端要作大量的基於計算機視覺或者雷達數據的路況實時分析,這種高性能計算在車輛計算單元上的處理,其準確性等方面還有待提高,若是能移到雲端去作,準確性可能會提升不少,並且雲端還能夠作不少複雜的算術和邏輯運算。
可是這裏有一個問題,即雲端計算存在的時延問題。自動駕駛智能決策的時延要求很是高,若是移到雲端去計算,整個數據鏈路拉長勢必形成時延的增長,這就可能給自動駕駛業務帶來嚴重的影響。例如車輛在高速公路上以120千米/小時的速度行駛,每秒鐘就能行駛 30 多米,時延增大就可能會引起嚴重的交通事故。
因此移到雲端是個不錯的想法,但它又帶來了時延方面的負面因素,這種狀況就爲邊緣計算的部署提供了一個契機。也就是,把雲端那些計算任務移到路側的邊緣計算平臺上來進行,經過在路側的基礎設施上部署邊緣計算平臺和車聯網的應用,從而對車輛進行實時的智能提醒和決策。
在靠近網絡接入的路側基礎設施上進行邊緣計算,它的好處是很是明顯的。第一,計算能力大幅提高,有利於準確度的提高;第二,不須要佔用過多的核心網或者骨幹網絡帶寬;第三,能夠有效下降時延,在網絡的邊緣側只要經過基站就能夠直接將消息分發給路上的終端,數據傳輸路徑比互聯網到無線核心網再到無線接入網的路徑短了不少,這就是邊緣計算在車聯網中應用的背景。
邊緣計算在車聯網裏面會發揮着重要做用,目前咱們看到各地關於 C-V2X 的新基建建設項目,重點的內容就是 C-V2X應用 和 MEC 服務的建設和部署。
上圖展現了無線網絡的架構圖及MEC在網絡中的位置,左邊是一些終端,經過5G基站接入5G核心網絡,最終抵達互聯網上部署的各類業務。其中核心網分爲上面的控制面設備CCF和下面的用戶面設備UPF。
控制面有不少的功能實體,這些功能都是 5G 網絡專用的核心網網元。MEC須要部署在邊緣UPF附近,經過本地分流能力將手機用戶的業務請求引導到MEC上,由MEC上部署的應用爲其提供服務。
好比說,一般狀況下手機訪問英特網上的業務,其訪問路徑是經基站設備到邊緣UPF,再經本地UPF匯聚後進入因特網,最後到達雲主機,這條路徑比較長。
而在邊緣計算場景下,業務部署在邊緣UPF附近的MEC上,數據傳輸路徑明顯短了許多。當用戶訪問一個邊緣應用的時候,咱們經過本地分流將用戶的請求直接引導到部署在基站側的 MEC 上,這樣它的流量就在靠近網絡邊緣被處理了,既不佔用後端的核心骨幹網絡的帶寬,同時又能下降手機訪問網絡業務的時延,優點顯而易見。
在這種背景下,騰訊提出了邊緣計算 TMEC 解決方案。
整個解決方案分紅三個層次,最上面是業務層,是TMEC支持的主要的邊緣應用,好比雲遊戲、視頻直播、智慧出行、智慧影視、智能製造等。咱們看到這些業務絕大部分都和視頻相關,這是由於視頻在網絡中佔的帶寬很是大,邊緣計算能夠很好地解決視頻相關應用對網絡帶寬的佔用,同時保證手機端的用戶體驗。
中間層是平臺層,咱們知道騰訊雲有很是豐富的中間件服務,能夠爲上層應用提供豐富且可靠的基礎業務支撐能力。
最下是基礎層,它是 TMEC 平臺的基礎支撐,咱們採用騰訊雲自研的容器平臺TKEStack來實現。
下面簡單介紹幾個TMEC上部署的特點業務能力。
TMEC 一個重要的特點業務能力就是 5G 業務能力。
要實現5G業務在邊緣計算設備上的部署,必須支持5G網絡流量從 UPF分流到邊緣計算站點。於是,引流是MEC平臺的基本功能,經過與核心網的交互,將終端發給核心網的數據流量依據MEC業務的要求分流到MEC站點並分發給MEC業務處理。
如上圖所示,3GPP標準定義了引流功能的實現。目前引流有多種方案,比較成熟的是基於上行分類器UL CL的引流方案,目前騰訊已經和多個設備廠家進行了對接,實現了從核心網UPF網元到MEC 流量的引導。
TMEC還支持 5G QoS 和網絡切片能力,能夠爲部署在 TMEC上的應用提供一個可靠的無線通信 QoS 保障。網絡切片是 5G 重要特徵,TMEC支持爲邊緣應用建立專門的網絡切片,來進一步保證應用的服務質量。目前這些工做騰訊已經在現網和設備廠家及運營商之間進行了對接。
視頻類應用是邊緣計算典型的應用場景。TMEC提供有高質量的視頻轉碼能力,它是基於用戶感興趣區域ROI的視頻編碼技術,經過這個技術能夠在不影響用戶體驗質量的狀況下,將碼率下降30%以上。
從上圖中能夠看到,TKEStack是屬於基礎平臺層的解決方案。基礎平臺層主要解決的問題是爲上層業務提供計算資源支撐,解決上層業務的各個服務在服務生命週期內的對計算資源、存儲資源、網絡的需求問題。
隨着容器技術的發展,容器化的服務能夠在集羣上自由的遷移,服務的可靠性和穩定性獲得了更好的保障,同時也帶來了一些問題,好比:容器如何編排?編排框架上手難度較大,如何部署和維護?如何節省服務依賴的日誌、告警、網絡組件的部署維護成本?多個k8s集羣如何管理等等問題,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 集成了日誌和監控報警等功能,經過擴展插件形式,一鍵部署,解決了上層平臺的日誌報警需求。
上面咱們簡單介紹了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 功能圖譜
在TMEC方案中,TMEC有兩種部署模式,中心化部署和邊緣自治部署。
中心化部署狀況下,在雲端中心部署TMEC管控平臺和TMEC業務服務,管理邊緣節點上的TMEC服務,這種模式下邊緣的節點和雲端中心處於同一個業務集羣。
邊緣自治部署模式下,分爲雲端集羣和邊緣集羣,雲端和邊緣分別部署整套的管控平臺和TMEC業務服務,TMEC管控平臺之間進行跨集羣通訊。
TMEC用戶經過TKEStack的控制檯入口統一管理邊緣集羣和中心集羣,實現TMEC服務的部署更新和維護。
雲遊戲將遊戲渲染放在服務器上進行,並將渲染完畢後的遊戲畫面壓縮後以視頻流的方式經過網絡傳送給用戶。
在雲遊戲模式下,客戶端的遊戲設備並不須要昂貴高端處理器和顯卡,而只需具有基本 的視頻解壓能力和遊戲操做能力。
雲遊戲時代的到來,將會使玩家即使沒有高配置的遊戲硬件系統,也能暢玩高質量的3A 遊戲大做。雲遊戲能解決用戶硬件配置要求太高、遊戲包頻繁更新、遊戲外掛等問題,無需冗長的遊戲下載,實現即點即玩。
多視角觀賽即用戶能夠從多個角度來觀看同一場比賽,而再也不限制於導播給出的單路畫面,好比籃球迷除了能夠觀看正常的球場側方視角外,還能夠從籃架下方、場邊VIP席等多個角度自由體驗籃球魅力。
利用TMEC部署邊緣應用,能夠分別構建場館內多視角直播平臺和多視角直播分發平臺。既能夠爲演播人員提供本地快速編輯、 渲染、和極速分發等能力,也能夠爲終端用戶提供穩定、優質、低時延的觀看體驗。
基於TMEC構建了一個車聯網 V2X 平臺,以下圖所示。底層是路側的基礎設施,在平臺層,提供多種V2X應用服務能力,爲上層的應用開發和運行提供支撐。
上圖展現了典型的應用部署場景。車輛直接和路側的無線基站或者 RSU通信,路側攝像頭和雷達等傳感器數據送到路側MEC計算,而後經過無線基站或者 RSU 把道路的一些異常事件下發給車輛或行人。
根據應用需求,聚合第三方能力,可利用既有道路信息化設施,支持深度定製。
內置騰訊C端(微信、QQ及地圖等)觸達能力,充分發揮騰訊連接優點,快速提高車路協同滲透率。
無線網絡與數據中心融合,兼容DSRC、C-V2X、4G及5G等多種網絡,智能調度管理邊緣應用,實現邊緣雲和中心雲的高效交互。
輕量化支持物理機、虛擬機、容器等異構部署環境,減小資源消耗,下降業務遷移難度,提高部署效率。
服務動態加載,區域感知,智能熔斷,全天候監控能力,保證業務智能運行,支持10萬+服務規模。
提供包括主機安全、網絡安全、應用安全、通訊安全在內的全套安全解決方案。
整個產品方案涉及到一個龐大的產業鏈,於是產業生態的建設是須要騰訊和各個廠家合做夥伴一塊兒來完成的。目前在 4G 和 5G 網絡上咱們和業界主流的廠家都有合做,也作了大量的對接工做,和中國的三大運營商在現網也作了大量的測試驗證工做。
另外像車廠、車載終端、路測設備廠家和軟件解決方案廠家,咱們都歡迎他們參與平臺生態建設中來。
經過參與5G和行業標準、理論研究和實踐驗證,騰訊將來網絡實驗室在 5G 和邊緣計算應用方面也積累了一些經驗,同時咱們也在思考一些遇到的問題。
首先是 5G 標準的滯後和網絡大規模建設需求之間的矛盾。咱們看到3GPP 5G 網絡標準一再推遲,R1六、R17 網絡標準沒有正式發佈,這就致使網絡側的互通側缺少標準接口定義。因此咱們在和 5G 網絡的設備廠家去作對接的時候,須要大量的定製化開發,這對邊緣計算產品在現網的落地也提出了比較大的挑戰。
其次,整個生態目前參與方仍是很是多的,你們的利益有不少互相交錯的地方。好比說電信運營商、電信設備商和互聯網廠商在邊緣計算方面都會有本身的方案,而這些方案存在不少的衝突,包括邊緣計算基礎設施、邊緣計算平臺和網絡等。如何保證各自的利益,是一個頗有挑戰性的問題。
最後,業務方向選擇的問題。邊緣計算能夠支撐To B業務和To C業務,BAT最先一直是作 To C業務的,作 To B 主要就是華爲、中興這些設備廠商和其它一些專業廠商。如今你們都在作 To B業務,競爭愈來愈激烈。然而 To B項目相對 To C 來講,從項目交付難易程度、利潤等各方面都存在挑戰。邊緣計算做爲一個當下的熱點,催生出不少初創公司,對於這些公司,選擇 To B仍是 To C ,一樣具備很大挑戰性。
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:在邊緣計算中,關注不少是負載均衡和訪問延遲方面的研究,請問目前騰訊平臺是如何設計的?
何猛:目前邊緣計算的方案已經在公有云上線,有這方面需求的能夠體驗一番,目前尚未開源,等方案更加成熟以後會在獨立部署場景落地。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公衆號,及時獲取更多幹貨!!