如何在雲上構建容器化的科學計算平台？

導讀

一般來講，在雲端構建大規模計算集群是難以實現完整的資源自治的。那麼在計算任務運行容器化之後，應當如何進行雲上構建計算集群並對大規模容器進行管理呢？請看這篇文章。

演講嘉賓： 林帥康 | 晶泰科技雲計算平台技術總監，2015年加入晶泰科技，主要負責晶泰科技高性能計算平台(majorana)的研發工作，專註於在公有雲上通過mesos/k8s構建大規模的容器化高性能科學計算平台，以實現高效，低成本，靈活的雲上超算系統。

以下內容整理自分享：

我是來自晶泰科技的林帥康，今天我想和大家分享的主題是《雲上構建容器化的科學計算平台》。

晶泰科技(XtalPi)介紹

在講之前，我會對公司有一個簡單的介紹。這張圖主要表現的是在葯工業裡面做一款葯，從這個圖可以看出，大概會經過七個大的步驟，會花費6-10年的時間以上，才可以有一款真正上市。右邊看，葯最終到葯監局審批的時候，可能需要臨床實驗，小白鼠或者更高級的臨床實驗。我們主要關注的領域不會在這裡，主要是在前期的臨床研究。在臨床研究中，這是化合物的集合，我們需要從一萬個化合物選擇出250個可以符合臨床研究的化合物，從這裡再挑選5個精型出來做成一些葯制，然後開始臨床實驗，最終才會有一款葯真正上來，比如說可能是一個抗癌藥物。所以這屬於一個重磅藥物，經歷的時間周期比較長，畢竟生命還是很可貴的，做這種東西要非常小心才行。

晶泰主要致力於通過分子模擬平台以及藥物動力學、劑型預測技術，減少在藥物前期的研發周期，從6-8年可以減少到4-5年時間。它所依賴的技術，最右邊會有量子演算法，這主要是和科學計算相關，它可能會包括大家聽說過的蟻群演算法以及退火演算法等東西。再結合AI的融合，最終這兩部分會跑在超算的平台上面，例如我們熟知的天河2號或者新出的中國最大的超算中心。但是因為超算上面使用的資源可能會有申請的過程，而且使用量會有一定的限制，比如說一個小企業申請，有可能會限制只可用幾十台或者上千台，比較困難。

我們就會想到，現在雲計算髮展得非常快，很多企業已經從傳統企業轉換成雲上企業，已經成功落地。能否把傳統的科學計算移到雲上面？當然，現在很多公有雲平台已經在做，比較典型的產品可能是批量計算、高性能計算。我們把這兩部分技術結合之後，藉助騰訊雲和AWS去構建一個大規模的HPC集群，可能會達到百萬核實量級。核實在科學計算裡面是一個通用的概念，主要衡量計算池的標準，和超算用浮點的計算能力是一樣的，100萬核實怎麼換算？比如說每一台機器會有24核或者32核，1萬個核需要300台機器，100萬可能會到幾千上萬級的機器集群。

為什麼會需要那麼大量級的集群呢？這是我們的一個小分子藥物的劑型預測流程，我簡單介紹一下，大家有流程不清楚沒有關係，我可以打一個簡單的比方。左邊是分子輸入結構，你們可以理解為它是一個小的文本文件，裡面包含了一些化學參數，描述分子的見長和角度的旋轉。經過這個輸入，我們會有一個結構的搜索演算法，會產生億級的晶體結構處理，也就是很大的輸入池。

我們區別一些大數據公司，大數據可能有幾個T，或者PB級別的數據，在上面進行並行分析計算，而我們的輸入很小，就是幾KB，但是中間會產生大量的數據。我們可能還會經歷在科學裡面的能量篩選，以及基於CPU的聚合聚類演算法，還有高精度晶體結構的排位，最終得到我們想要的能量式圖的結果在裡面。這個流程中每個流程都需要計算來支持，這個圖是說每個過程中可能會需要多少量極資源在裡面。前期的幾個流程來看，需要的資源都可以在規模不大的集群裡面滿足需求。後面比較大，而且比較高，佔據了計算的很大部分，這就需要我們藉助雲計算的雲在裡面，可能需要把多個雲融合在一起，去構建一個比較大規模的資源池，在裡面跑相關的計算任務。

