基於 K8S 構建數據中心操做系統

在 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 是開源生態，開源有不少安全性問題，咱們如何在升級新版本時，讓當前集羣上的業務不會影響，這是一個很是關鍵的因素。

第二是集羣信息可視化，包括宿主機、系統關鍵組件，L七、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！

（爲保證視頻及時獲取，請將「提交成功」頁面截圖發送至公衆號後臺）