每日最新頭條.有趣資訊

使用 K8S 幾年後,這些技術專家有話要說

9 月 7 日下午,在深圳南山軟體產業基地,騰訊雲 K8S & 雲原生技術開放日成功落幕,來自騰訊、靈雀雲、超參數科技、虎牙等資深技術專家與現場開發者共同探討企業落地 K8S 的過程中遇到的難點以及解決問題的方法。

K8S 逐漸成為容器編排的標準,越來越多的實現方式和使用方式已經成為了標準化的流程,但是在應用容器化、DevOps、監控、性能調優、發布方式等方面仍存在一些技術難點。在學習和實施容器交付的時候,我們對於 K8S 的認知和理解多少會存在一些偏差;在一些項目落地實施時,開發者經常會對 K8S 本身沒有包含的問題或者是沒有解決的問題而感到束手無策。騰訊雲 K8S & 雲原生技術開放日邀請多位技術專家,就和大家聊聊在 K8S 中存在哪些問題,以及如何解決這些問題。

靈雀雲微服務架構師 賀洪龍

為什麽要上雲原生?這是靈雀雲微服務架構師賀洪龍老師在演講開始時問大家的問題。其實,傳統的架構轉向 DevOps 的架構,有點像以前 C/S 架構轉向 B/S 架構,這是一個必然的趨勢。不只是互聯網公司適合用雲原生,其實傳統企業一樣適用,像中石油、海關總署、一些央企或者是大型的部委,他們現在也非常關心整個核心系統的更新換代,這個需求並不是來源於業務或者技術的角度,部分是出於管理的角度。實現雲原生要做到兩點:一是能夠統一企業所有內部的應用架構,包括中間件都可以統一;二是要做舊系統的遷移。比如一個部委的核心系統可能是 10 年前開發的,而如果開發一個新的核心系統要上線的話,開發周期有可能要兩年。那麽遷移的時候,原系統下有幾百個子系統,如果還是採用單體結構,實現難度非常大。而且現在政府的系統其實對於互聯網的需求很多,以前一套系統可以跑 10 年不用更新,現在的系統分分鐘要修改、要迭代。因此對雲原生架構的需求就變得非常強烈。

DevOps 的價值體現在哪裡?

一是可以快速投放市場。有多快?每天迭代 N 個版本,賀洪龍提到,「我記得是 2016 年,某銀行信用卡中心一周時間迭代了 183 次,每天差不多有幾十次的小版本迭代,用藍綠版本迭代,這樣頻繁的發布也只有通過 DevOps 才能實現。因為這個銀行信用卡中心的運維伺服器開發得很早,從 2014 年就開始做了,最開始是跑虛擬機。據我所知,做發布的兄弟們三個月走一批人,經常需要通宵,他們都受不了;相反,用容器來做,基本上可以不用加班,用兩套環境,一套藍、一套綠,下午做好部署,晚上一切網絡就可以了。」

二是降低成本。有 DevOps 工具之後,可以減少人工投入,進而減少因停機時間帶來的損失。以手機制造廠商為例,他們的應用要發布,中間如果要停機,停一個小時損失 300 萬。如果發布要 4 個小時,那就是 1200 萬。而手機制造廠商的 IT 部門一年的投入也就一個億。所以,通過 DevOps 基本上可以把 IT 的投入賺回來,這就是 DevOps 的價值體現。

三是 DevOps 可以讓開發者不用做一些低價值的事情,包括安裝、部署、配置都可以用工具來做。DevOps 可以讓運維人員做一些更高端的事情,類似於運維架構師的角色。DevOps 平台可以滿足整個生命周期管理的需求,從最早的項目管理、需求再到構建、代碼,到最後運維。

騰訊高級工程師 盧承山

騰訊高級工程師盧承山從實踐的角度,重點介紹了雲智中樞 AI 中台的建設思路,該平台要打通設備、數據、上層的應用,讓應用開發者基於該平台,通過服務編排減少用戶的開發量。

雲智中樞 AI 平台是從 0 到 1 構建是思路是:

(1)技術選型,比如用什麽微服務框架,用什麽容器平台。

(2)算法,算法可能有上百種,如何接入,並且發布成一個應用。

(3)AI 產品怎麽落地。還有一個持續交付的問題。

很明確的是,用容器、微服務已經是一個趨勢了。在架構選型方面,騰訊雲容器服務 TKE 基於其強大的 K8S 的原生能力,同時對整個交付集成有一套完整的體系。