計算平台演變

剛才的介紹是想說明未來支撐比較特別的場景，可能需要一個大規模的資源池的支撐。在構建這個資源池的時候，有一個計算平台演變的過程，這個演變過程就不放太多的架構圖，稍微解析一下。我們公司從2015年成立的時候，也是從超算這邊開始脫離出來使用的。當然了，我們第一代平台有一個PBS調度系統，一般跑在超算上面都會有一個任務調度系統。相對於K8s這種複雜的容器編排來說是比較輕量級的。

還有一個NFS，可能大家對此比較清楚。當然了，超算的NFS工程和我們自己建的NFS肯定不一定，它是高通量以及IOPS都是幾十兆到上百萬兆網卡的支持。我們第一平台很簡單，都是使用開源的，在雲上主結點搭建PBS幾個G的內核就可以支持了，NS也是直接用開源的ABD Get一下，就可以產生一個掛載點，然後再掛幾十台，這樣基本滿足了我們前期使用的需求。

但是隨著業務的遞增，我們需要計算量越來越大，這兩個也有它們的局限性，例如有些資源利用率的不足以及LPS的性能不足，LPS壓測可能會焊住以及假死等等狀況。這樣我們就會有第二代平台的迭代更新在裡面，藍色這邊是我們開使用Mesos。我們2016年也有關注K8s，有一個簡單的轉型，但是當時K8s還處於比較早期的狀態，而且也沒有太支持批量計算服務在裡面，我們就選用了mesos。當時mesos比較火，在國內有很多公有雲都會根據它做一些第三方的插件調度軟體之類，我們也會拿mesos來管理我們的集群。

2016年2月份，我們開始用mesos，以及開始我們的容器化之路，真正開始用Docker去封裝一些高性能的計算演算法。在2016-2018年這兩年之間，基本還是沿用了mesos。中間這些都是為了去拓展、遞增我們資源池的實力數，比如我們開使用競價實力，一開始國內的競價實力還沒有興起，會使用不同的類型，這兩個也是出於成本的考慮，競價實力以及多個實力類型的搭配可以降低我們的計算成本。然後用Golang去重構我們的調度系統，因為任務量比較大，用來只用排產，性能上面會有一些瓶頸。

使用多個公有雲廠商，也開始接觸國外的谷歌、亞馬遜，以及國內的騰訊雲，我們有個多雲資源彈性伸縮與監控，最終就會開始使用K8s集群去管理現在超算上面也能跑的任務。這裡基本介紹了我們平台演變的歷程。

下面是現在的三代平台技術站。上面是我們現有的計算產品，主要是晶形搜索服務以及高峰量、精度比較高的計算服務，以及最終產出的報告工具。中間是剛才說的我們自研的演算法，以及融合現有演算法進行二次開發、封裝，打包成一個Docker鏡像，業務人員只要去使用這個Docker鏡像，就可以運行在超算上面的高精度的一些分子計算以及一些通用力場的計算。下面是支撐上面計算的平台架構的高性能平台，最上面就是雲資源。

它的架構是這樣的。左邊是業務前端，我們使用的Jupiter的Web服務，Jupiter大量用於科學家在線編程以及機器學習。下來是我們對輸入的文件進行一鍵化清洗和初步的分析，最終會到以對象存儲以及其他存儲空間組成一個數據壺，中間融合了一定的workflow操作在裡面，業務人員隨著提交任務計算，會不停的在每個階段對計算出來的結果進行分析，再去重新生成新的任務。

最右邊是計算平台的架構圖，有任務的管理、任務隊列、中間件，例如使用一個MQ對接了不同雲的集群，下面是某一個公有雲集群，例如是騰訊雲TKE容器集成在裡面。當然，我們還是會有兼任mesos集群在裡面管理。

騰訊雲容器服務實踐

