在 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！
（為保證視頻及時獲取，
請將「提交成功」頁面截圖
閱讀更多 七牛雲 的文章
