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

第二是集群信息可視化,包括宿主機、系統關鍵組件,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!

(為保證視頻及時獲取,

請將「提交成功面截圖

marketing@qiniu.com