這是我站在使用騰訊雲TKE的場景去做一些講解，沒有涉及K8s太深入的東西。我會在使用騰訊雲中做一個大集群構建時遇到的問題，也是大家可能面臨過，以及通用的一些解決方法，希望和大家有技術上的交流。

需要說明一下，我們關注的更多是超算計算和現在做的服務發布以及編排，可能有比較大的差異。科學計算工作負載的特點，主要是計算是密集型，時間持續比較久。雖然時間比較久，但是還是一次性任務，可能會持續幾個小時，幾天或者幾個一星期，最終有一個完成態的結果。它會追求演算法的執行效率，演算法直接導致了我們計算的成本，如果算得越快越準確，計算成本就可以壓縮下來。它會以一些工作站以及超算為主，傳統來說都是這樣的，直到這幾年超算開始搬上雲，才有雲超算系統。右邊是信息服務的特點，K8s應用的主要模式。

容器鏡像

雲容器服務，我可能會分幾部分來講。一個是鏡像，可能大家都使用過，但是對於超算，鏡像會和大家平時使用的鏡像不一樣，可能會包含一些比較大的科學計算軟體在裡面，每個科學軟體可能達到GB的級別，我們曾經打成一個包，可以達到10GB的鏡像在裡面，後面也有優化和分解，但是分解也有2-3G級別。

下面說集群空間以及集群擴容。擴容集群對於我們很重要，也是關於到成本的問題。因為我們擴容對於雲服務還是要求比較苛刻的，我們要構建一個一台台到三台台24核的機器，要求在20分鐘完成，有不停的任務去提交。而且在提交的過程中，我們要求這個集群裡面的負載是達到80-90%以上的。

我們使用CI也比較簡單，觸發一個drone的CI，然後輸入的SDK庫，SDK庫是我們一些科學家和量化工程師開發的專有演算法，去打包或者其他軟體，通過這個私有庫下載到Docker鏡像，根據Dockerfile去構建。拉取一些基礎的鏡像。然後把鏡像同步了AWS或者騰訊雲上面來，最終有一個發布通知的過程。

右邊有一個鏡像分層的結構在裡面，基礎鏡像比較熟悉了，第二塊比較特別一些，有HPC Images在裡面。我們會使用一些現有比較有名的二進位軟體在裡面，這些軟體都是在固定的平台去編譯的，有的有源代碼，有的沒有源代碼，他們在固定平台編譯的時候，因為雲服務發展得比較快，例如騰訊雲可能又推出一些新的機器類型，它的CPU指定級以及其他一些架構有變化，老的NEG系統跑起來，可能跑著跑著就會死掉，還有一個性能的問題，它可能沒有用到一些優化的CPU指令集，比如說ABS的一些指令集，然後會導致效率上下降20-30%。

如果大批量使用，這是很大的成本量。我們會針對不同的平台有智能化的構建，去適配不同的當前在騰訊雲上面用的機型，以便它能對應在某一台機器跑的時候，不至於是跑了一個錯誤的鏡像在裡面。下面有一個工程的鏡像在裡面，就是剛才說的演算法開發組上傳的一些SDK，最終是Docker跑起來運行池狀態。

鏡像負載我剛才稍微解析了一下。有一些科學技術軟體可能會達到GB的級別，打包幾個進去可能就會達到幾個G或者上10G的樣子。我們可能會對鏡像進行一些裁減，裁減完之後可能會有一個鏡像預拉取，也會考察當前能否有一些方法可以加速鏡像的拉取。因為我們最終裁減還會會有一些軟體保留在鏡像裡面，所以在公有雲這邊，例如騰訊雲提供的TKE來進行鏡像任務編排的時候，有時也會發現大批量拉取的時候，鏡像拉取比較慢，而且會有超時操作動作，有可能是雲服務鏡像倉庫的問題，也有可能是因為網路的問題以及等等問題。

雖然騰訊雲已經在上面提供了自建的平台，但是我們也要看是否有一些優化的方案。現在是K8s集成雲來託管，但是也許有一天我們可以提供A準的主機徑下功能可以定製化開發的，我們可以改變參數。後來我發現，最新版的K8s已經支持動態修改Kubulet參數。