騰訊雲最新推出的企業級容器雲平台 TKE(Tencent Kubernetes Engine )基於成熟的 Kubernetes 技術和生態,能夠幫助企業快速構建自身的私有化容器管理平台。TKE 企業版在架構設計過程中作了針對性優化,通過採用與騰訊公有雲容器服務一致的架構和管理模式,可以幫助企業在私有化管理容器服務的同時,便捷地打通雲上的容器服務並獲得一致的管理體驗,實現混合雲部署。

另外,TKE 企業版還充分利用了騰訊內部微信、QQ、遊戲等重量級業務在容器使用方面的經驗,例如 GPU 虛擬化用於解決 GPU 共享問題 ;TAPP 應用管理用於讓服務管理更加精細化、發布過程更加可控 ; 在離線混部技術提升資源利用率降低成本等。

騰訊自己開發的服務,包括算法服務,都能接到 K8S 裡面去,其實這個已經比較成熟了,但是有些組件,包括一些存儲性的東西,分布式文件存儲或者 MySQL 存儲等等,業界也有相關的方案,但是從整個的穩定性來說,存儲目前還是用的物理機的方式,除了服務以外的存儲還是用的物理機。那怎麽接入算法?最原始的方式可能是讓它提供二進製包或者類似的方式來幫它做。我們最終提供的就是鏡像製作的方式,最終都是通過鏡像。如果用戶提供了一個二進製包,怎麽幫他們做鏡像?這裡其實有兩種對接方式,第一種直接對接其鏡像。這是最簡單的,也有容器平台。第二種是自動構建鏡像。比如說它還是物理機或者是虛擬機的方式,它提供的可能是一些包,我們幫它自動做鏡像。我們把每個環境抽象成一個組件,比如說你需要 JDK、OpenSL 等等環境,我們把它抽象成一些組件,你只需要把包選出來在你的頁面上,這裡就是一個可視化的操作,你可以在我們的平台構成完做成你的鏡像,把你的二進製包上傳。

這裡有個難點,怎麽縮短鏡像製作的耗時?一個原始的 GCC 編譯可能需要一個小時,CUDA 的安裝也需要 20 分鐘,做一個鏡像如果環境變複雜,是不是需要一兩個小時才能做一個鏡像。那怎麽縮短時間?思路是:第一次製作有可能確實需要花這麽長時間。另外,騰訊也抽象了幾點,把 GCC、CUDA 和鏡像的版本做了綁定,因為是常用的,所以會做成基礎鏡像,每個用戶製作的內容都會在後台分析,用戶最耗時的以及最頻繁使用的,可以在後台幫你分析,做成一個模板鏡像,下次做的時候不會基於 Linux 來做,它可以基於鏡像模板機來做,它的耗時明顯就會減少。

盧承山也介紹了 GPU 虛擬化的難點,並具體解釋了騰訊和NVIDIA在 GPU 虛擬化上的不同。怎麽在容器內使用 CUDA?容器可以做到 CPU 記憶體和 CPU 核的隔離,包括細分到 0.01。GPU 的最底層是 GPU 的設備,上面是 GPU 運行的環境。

騰訊是做法是:

一、最底層的兩層是在物理機層面的,需要把它掛到容器上,最上層的 CUDA 是在鏡像層面做的。

二、解決在使用容器過程中 License 的問題。

算法服務和普通服務不同的地方在於,算法廠商不希望這個服務你拿去就用,它有一些鑒權,不可能把服務給你。最早都是物理機過來的,它依賴物理機設備上的東西。怎麽把這些東西掛到容器內,它依賴 MAC 地址,而容器的 MAC 地址是虛擬的。騰訊在這裡面做了一部分改造,把物理機掛到容器,然後再做 License 的鑒權。

GPU 虛擬化也涉及一些選型問題,NVIDIA GPU 虛擬化存在一些問題:

第一是物理層面,NVIDIA是在 CUDA 的驅動層面來做的,雖然性能很好,但由於是在虛擬機層面做的,因而不適合容器。

第二是它不開源,而且收費。既然不開源,出現各種問題你就很難去查。

另外,NVIDIA基於 MPS 做了一個軟體的 GPU 虛擬化,要求必須平均分配,這會造成資源的浪費。比如,它是把一張卡虛擬成 0.01 之類的。使用一張卡其實很浪費,以一張 P40 的卡為例,很有可能你的算法根本用不到。基於這個痛點:騰訊做了一個選型,也是在 CUDA 層面上做了一層,所有的調用都是轉到這個後面,再去調 CUDA 的底層,但是我們這個不會對 CUDA 底層的東西做任何改動,只是中間加了一層。

超參數科技高級研發工程師 朱恆滿

