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

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

以下內容摘選自部分演講速記，完整速記、音頻和 PPT 請掃描文末二維碼獲取。靈雀云微服務架構師 賀洪龍

為什么要上云原生？這是靈雀云微服務架構師賀洪龍老師在演講開始時問大家的問題。其實，傳統的架構轉向 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 虛擬化的難點，并具體解釋了騰訊和英偉達在 GPU 虛擬化上的不同。怎么在容器內使用 CUDA？容器可以做到 CPU 內存和 CPU 核的隔離，包括細分到 0.01。GPU 的最底層是 GPU 的設備，上面是 GPU 運行的環境。

騰訊是做法是：

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

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

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

GPU 虛擬化也涉及一些選型問題，英偉達 GPU 虛擬化存在一些問題：

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

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

另外，英偉達基于 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 的方式直接接入邊緣節點，這種方式是比較依賴一個邊緣網關、EdgeHub。另外它使用 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 資源。

點擊

總結

以上是生活随笔為你收集整理的k8s停止服务_使用 K8S 几年后，这些技术专家有话要说的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。