下面這三個參數可能會涉及到鏡像拉取的性能以及並發率。第一是串列鏡像拉取，通常情況下是forest，官方文檔上面說，如果執行錯，可能會對老版本的Docker以及使用NUSFS的後端存儲會造成一些影響。我們現在平台上的Docker版本都比較新，這個參數開啟可能會對我們有一些幫助。第二是鏡像拉取超時，到底要設多久，可能和我們大鏡像經驗值有關，可能會有10分鐘。Docker這邊可能會有並發拉取的參數在裡面，也可以去調節，加速任務分發時減少鏡像拉取時間，儘快把任務跑起來，畢竟時間就是金錢。

講完鏡像，開始真正講K8s集群的構建。我們當然是基於騰訊雲伺服器的TKE來構建，之前是叫CCS，現在叫TKE了。它現在的構建方式相對於之前我們自己手動構建的方式更加方便，基本一鍵就可以構建出一個帶有Master的K8s小集群在裡面，有點像集群即服務，我這個集群可以通過一種服務的方式提供出來，你可以隨時刪掉或者創建。

騰訊雲這邊也打通了和其他每個一些雲服務的服務，例如監控、hap、安全的以後一些服務在裡面，用起來還是比較方便的。TKE會提供一個API出來，但是它提供的API主要還是針對一些服務編排，真正去做高性能計算的任務提交，我們現在還是用原生的client-go來做的。右邊是一個K8s高可用的集群架構。

我們來看一下，現在K8s已經發布到1.11。現在它支持不超過五千個結點，在集群裡面不超過1.5萬個pod，以及不超過30萬個容器，大概結點不超過100個pod。會有這些限制在裡面。對應到我們的應用需求，我們當前的大概集群規模可能會達到100-3000個結點，可能大家會覺得這會小於它的結點數，應該比較安全。但是因為我們用的是大機器類型，每個機器都是24核或者32核類型，如果稍微拆小一點，用18核或者16核，可能機器數就會翻倍。

下面有一個紅色標，這個pod數就會超出了它的限制，可能是1000-70000個pod。容器和上面相同，稍後我會解釋為什麼相同。pod單個結點一般會有1-24，我們目前是用24的機器。下面產生這個數據的原因有這麼幾點，我們的SBC單機的配置要求比較高，可能是24核或者32核的大機器類型，現在一個pod對應一個tast，就是一個pod會跑一個任務。

我們最小的一個pod是多少？需要的CPU是一個核，24核在最極端的情況下會跑24個任務，就會有24個pod在跑，這樣算起來就超過它的限制。我們還會有單次提交任務量比較大的情況，例如我們單次會提交10萬個任務，如果你不控制任務提交速度，把10萬個任務都提交到K8s裡面去，即使資源都起來100台，但是已經有9萬多個任務在等待了，這對它的其他組件是有一個衝擊性的，特別是一些周期性查詢的組件在裡面。

我之前使用騰訊雲，坦白講還是遇到了一些問題，畢竟現在國內公有雲上的K8s集群還相對來說不是完全的特別成熟，特別是面對我們這種使用情況比較特殊的，構建集群也比較大，任務隊列也比較長，這需要有個定製化開發，或者慢慢去調試的過程。左邊是我們遇到的一些問題，比如說Kubectl請求超時，推薦一個命令，加-V可以列印每請求一步請求到哪裡，以及到哪裡去超時，可以定位到相應的問題是請求到一個API還是別的地方。K8s調度嚴重延時，這也是因為任務隊列過長的一個主結點集群性能下降，可能會有調度的退避演算法在裡面，即使Node上面有資源，但是這裡卡住了，不會把相應的pod調進去。

還有K8s-dns負載過高，如果每個pod裡面都會有一個dns請求，就可能單次有上萬個pod去跑，對K8s-dns去請求。因為K8s-dns還是比較輕量級的，它雖然有一個負載過程在裡面，但是還有可能會拉垮它，API不可能開始出來，以及ETCD讀取延時變大，因為提交任務比較大，每個任務通過job去創建，那麼在ETCD上面就會有對相應的數據存儲，以及ETCD可能還會有一個事件對象存儲在裡面。K8s容器網路不可用也是和其他相關的。

