在 12 月 22 日 ECUG 的下午場 ，七牛雲容器計算部技術總監袁曉沛為大家帶來了主題為《基於 K8S 的 DCOS 之路》的精彩分享，向大家介紹了七牛容器雲目前 K8S 的狀況和產品思考。

同時，他在會上講述瞭如何通過七牛公有云業務容器化的操作實踐，組建 K8S 翻譯團隊，對《Kubernetes in Action》這本書進行落地的翻譯。

以下是演講內容的實錄整理。

大家下午好！我是七牛雲容器計算部技術總監袁曉沛， 我今天想分享的是七牛雲基於 K8S 的 DCOS 之路，結合一些實踐經驗，講一下我們在其中做的事情和產品層面的思考。

我今天會先講一下七牛雲內部業務容器化歷程，然後講基於 K8S 的 DCOS，七牛雲在做一個更強大的 K8S 發行版，它體現在三個地方：一是底層技術的穩定性。做一個更強大的 K8S，技術穩定性是使用者第一時間關注的；二是功能的擴充套件性。如果一個系統不滿足需求時，就要考慮它的擴充套件性怎麼樣，能不能基於開放性介面實現；三是易用性。K8S 是非常複雜的系統，如何保證它的運維、使用非常簡便，讓終端使用者可以快速入門。最後，會簡單介紹 K8S 周邊的生態，包括上下游及應用生態，以及應用生態豐富性。

七牛雲內部的容器歷程

七牛雲從 2014 年開始做容器，當時啟動的專案叫 QCOS，它的全稱是「Qiniu Cloud Operating System」。當時我們通讀了 K8S 的設計草案，我們認為自己有能力做這樣一個系統。然後我們從零開始自研了一套容器叢集排程管理系統，這個事情做了兩年。2016 年底時再回頭看，發現一個容器叢集排程管理系統要做的事情非常多，要包含 CPU 和記憶體排程（計算力排程）、網路管理、儲存外掛、應用相關處理(日誌、監控、告警)，這是一個非常大的系統，幾乎沒有幾個公司有能力從零開始做這件事情。當時來看，唯一的可能性是谷歌，因為他們有一套 BORG 服務內部多年，而 K8S 是由 BORG 系統設計理念演化過來的。於是我們在 2016 年底決定全面轉向 K8S，而且 100% 相容 K8S。

現在是 2018 年底，我們近兩年做的是七牛雲內部的 5 大業務 K8S 容器化：最早是測試系統，現在七牛雲的測試已經全容器化；第二個是多媒體轉碼系統，也是全容器化的；第三個業務是七牛雲 AI 業務，AI 有大量 GPU 機器，需要基於大量資料集做 AI 學習和訓練，所以我們是基於 Kubernetes 之上做了機器學習的平臺，我們為這個平臺做了很多擴充套件功能；第四個是大資料，大資料 Spark 業務在我們的容器應用市場上，作為一個應用，讓使用者可以快速部署。

我們在本季度正熱火朝天做一件事情，把七牛雲最核心的物件儲存業務搬到容器雲上，這個事情已初步驗證通過，正在切量過程中。到現在為止，七牛雲的幾大業務線都有大量應用執行在容器之上。從 2018 年下半年已經對一些外部客戶輸出容器產品，結合七牛雲過去五年容器化經驗，把我們好的技術、理念、功能打造成產品開始對外輸出。

容器化帶來了什麼

容器化到底給我們業務帶來什麼？

第一點，員工開心。交付部署效率大幅提升。原本從一行程式碼的提交到測試再到生產的上線，可能需要幾天甚至幾周時間，而且上線之後可能會不穩定要回滾，基於容器技術，可以把整套過程用 CICD 和 DevOPS 理念整合到一起，一行程式碼提交之後，可以讓這行程式碼變更編譯成一個映象自動跑單元測試，跑完單元測試可以跑程式碼靜態檢查，也可以加一些自定義指令碼，然後整合測試，最後是 CD 持續部署，線上連線起來。釋出週期可以從幾天、幾周到分鐘級甚至秒級。這個過程中，最簡單的變化是員工很開心，開發、測試、運維，都可以早點下班，不用等到凌晨四點業務低峰時釋出。