超參數科技高級研發工程師朱恆滿從 AI 與遊戲的角度,講解了遊戲 AI 在實踐中遇到的難點以及解決問題的思路。遊戲 AI 近些年來在學術界已經有了很多的探索,在最近幾年出現了比較顯著的成果。2013 年 deepmind 在 Atari 的遊戲上超過了人類,但是在當時並沒有引起很大的轟動,在 2016 年 AlphaGo 擊敗了國際頂尖的圍棋選手,使得 AI 有了很大的進展。最近,deepmind 和 OpenAI 分別在 rts 和 moba 遊戲裡面戰勝了職業選手,資源不斷升級,規模也是越來越大。

遊戲 AI 的實驗流程:首先在本地是一些算法的設計、迭代,包括一開始去體驗遊戲,感受遊戲需要怎樣的特徵,設計怎麽樣的流程更好;然後是模型的參數調整,做一些小範圍的參數設置;接下來就是做一些大規模的實驗。強化學習主要是 CPU 和 GPU 混合的異構的計算,規模會比較龐大。那麽,現在 AI 真實對戰的能力指標是不是已經達到我們的預期了?如果達到預期,實驗就可能會停止;如果達不到,就會再回溯到之前的各個模塊,看看在特徵方面有沒有什麽需要改變;最後就是保存模型。

那為什麽要做一個平台化?

首先是因為計算模式的複雜性。目前,強化學習在 K8S 上的編排模塊比較多,包括 GPU、CPU 生產數據等方面,還有中間做了一些緩存。這麽複雜的模式,如果沒有做平台化,需要寫很多的腳本,對於個人而言,很難掌握大規模、複雜的系統。另外,比較重要的一點是計算模式需要能夠被複用。整個迭代流程更多的可能是修改參數,或者是一些模型、特徵,其實整體的框架是不會動的,這就需要提供一些可複用的計算模式,進而可以提供對算法模型來說更加直接的分布式能力。

其次是資源需要被更高效地管理和利用,這也是 K8S 賦予的能力。如果是個人或者團隊分配機器,利用率是很低的,包括自己的業務可能需要去協商可以用哪些機器,這個流程非常拖遝。同時,也存在資源競爭的問題,比如兩個人都想用 GPU,一台虛擬化的機器只有一張卡,怎麽分配?還有就是個人很難管理這麽大量的機器。

最後,平台的通用化分析能力,可以開放給算法同學,包括算法的監控,硬體和業務的監控。另外,在日誌處理方面,通過日誌去判斷一個 AI 是不是已經達到了能力上的需求,這裡會有一些指標,包括模型方面的要求;還可以做日常定位的工作;在數據管理方面,訓練數據和模型都需要做管理。

虎牙直播高級開發工程師 王玉君

因為虎牙直播業務方面的特性,它有很多業務是部署在邊緣節點,因為涉及到主播推流等,對網絡質量要求比較高,也在嘗試邊緣機房的建設。目前,虎牙有一些測試的機房,預計會在今年 Q4 完成生產環境的建設。這是目前的現狀:虎牙現在 Node 機房有 700+ 物理機,Pod 有 7000 多,應用程序在 350+,這些數據還在不斷增加。有時候有一些賽事需要緊急擴容,一天就會擴容 100 台,虎牙會根據實際的業務情況來增減。

虎牙直播高級開發工程師王玉君分析了虎牙直播應用 K8S 的背景以及目前實踐的一些思考。虎牙現在有一些 K8S 集群是搭建在公有雲平台上的,目前用到了騰訊雲、阿里雲、AWS。對比這三家,騰訊雲 TKE 可以大幅節約成本。比如說一台虛擬機上跑 10 個容器和跑 30 個容器是有本質差別的。虎牙當時也實踐了不同的平台,在騰訊雲 TKE 上,一台虛擬機可以跑到將近 40 個容器,它還可以提供更多的密度。

通常情況下,K8S 如果直接提供給業務方,API 等方面用起來不是很方便,包括一些 CI/CD 的流程,如果沒有把業務打通,用戶是不願意遷移上來的,因為要考慮自己的應用性成本,包括後期的部署,一些變更的成本等。虎牙一站式服務可以實現從代碼編譯到部署,所有的環節都幫助用戶在頁面上實現,用戶只要在頁面上點一下,就可以在很短的時間內把新版本發布。