這邊中間是我們和騰訊雲這邊有一個測試過程，發現了一些問題，剛才的導師也說針對一些特殊的任務，要做定製化Master集群的構建，要把大集群拆分，以及把Master配置上升，通用可能會上升到最頂配，32核或者是60G的內存級別。ETCD原來只是一些機械存儲，也可以改成SSD的存儲。etcduf的分離和讀取時延時優化相關，數據拉取和數據事件響應可以分開，通過前面的負載可以保證Kubernete、Kubecontrol以及其他一些事件請求可以得到及時的響應。

右邊是我們自己做的調度系統的優化過程，盡量用K8s的job類型，因為經過測試，相比job類型，它在EDG上面存儲的數據會多一些，數量比較大，可能就會有上G、上10G的差別在裡面。我們也會控制任務的提交速度，我們之前也有考慮過這一點，但是當時也是比較信任K8s，所以一股腦把很多任務都積壓上去，不用去管，讓它慢慢去調度，保證整個集群都是一直高負載的，不然我們可能調度這邊還要周期性輪巡當前K8s的自營狀態。

在Netwook host方面，一些批量的任務之間沒有網路通信，都是獨立的離線任務，它用容器網路和不用區別不大。DNS host方面，騰訊雲的同事反映，訪問外部服務時可以直接通過主機的DNS host就可以，不需要走K8s-dns。後面我們還有另外一些任務類型需要DNS host、K8s-dns來支持。這邊主要是一些優化的點。

K8s官方也提供了一些構建大集群的輔助文檔在裡面，但實際上你在構建的時候還是會有形形色色的問題在上面是沒有提及到的。

K8s主結點集成已經由騰訊雲給我們構建出來了，接下來肯定是要添加計算結點在裡面，通常情況下都會提供彈性伸縮組融合在裡面。目前大多數都會實現了K8s官方的社區版實現。我們的要求主要出於節約成本的目的，一定要高度彈性的以及快速擴縮容，因為它會涉及到我們案例報告產出，我們有一個案例有一個周期，需要在特定的時間內輸出這個報告。

但是我一次性提交10萬個任務，可能會要求幾天之內要把這個任務算完，所以單次的彈性資源有可能是0-1000/2000個結點一起跑，然後跑完之後又從2000個結點縮放到0的結點，會有這種場景在裡面。大概是這樣子，也就是說我8點的時候就開始提交任務資源，從8：20提交得隊列比較長在這裡了，我們就會限制一個流控。稍微了解一下K8s彈性伸縮的原理，是根據pending pod的數目進行觸發的。

我們可能要求20分鐘之內擴到4萬個資源在裡面，也就是2000台機子在裡面。這個任務量比較大，算的時間比較久，可能從今天8點算到明天9點大概會算完，因為任務的輸出很多時候都會有相似性，所以計算的周期相似，那麼就會有一大批任務會釋放出來。到這裡就會有一個比較長的曲線在裡面，這也會影響我們的成本，我們稱之為長尾的任務，也是一個遺留的裝箱問題，我們還沒有實現K8s的重調度以及任務可重調度斷點去算的功能在裡面。

稍微提及一下，因為了解K8s的可能都會知道。剛才我們提到了擴容機制，可能調度失敗的pending pod數量同我們配置伸縮組裡面的配置，例如有一個1萬個是調度失敗的，那麼我們現在配置的伸縮組可能就是每個機器類型是24核，它就會計算出相應的機器類型，會有分批的添加計算資源，達到調度的效果。

基於這種情況，我們會想怎麼阻止pod被重調度漂移，官方提供了一些參數，例如在cistern上面的空間，這些pod不會漂移，還有一些外部存儲的pod也不會漂移。但是我們不讓它漂移，剛才有一個長尾的情況在裡面，最終到9點的時候，因為這一千台機器的任務都是分散調度的，在調度時並不知道這個任務是多長多久的，最終會導致有一些長任務分布到每一台機器上面去，所以大部分任務跑完之後會發現有很多機器上面單獨跑了一兩個任務，每個任務可能就佔8核，那可能每台機器有16核的浪費，有幾百台機子都是16核，其餘去等待幾小時讓它算完，就有資源浪費的情況。