第二點，使用者開心。運維排錯效率大幅提升。一個容器平臺預設就提供了容器的監控，系統級別 CPU 和記憶體監控、入口級別的監控報警，甚至日誌也可以自動收集起來。一個寫得很一般的後端應用執行起來之後，平臺都能為它提供一些基礎的日誌監控，如果業務做一些適配，業務級的監控也可以被收集到，這些整合起來就是全鏈路的日誌監控和告警機制。如果線上出現問題，基於監控日誌和告警，可以大幅降低從錯誤發現到錯誤解決的時間，降低 MTTR ，提高應用的可用性。應用的可用性提高了，客戶受到的影響就會越來越小，本質上來講是客戶更開心了。

第三點，老闆開心。因為機器資源的利用率大幅提升。在一個數據中心裡可以用一個 K8S 叢集來管理所有物理資源，讓所有業務在一個計算資源大池子裡做業務混部，然後利用率提升了，從原來不到 20% 的資源利用率，最高可以提升到 60%、70% 以上。對公司來講，降低了企業 IT 成本。從這一點來看，沒有老闆會不開心。

基於 K8S 的資料中心作業系統

做了這麼多事，我們收穫了很多好處，然後就在思考我們本質上在做什麼事情。本質上我們是在做一個數據中心作業系統。原來機房裡一堆機器的管理，本質上是通過機器 IP 再加一個 SSH 埠號，無論使用什麼部署工具，都是把一些應用推上去，更改配置，啟動這個應用，是通過 IP 地址和 SSH 埠跟這些機器打交道。但有了容器之後，跟資料中心互動的介面完全發生了改變。我們使用程式設計化介面，操作和排程資料中心的 CPU 和記憶體，不用在意業務到底被排程到哪一臺機器上，甚至可以用 API 的方式操作日誌、監控、報警。所以，我們是在做一個數據中心作業系統。

K8S 已經是一個數據中心作業系統了，而我們是在做一個更強大的 K8S 發行版。

更強大的 K8S 發行版，需要具備什麼呢？

我們總結了三點：第一是底層技術的穩定性，商業公司站在背後支援，保證技術是更穩定的；第二是豐富的擴充套件功能；第三是易用性，對於平臺運維來講是否易部署、擴容、升級，對於終端使用者來講是否容易使用，都是至關重要的。此外，一個完善的作業系統，除了自身功能之外，還需要提供必備的上下游服務和上層應用。

底層技術穩定性方面，我們每天都在迭代。這是我們近一兩個月在做的事情，我們在網路模型上，etcd 分離部署，與 K8S etcd 互相不影響，使用 etcd V3 API 作為資料庫，效能提升 2 倍；使用 BGP route refletor，關閉 Full Mesh，大幅提升效能。

舉例說明，大家可能都不會太關注的點：KubeDNS，社群預設版本效能只有 99.5%，意味著不工作時候可能超過 3 個小時。我們做了一系列改進可以把 KubeDNS 可用性從 99.5% 提升到 99.999%，每個月不可用時間不超過 25 秒。實際上過去三個月不可用時間是 0。

有人可能會問七牛云為什麼在這麼小的事情上較真，做這麼多事情。對容器雲團隊來講，每一個元件都是這種心態做優化。因為使用者打到七牛雲的每一個請求，存在我們這裡每一個檔案，都是對我們的信任。我們對使用者有一個承諾，我們要讓系統盡無限可能接近 100% 的可用性。

擴充套件方面，系統層面針對 Nvidia GPU 監控和排程做了優化，定製排程器確保 GPU 的排程效能，開發了 K8S 整合 AlluXIO 儲存外掛，通過這個外掛可以讓 AI 訓練使用 AlluXIO 快取海量檔案。第二，我們在靜態本地磁碟上啟動了一個新的 Kubernetes SIG，基於這個很多人可以一起貢獻程式碼，把靜態本地磁碟供給做好。在網路上基於 vlan/vxlan 實現 SDN，支援二層網路隔離。

這是基於 CLI 的日誌自動收集方案。主要原因是一個容器往往需要往多個目錄打日誌。但按照容器標準，只能往標準輸出和標準錯誤裡打日誌，這樣很難收集擴充套件多個目錄的日誌。CLI 是 Container Logging Interface 的縮寫，它讓整個方案能夠對接任何現有的日誌方案，比如可以對接七牛雲的 Pandora，也可以支援 ELK、Splunk。

這是日誌收集方案的使用方式。

作為一個容器平臺或者資料中心作業系統，很關鍵的一點是易用。

平臺的運維很關鍵，很多容器產品關注的是這個產品很好用，但實際上容器平臺的運維更難，因為 K8S 管理著整個資料中心，業務大了之後，K8S 平臺自身的運維更重要。