之前有用戶不願意上雲,擔心業務被其他人影響。虎牙使用了TC 限速策略,做了一些容器的限速,有稍微的改動。如下圖所示,左邊底下這些三角形是容器,出向限速在左邊,右邊是入向限速,底下藍色的方框是 TC 的模塊。如果這個網卡是 1000M,左邊這個圖有兩個方塊,虎牙做了一些優化。因為機房用 BGP 的模式,要保證它有一個獨享的帶寬,不能被其它所干擾,否則對路由有影響。右邊這部分就通過 filter 分給不同的容器,然後有一些不同的策略。右邊這一塊只是限出不限入,也是用開源的方案,通過一個網卡轉發,網卡數據包進來,再出去,通過限制網卡的出速,相當於限制了容器進來的速度。

那麽,邊緣節點如何接入?

如下圖所示,左下是數據中心,master 跑在數據中心裡面,邊緣節點分布在各個地方,它如何接入數據中心呢?圖中右邊這部分是通過公網直接接入集群,這種方式有很多風險,比較嚴重依賴虎牙自研的防火牆設備。比如說 K8S 的業務運維或者是系統運維,在擴容邊緣節點的時候,它會先跟安全部門進行申請,開白名單,然後接入才能成功,跨部門的溝通是非常影響效率的。左邊這一塊是通過 IPsec VPN 的方式直接接入邊緣節點,這種方式是比較依賴一個邊緣網關、EdgHub。另外它使用 VPN,在同樣的鏈路下,它會有一些性能上的損耗。

基於這一點,虎牙結合 K8S 的特性做了一些邊緣節點更新的方案:

(1)用戶可以直接通過公網接入。

(2)系統管理員不需要找安全部門開白名單。

通過 kubectl 或者 Restful API 向 master API 發起一個授權,進而推送一個資源,安全資源有變更時,會把配置後的信息發送到一個源數據服務,源數據服務會實時更新該插件上的防火牆配置,業務的節點就會比較快速地接入集群。這樣做的好處是:邊緣節點分布在各個地方,edge mate 可以進行統一的管理,它會把邊緣配置下發到各個節點,然後對自身進行配置,提供一種邊緣集群的對外訪問能力。

另外,原地升級是對 K8S 比較好的一個補充。如果要進行升級,按照 K8S 現在的方式,會把 pod 銷毀重建,這樣業務是不答應的,所以原地升級可以 pod 不變,業務容器也不動,只是把 Sidecar 容器做一個更改。當集群的規模到一定的程度之後,有很多的業務要進行更新操作,更新的時候會對調度器帶來一些壓力,這是可以完全避免的。從這一點上看,K8S 原生設計上對規模比較大的集群還需要一定的優化。從資源鎖定的角度,資源不足的時候被內部搶佔,也可以通過原地升級來解決,因為 Pod 根本沒有銷毀,所以 pod 的立面沒有改變,其它的 pod 不會調到這一台物理機上,不能達到 pod 鎖定的目的。

騰訊高級工程師 杜揚浩

Harbor 是目前唯一的一個也是最流行的一個開源企業級鏡像倉庫解決方案。Harbor 除了包含最原始的鏡像功能以外,還包含用戶圖形界面,以及它的認證、鑒權模型;同時,它還支持病毒掃描、鏡像的複製。另外它也支持一個 RestfulAPI,這對企業來說是非常重要。最後 Harbor 也比較好部署,現在 Harbor 支持兩種部署模式。

騰訊高級工程師杜揚浩在演講中主要介紹了 Harbor 的優勢以及應用過程中的經驗。他提到,目前 API 可以滿足大部分企業的需求,但是隨著企業的業務越來越複雜,應用越來越多,原有的 API 就有點不夠了。杜揚浩舉例說,「我查詢過一個倉庫所有的鏡像列表,它最開始提供的 API 裡面並沒有企業用戶所需要的一些信息,比如需要對某個用戶進行過濾,或者對某個資料欄進行過濾,這時候它的 API 就不能滿足企業用戶的需求。」

這時候就有一個問題,怎麽在不改變 Harbor 的情況下來適應企業級的需求?

有兩種方案:第一種是內嵌式的修改方案。直接修改 Harbor API,讓 Harbor 實現 API;另一種是非侵入式的方案。在 Harbor 的外面另外配置一個適配器,所有對 Harbor 的適配操作全部通過 Harbor Adapter 改造,無需修改 Harbor。

這兩種方案相比,使用非侵入的方案,需要幾百行代碼來完成這個邏輯,如果用修改 Harbor 代碼的方式,可以通過幾行代碼實現一個非常簡單的功能。但是內嵌式的方案有一個很大的缺點,它對 Harbor 是有侵入的,當 Harbor 升級、修改比較多的時候,維護成本隨之會增加,有可能當 Harbor 進行了一個版本升級的時候,企業內定製的 Harbor 也需要進行升級,就需要一個完整的路徑來進行升級的工作。