當時我們考慮支持斷點續算的功能，斷點續算在我們這邊的實現原理也比較簡單，可能說當HPC job周期性算的時候，我們有（英文）的動作在裡面，把中間的結果保存下來，就像進程調度一樣，有上下文壓占和出佔一樣，就是說開個（英文）上傳到對象存儲，過了幾個小時，發現有大批量的釋放之後，整個集群的資源利用率會下降，這時候就可以觸發這個重調度，把這些佔用了結點資源，但是只是佔用了小部分可以做一個漂移，它漂移到另外新的結點，就可以從對象存儲裡面把之前的上下文下載下來，重新開始它上一步計算。當然，這個重調度計算還是會有一定的機時在浪費，因為（英文）這邊有一個周期，可能會浪費一個小時，我們通過這個情況縮短了它浪費的力度。這裡主要是資源利用率的問題。

搞定了集群的構建以及快速的擴縮容之後，就開始提交任務。稍微解釋一下，現在高性能遷移的任務過來有哪些。從時候維度來看，分短時間任務和長時間任務。當然，其實它對應的具體實現演算法可能是只要在單結點裡面跑就OK了，還有需要多個結點協同去跑的，比如說那些流體計算，可能一個任務拆解成了幾十個小任務，需要在幾十台或者上百台機器上面去跑單個任務。

二是低精度和高精度任務。在藥物計算裡面中會有精度要求，從右邊圖來說，不同的科學計算軟體對於輸出進行不同的演算法計算，會有一個精度的差別，也會反映在時間上面。往往低精度的演算法要求的時間比較低，但是高精度演算法比較耗機時，使用資源量比較大，最終計算的精度就比較高一些。上K8s，我們選擇過用developm還是用job類型，我們曾經用過developm來做，但是對於K8s主結點還是產生壓力比較大，job類型在今年算是比較成熟的類型了，也是面向高性能計算來定義的。我們的任務類型從核數來說，分為1、2、4、8、16核，也是為了實現裝箱的問題，提高資源利用率。

當然，可能還會從其他維度來分，它是一個計算型，裡面可能又分為計算需要的內存比較大一級計算需要的存儲比較大。當然，目前大部分都是普通的計算型，就是說存儲和內存一般按機器分配1：2，比如說按4核來說，就會有48G內存，1：2就OK了。右邊是我們現在使用到的job類型，可能看得不太清楚，裡面會有紅顏色標誌下來比較重要的參數。我們會用到一些外部掛載，例如騰訊雲的CFS這種情況，還會用到一些Docker或者K8s默認的內存共享會比較小，比如說幾十兆、上百兆，其實有的科學計算軟體可能需要幾百兆共享內存，如果運行池比較小，就會導致宕機，目前我們會通過某些解決方案讓它擴大，我們之前也在K8s上有提及這種方案，掛載了外部一個Net host進入裡面去充當共享文件存儲，但是往往掛載的是一個的文件類型，會導致pod無限重啟的問題，有待後續開發方面有更新的支持。

任務裝箱現在主要是依賴K8s，我們後期也會考慮有一個對等調度K8s支持的定製化調度，這樣K8s本身的功能會退化成資源的管理者，有點像回到了mesos開發模式在裡面，但是它提供了其他的特性，我們還是可以用到，例如它的容器網路以及一些外部可插拔的硬體，例如一些GPU、IP網路或者是一些高性能的網卡。然後是job的生命周期管理，這比較簡單，每個job都會有一個生命周期管理，我們定義成它是一個rending或者是被殺死、休眠狀態以及被（英文）狀態，最終會反映到我們的隊列資料庫上面，它是實時和K8s的job pod狀態去同步的。