第一是部署、擴容、升級的便捷性。我們的目標是 5 分鐘部署一個新叢集，秒級擴容一個新節點。K8S 是開源生態，開源有很多安全性問題，我們如何在升級新版本時，讓當前叢集上的業務不會影響，這是一個非常關鍵的因素。

第二是叢集資訊視覺化，包括宿主機、系統關鍵元件，L7、L4 入口的監控、日誌、告警。如何通過平臺監控資訊發現機器或者系統元件、入口層面的問題，通過平臺快速定位業務問題，這都是叢集視覺化要做的事情。

第三是常見故障自動化處理，我們實現了一種機制，可以讓故障自動探測、一鍵解決。

這是平臺運維管理介面。

這是具有自動化運維處理機制的工具，每一臺節點上都會執行這個工具，它能做到自動化探測，外掛方式都是自動化探測已知現象，把這些上報到 K8S api-server，採取措施自動修復一些問題。

從使用者使用層面講易用性，我們是以專案為中心，對使用者有強大的管控能力。傳統專案都是先有虛擬專案再有人，然後是機器和軟體。我們完全按照這樣的方式管理專案，把 K8S 資源空間當做一堆資源，往專案裡新增。專案裡可能有項管、運維、測試、開發，每一個不同的人決策許可權不一樣。

然後是強大的應用編排能力，很多 K8S 平臺為了追求編排的易用性而犧牲了相容性，等使用者對這個平臺和 K8S 足夠熟悉之後，使用者可能就會要求平臺和 K8S 完全相容，意味著通過 K8S API 建立的資源必須通過平臺顯現出來，或者通過平臺建立、編排的資源可以通過 K8S API 操作，正向和逆向都可以，所以我們產品 100% 相容原生 K8S，並且相容 kubectl。

最後一個是強大的映象空間管理能力，國外映象同步、映象加速、私有映象託管；C2I：基於程式碼、單元測試、靜態檢查，構建可交付映象；映象檢查，基於一些工具檢查映象，看它裡面是否有存在安全風險的東西。

以上是使用者易用性上需要考慮的點。

這是使用者使用產品的介面，應用編排、應用列表、應用服務編排。

一個強大的資料中心作業系統，還需要一個比較完善的周邊生態。持續部署和 Kubernetes 打通，上面可以通過 HELM，右上角是 ISTIO，基於 ISTIO 做流量管理功能，比如灰度釋出、熔斷、鏈路追蹤，幫我們快速發現問題。

七牛雲基於 K8S 實現了常見的資料庫中介軟體服務，包含 MySQL、MongoDB、Redis、RabbitMQ。這些運維工具本質上就是由 Operator 實現的高可用服務，支援一鍵部署，能做定期備份和恢復，保證資料的可靠性。本質上是把公有云的 RDS 服務搬到 K8S 上，讓非公有云使用者使用高質量的資料庫服務，大幅度減輕 DBA 的工作負擔。

這是七牛雲當前在 K8S 社群的全球排名，我們排第 26 名。可能會有人問，到底有多少人在開源，我的回答是我們沒有一個人專職做開源，也沒有把做開源當成很刻意的事情，是在維護 K8S 的穩定性、擴充套件功能、提高產品可用性的過程中，貢獻一些東西。因為我們受益於開源，所以這些改進，新的功能我們都儘量直接貢獻到開源。但我們不做三件事情：不去改拼寫錯誤、增加單元測試、改註釋。

這是七牛容器雲團隊和七牛雲內部一些小夥伴翻譯的一本書，書的名字是《Kubernetes in Action》（中文版購買連結：https://item.m.jd.com/product/12510666.html），主要教我們如何在 Kubernetes 上部署分散式容器應用，這本書的作者是 Marko Luksa，他是紅帽 OpenShift 工程師，這本書由七牛雲 CEO 老許親自作序。翻譯過程中，七牛容器雲團隊根據實際應用經驗，把這本書翻譯得儘量準確，並且通俗易懂。

Kubernetes 是希臘文，本意是舵手，帶領一條船到達正確的地方，希望這本書像舵手一樣，能在大家學習 K8S 的過程中帶來一些幫助。

（Marko Luksa 在 ECUG Con 2018 的現場分享片段）

關注公眾號：七牛雲 點選本文文末「閱讀原文」，獲取

Marko Luksa

完整版精彩演講 DEMO！

（為保證視訊及時獲取，請將「提交成功」頁面截圖傳送