對於非侵入式的 Harbor 修改方案來說,優點也很明顯,唯一需要注意的是 API 的向下兼容。如果它的 API 不能實現向下兼容,就需要進行適配,它的缺點就是一個效率問題:可能一個很簡單的操作,就需要很麻煩地拚湊才能實現同樣的效果。還有就是對一些有狀態的數據的操作,比如需要在 Harbor 原有的數據的模型下再插入一些數據,在外部就不是那麽好做,還需要在裡面存儲一份數據,這份數據還要和 Harbor 原有的數據合並,這並不適合採用侵入式方案。綜合來說,在滿足性能要求的情況下,可以接受非侵入式對 HarborAPI 調用的損失。但更值得關心的是,這種升級所帶來的維護成本。因為這種非侵入的方案有利於 Harbor 的升級和維護,當開源的 Harbor 升級的時候,可以用很少的工作量完成 Harbor 的遷移和升級。

Harbor 雖然支持完善的認證和鑒權機制,但是企業內部一般都有自己定製的認證和鑒權邏輯,而這些特殊邏輯是無法通過 Harbor 現有的方式來兼容的。怎麽在不修改 Harbor 的情況下進行認證和鑒權?

首先是無侵入的認證和鑒權。它的核心就是把認證和鑒權從 Harbor 內部遷移到 Harbor 外部。現在的流程是平台調用認證中心,由企業的認證中心來完成這個認證和鑒權,當認證和鑒權通過之後,再調用 Harbor 的 API 來執行相關的操作。執行完相關的操作之後,還需要把對應的 RBAC 的資源寫入到認證中心,這樣就可以實現對 Harbor 的無侵入認證和鑒權修改方案。API 的認證、鑒權無侵入方案存在的一個問題就是,它不能兼容 docker 命令行,因為它不是使用我們的平台 API,它是由 dockdemo 加入,所以這裡面還要對認證和鑒權的命令行做一個無侵入方案。

在企業生產環境裡如果需要部署 Harbor,要進行高並發來壓測一下。杜揚浩在演講裡對比了基於普通的 CephFS、基於對象存儲和文件存儲這三個環境的壓測對比。

Harbor Ceph FS 壓測

Harbor Rook FS 壓測

Harbor Rook Ceph RGW 壓測

通過壓測數據得出結論:隨著並發量的增加,三種存儲平均拉取時間都在增加,而且成功率也是越來越低。10 個並發的時候是 100%,30 個並發是 92%,600 個並發是 73%,當然這裡面很大的原因是 Harbor 本身的 bug 問題。可以認為 rook 的文件系統和普通用物理機搭建的文件系統性能接近,rook 的對象存儲的性能是遠高於 rook 搭建的文件系統的。

除了剛才提到的對象存儲的性能本身就優於文件系統之外,為什麽 Harbor 壓測結果有這麽高性能的提升?

經分析可知:一方面,Harbor 切換了對象存儲之後,它在與 docker 互動的過程中會採用一個重鏡像的技術,這樣流量就從 Harbor 切換到對象存儲的服務裡面來,Harbor 就不需要轉運站數據,節省了 Harbor 自己的一些資源以及時間。另一方面,數據由 Harbor 切到對象存儲之後,流量瓶頸和並發瓶頸就由 Harbor 轉到了對象存儲,所以,基於上面的兩個原因,就導致了 Harbor 在切換對象存儲之後,它的性能有了一個質的提升。

還有比較重要的一點是關於 ceph 文件系統的備份還原。對於 Harbor 的 ceph 文件系統來說,Harbor 的數據實際上是落地在文件系統的某一個路徑上,這裡備份的原理就很簡單:通過 PV 獲取到它的路徑,然後把這個路徑 mount 到本地的文件系統,通過這個文件系統進行一個壓縮或者備份。文件系統的還原就是剛才備份的一個逆過程,只需要把備份的數據打入到剛才 mount 的文件系統裡面就可以了。

對於 ceph 的對象存儲來說,它的備份還原的原理實際上是一樣的,但是它的具體實現就有點區別:因為對於對象存儲來說,它的數據不是保存在某個路徑下,而是保存在對象存儲的 bucket 的概念中,所以如果要對 Harbor 的對象存儲進行備份還原,就需要對這個對象存儲中 Harbor 所對應的 bucket 數據進行備份還原。

在現場提問環節,部分參會者也問到了關於騰訊雲容器服務 TKE 的問題,為什麽選擇 TKE?開源自建 K8S 與 TKE 的對比如下:

想了解更多?掃碼回復:TKE即可免費獲取本次技術開放日完整 PPT 資源。

獲得更多的PTT最新消息
按讚加入粉絲團