這邊是一個單結點的任務定義，下面說我們現在支持的HPC多結點並行的任務。了解過高性能計算的人，都會通常意識到現在一些公有雲的普通網路沒有辦法滿足MPI數據並行任務。MPI需要一個高性能的網路，可能是幾倍、幾十倍的萬兆網卡，需要一些專有的網卡去支持遠程的直接內存訪問。

通用的概念是，有兩台機子，這台可以通過網路去訪問那一台的內存，就像我在本機訪問的速度一樣，延時是非常低的。當然，這需要一些專有的網卡。運行任務的運行周期會相對長一些，右邊是我們在K8s實現的MPI任務。剛才提及現有的TKE提供的網路沒有達到通用的MPI的網路要求，但是我們會其中篩選出一些可以在雲上面跑的MPI任務。它們結點之間的數據交互通常是比較少的，這樣它們走的網路數據傳輸也比較少，這樣就可以避免高性能網路的限制，但是還是會有很大的局限性，在網路發展裡面肯定會接觸很多流體力學計算在裡面，現在這種情況是沒有辦法滿足的。

但是剛才看老師的解析，我們也關注到現在公有雲陸陸續續會上一些裸金屬的機器在裡面，機器上面會配備一些高性能的網卡。並且K8s這邊有一個叫做（英文）插件支持的機制在裡面，可以直接把RDMA網卡或者其他高性能的網卡插到上面去，跨過了OS以及TCBIB網路層，可以實現低延時的數據分發在裡面。右邊這個圖是InfiniBand性能和百兆網卡性能（英文）區別，可以看到它的測序是OpenMPI以及MPICH兩個開源的MIP庫，右邊時間明顯比左邊時間長很多，因此它是依賴於高性能網路提高計算效率的。可能大家還是接觸比較少，我稍微提及一下。

任務的性能監控剛才已經提及到了，容器雲這邊已經提供了比較健全的服務監控。當然，我們可能會出於一些其他的需求，需要實時監控pod CPU以及內存。目前不會去監控網路吞吐，所以我們也會搭一個heapster+influxdb+grafana開源架構在裡面，去收集我們想要的信息，去對比演算法版本更新的時候會否導致CPU的運行效率下降和內存變多，但是因為任務量比較多，所以存儲的數據會比較大。

下面有個kubelet10250埠的參數，我們之前碰到一次，剛剛創建集群的時候，在安全組上面太粗心大意了，沒有把計算結點10250埠封掉，導致會被人家入侵，因為它開啟了enable-debugging-handlers=true 的情況下，外部可以直接通過這個埠，到pod裡面進行集群調試，我們發現有人通過掃描機器，在上面跑了一些外掛程序。大家使用的時候稍微注意一下，官方已經有一個PR在裡面。

日管理依賴騰訊雲，對接了Kafka和ELK，不詳細說了。前面是騰訊雲的容器服務實踐，遇到了一些痛點。騰訊雲容器發展得還是比較快的，但是它也不可能覆蓋所有的應用場景，通過我們和它的合作，一是滿足業務的需求，一是可以推進它更好的做一些比較少見的服務，例如高性能計算，在這方面可以完善得更好。

未來規劃

下面是我們對未來的一些規劃。我們也比較關注云容器實例服務，這已經在K8s TKE層面上再推進了一步，集群的主結點創建和彈性伸縮都不需要管理了直接通過騰訊雲這個介面提交相應的任務，上面就可以跑起來了。所以這方面落地更加方便一些，serverless lambda大家也比較了解，在高性能應用中也會使用到，一些比較小的排位任務，可能是一分鐘的任務，但是它有幾百萬量級的東西，就可以通過serverless lambda來實現。完善的作業工作流管理剛才在架構圖中也提到過，對於一些複雜的預測流程，任務之間有嚴重的依賴關係。例如這個圖中，job2、job3、job4是依賴job1的輸出文件作為輸入文件，後面的job5、job6也是依賴前面文件的。如果中間有一個任務出錯了，在開發的過程中可以重走這個工作流去，節省到前面幾個任務的計算流程直接到job6，繼續往上面走，繼續修復以及類似的循環這樣去做。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！