58 私有云平臺是 58 同城架構(gòu)線基于容器技術(shù)為內(nèi)部服務(wù)開發(fā)的一套業(yè)務(wù)實(shí)例管理平臺。

它支持業(yè)務(wù)實(shí)例按需擴(kuò)展，秒級伸縮，平臺提供友好的用戶交互過程，規(guī)范化的測試、上線流程，旨在將開發(fā)、測試人員從基礎(chǔ)環(huán)境的配置與管理中解放出來，使其更聚焦于自己的業(yè)務(wù)。

[[207200]]

本文和大家分享在私有云平臺實(shí)施過程中的相關(guān)容器技術(shù)實(shí)踐，主要從以下三個部分來進(jìn)行討論：

• 背景：當(dāng)前存在哪些問題，為什么使用容器技術(shù)。
• 整體架構(gòu)：整個容器技術(shù)的架構(gòu)方案。
• 核心模塊的設(shè)計(jì)方案：一些核心模塊的選型決策與解決方案。

為什么使用容器技術(shù)

在沒有用容器化技術(shù)之前，我們存在這些問題：

01資源利用率問題

不同業(yè)務(wù)場景對資源的需求是不一樣的，有 CPU 密集型、內(nèi)存密集型、網(wǎng)絡(luò)密集型，這就可能導(dǎo)致資源利用率不合理的問題。比如，一個機(jī)器上部署的服務(wù)都是網(wǎng)絡(luò)密集型，那么 CPU 資源和內(nèi)存資源就都浪費(fèi)了。

有些業(yè)務(wù)可能只聚焦于服務(wù)本身而忽略機(jī)器資源利用率的問題。

02混合部署交叉影響

對于線上服務(wù)，一臺機(jī)器要混合部署多個服務(wù)，那么服務(wù)之間可能存在相互影響的情況。

比如，一個服務(wù)由于某些原因突然網(wǎng)絡(luò)流量暴漲，可能把整個機(jī)器的帶寬都打滿，那么其他服務(wù)就會受到影響。

03擴(kuò)/縮容效率低

當(dāng)業(yè)務(wù)節(jié)點(diǎn)需要進(jìn)行擴(kuò)/縮容時，從機(jī)器下線到應(yīng)用部署、測試，周期較長。當(dāng)業(yè)務(wù)遇到突發(fā)流量高峰時，機(jī)器到手部署后，可能流量高峰已經(jīng)過去了。

04多環(huán)境代碼不一致

由于過去內(nèi)部開發(fā)流程的不規(guī)范，存在一些問題，業(yè)務(wù)提測的代碼在測試環(huán)境測試完畢后，在沙箱可能會進(jìn)行修改、調(diào)整，然后再打包上線。

這就會導(dǎo)致測試的代碼和線上運(yùn)行的代碼是不一致的，增加了服務(wù)上線的風(fēng)險，也增加了線上服務(wù)故障排查的難度。

05缺少穩(wěn)定的線下測試環(huán)境

在測試過程中，會遇到一個問題，服務(wù)依賴的其他下游服務(wù)都沒有提供穩(wěn)定的測試環(huán)境。

這導(dǎo)致無法在測試環(huán)境模擬整個線上流程進(jìn)行測試，所以很多測試同學(xué)會用線上服務(wù)進(jìn)行測試，這里有很高的潛在風(fēng)險。

為了解決上述問題，架構(gòu)線云團(tuán)隊(duì)進(jìn)行了技術(shù)選型與反復(fù)論證，最終決定使用 Docker 容器技術(shù)。

58 私有云整體架構(gòu)

58 私有云的整體架構(gòu)如下圖：

01基礎(chǔ)設(shè)施

整個私有云平臺接管了所有的基礎(chǔ)設(shè)施，包括服務(wù)器、存儲和網(wǎng)絡(luò)等資源。

02容器層

基礎(chǔ)設(shè)施之上提供了整個容器初始化層，容器初始化層包含 Kubernetes、Agent、IPAM;Kubernetes 是 Docker 的調(diào)度和管理組件。

Agent 部署在宿主機(jī)上，用于系統(tǒng)資源和底層基礎(chǔ)設(shè)施的管理，包含監(jiān)控采集、日志采集、容器限速等。IPAM 是 Docker 的網(wǎng)絡(luò)管理模塊，用于管理整個網(wǎng)絡(luò)系統(tǒng)的 IP 資源。

03資源管理

容器層之上是資源管理層，包含容器管理、縮擴(kuò)容、回滾降級、上線發(fā)布、配額管理、資源池管理等模塊。

04應(yīng)用層

運(yùn)行用戶提交的業(yè)務(wù)實(shí)例，可以是任意編程語言。

05基礎(chǔ)組件

私有云平臺為容器運(yùn)行環(huán)境提供必備的基礎(chǔ)組件，包含服務(wù)發(fā)現(xiàn)、鏡像中心、日志中心、監(jiān)控中心。

06服務(wù)發(fā)現(xiàn)

接入云平臺的服務(wù)提供統(tǒng)一的服務(wù)發(fā)現(xiàn)機(jī)制，便捷業(yè)務(wù)接入云平臺。

07鏡像中心

存儲業(yè)務(wù)鏡像，分布式存儲，可彈性擴(kuò)展。

08日志中心

中心化收集業(yè)務(wù)實(shí)例日志，提供統(tǒng)一的可視化入口，方便用戶分析與查詢。

09監(jiān)控中心

匯總?cè)康乃拗骱腿萜鞅O(jiān)控信息，監(jiān)控視圖化，報警定制化，為智能化調(diào)度提供基礎(chǔ)。

10統(tǒng)一門戶

可視化的 UI 門戶頁面，規(guī)范化整個業(yè)務(wù)流程，簡潔的用戶流程，可動態(tài)管理整個云環(huán)境的所有資源。

全新的架構(gòu)帶來全新的業(yè)務(wù)流轉(zhuǎn)方式：

平臺定義了四套基礎(chǔ)環(huán)境：

• 測試環(huán)境：測試人員進(jìn)行功能測試，對接到線下環(huán)境。
• 沙箱環(huán)境：程序預(yù)發(fā)布環(huán)境，對接到線上環(huán)境。
• 線上環(huán)境：提供服務(wù)的線上環(huán)境。
• 穩(wěn)定環(huán)境：運(yùn)行在線下環(huán)境的實(shí)例，為其他上游服務(wù)提供穩(wěn)定的測試環(huán)境實(shí)例。

業(yè)務(wù)基于 SVN 提交的代碼構(gòu)建鏡像，鏡像的整個生命周期就是在 4 個環(huán)境中流轉(zhuǎn)。因?yàn)槭腔谕粋€鏡像創(chuàng)建實(shí)例，所以可以保證測試通過的程序與線上運(yùn)行的程序是完全一致的。

核心模塊的設(shè)計(jì)方案

開發(fā) 58 私有云平臺需要考慮很多細(xì)節(jié)，這里主要和大家分享下其中的五個核心模塊：

• 容器管理。
• 網(wǎng)絡(luò)模型。
• 鏡像倉庫。
• 日志收集。
• 監(jiān)控告警。

有了這幾個核心模塊，平臺就有了基礎(chǔ)框架，可以運(yùn)轉(zhuǎn)起來。

01容器管理

我們調(diào)研的基于 Docker 的管理平臺主要有三個：Swarm、Mesos、Kubernetes，通過對比，我們最終選擇了 Kubernetes。

Swarm 功能過于簡陋，所以最早就 pass 了，Mesos + Marathon 是一個成熟的解決方案，但是社區(qū)不夠活躍，而且使用起來要熟悉兩套框架。

Kubernetes 是專門針對容器技術(shù)提供的調(diào)度管理平臺，更專一，社區(qū)非?；钴S，配套的組件與解決方案較多，使用它的公司也越來越多，通過和一些公司溝通，他們也在逐步的將 Docker 應(yīng)用從 Mesos 遷移到 Kubernetes 上。

下面表格為我們團(tuán)隊(duì)關(guān)注點(diǎn)的一些對比情況：

02網(wǎng)絡(luò)模型

網(wǎng)絡(luò)模型是任何云環(huán)境都必須面對的問題，因?yàn)榫W(wǎng)絡(luò)規(guī)模一旦擴(kuò)大之后，會帶來各種問題。網(wǎng)絡(luò)選型這塊，針對 Docker 和 Kubernetes 的特性，對六種組網(wǎng)方式進(jìn)行了對比，如下所示：

針對每種網(wǎng)絡(luò)模型，云團(tuán)隊(duì)都做了相應(yīng)的性能測試，Calico 除外，因?yàn)楣舅玫臋C(jī)房不支持開啟 BGP 協(xié)議，所以沒有進(jìn)行測試。

iPerf 測試網(wǎng)絡(luò)帶寬結(jié)果如下：

Qperf 測試 TCP 延遲結(jié)果如下：

Qperf 測試 UDP 延遲結(jié)果如下：

 

通過測試結(jié)果可以看出：Host 模式和 Bridge 模式性能與宿主機(jī)是最接近的，其他組網(wǎng)模式還是有一些差距的，這和 Overlay 的原理有關(guān)。

私有云平臺最終選擇了 Bridge + VLAN 的組網(wǎng)方式，原因如下：

• 性能較好，組網(wǎng)簡單，可以與現(xiàn)有網(wǎng)絡(luò)無縫對接;可以很好的實(shí)現(xiàn)容器與容器、容器與宿主互通。
• 故障易于調(diào)試，傳統(tǒng)的 SA 即可解決;適應(yīng)任意物理設(shè)備，可大規(guī)模擴(kuò)展。
• 公司內(nèi)部服務(wù)之間都是基于 RPC 協(xié)議，有自己的服務(wù)發(fā)現(xiàn)機(jī)制，可以很好的兼容;現(xiàn)有內(nèi)部框架改動小。

由于 VLAN 最多有 4096 個，所以 VLAN 是有個數(shù)限制的，這也是為什么會有 VLAN 的原因。

在云平臺當(dāng)前的網(wǎng)絡(luò)規(guī)劃中，VLAN 是夠用的，未來隨著使用規(guī)模的擴(kuò)大，技術(shù)的發(fā)展，我們也會深入研究更合適的組網(wǎng)方式。

網(wǎng)上也有同學(xué)反饋 Calico 的 IPIP 模式網(wǎng)絡(luò)性能也很高;但是考慮到 Calico 當(dāng)前的坑比較多，需要有專門的網(wǎng)絡(luò)組來支撐，而這塊是云團(tuán)隊(duì)所欠缺的，所以沒有深入調(diào)研。

這里還有一個問題，默認(rèn)的使用 Bridge 模式是每個宿主機(jī)配置不同網(wǎng)段的地址，這樣就可以保證不同宿主機(jī)上為容器分配的 IP 不沖突，但是這樣也會導(dǎo)致出現(xiàn)大量的 IP 浪費(fèi)。

機(jī)房的內(nèi)網(wǎng)環(huán)境 IP 資源有限，沒有辦法這樣配置網(wǎng)絡(luò)，所以只能開發(fā) IPAM 模塊進(jìn)行全局的 IP 管理。

IPAM 模塊的實(shí)現(xiàn)參考了開源項(xiàng)目 Shrike 的實(shí)現(xiàn)，將可分配的網(wǎng)段寫入 etcd 中，Docker 實(shí)例啟動時，會通過 IPAM 模塊從 etcd 中獲取一個可用 IP，在實(shí)例關(guān)閉時，會對 IP 進(jìn)行歸還，整體架構(gòu)如下所示：

另外，由于 Kubernetes 不支持使用 CNM，所以我們針對 Kubernetes 源碼進(jìn)行了修改。網(wǎng)絡(luò)方面還有一個點(diǎn)需要考慮：就是網(wǎng)絡(luò)限速。

03鏡像倉庫

Docker 的鏡像倉庫使用官方提供的鏡像倉庫，但是后端提供的存儲系統(tǒng)我們進(jìn)行選型，默認(rèn)的存在本地磁盤的方式是無法應(yīng)用到線上系統(tǒng)的。具體的選型如下：

 

通過對比，可以看出 Ceph 是最合適的，但是最終云團(tuán)隊(duì)選擇使用 HDFS 作為鏡像倉庫的后端存儲，原因如下：

• Swift 是官方默認(rèn)提供支持的存儲類型，但是搭建一套 Swift 并保證其穩(wěn)定運(yùn)行需要專人深入研究，由于人員有限所以暫沒使用，Ceph 也是基于同理沒有進(jìn)行選擇。
• HDFS 系統(tǒng)公司有專門的數(shù)據(jù)平臺部門在管理和維護(hù)，他們更專業(yè)，云團(tuán)隊(duì)可以放心的將 Docker 鏡像托管到 HDFS 上。

但是 HDFS 本身也存在一些問題，比如壓力大時，NameNode 無法及時響應(yīng)，未來我們會考慮將后端存儲遷移到架構(gòu)線部門內(nèi)部自研的對象存儲中，以提供穩(wěn)定高效的服務(wù)。

04日志系統(tǒng)

傳統(tǒng)服務(wù)遷移到容器環(huán)境，日志是一個大問題。因?yàn)槿萜骷从眉翠N，容器關(guān)閉后，容器的存儲也會被刪除。

雖然可以把容器中的日志導(dǎo)出到宿主機(jī)上的指定位置，但是容器會經(jīng)常漂移，在排查故障時，我們還需要知道歷史上的某一時刻，某個容器在哪臺宿主機(jī)上運(yùn)行，并且由于使用方?jīng)]有宿主機(jī)的登陸權(quán)限，所以使用方也沒法很好的獲取日志。

在容器環(huán)境下，需要新的故障排查方式。這里，一個通用的解決方案就是采用中心化的日志解決方案，將零散的日志統(tǒng)一進(jìn)行收集存儲，并提供靈活的查詢方式。

私有云平臺采用的方案如下：

使用方在管理門戶上配置要采集的日志，私有云平臺通過環(huán)境變量的方式映射到容器中，宿主機(jī)上部署的 Agent 根據(jù)環(huán)境變量獲取要采集的日志，啟動 Flume 進(jìn)行采集。

Flume 將日志統(tǒng)一上傳到 Kafka 中，上傳到 Kafka 中的日志保證嚴(yán)格的先后順序。

Kafka 有兩個訂閱者，一個將日志上傳到搜索服務(wù)中，供管理門戶查詢使用;一個將日志上傳到 HDFS 中，用于歷史日志的查詢和下載，使用方也可以自己編寫 Hadoop 程序?qū)χ付ㄈ罩具M(jìn)行分析。

05監(jiān)控告警

資源的監(jiān)控和報警也是一個云平臺必不可少的部分。針對容器的監(jiān)控有很多成熟的開源軟件可供選擇，58 內(nèi)部也有專門的監(jiān)控組件，如何更好的監(jiān)控，云團(tuán)隊(duì)也進(jìn)行了相應(yīng)的選型。

最終，云團(tuán)隊(duì)選擇使用 WMonitor 來作為容器的監(jiān)控組件，因?yàn)?WMonitor 本身集成了物理機(jī)和報警邏輯，我們不需要再做相對應(yīng)的開發(fā)，只需要開發(fā)容器監(jiān)控部分的組件，并且針對內(nèi)部的監(jiān)控需求，我們可以很好的進(jìn)行定制。

Heapster + InfluxDB + Grafana 是 Kubernetes 官方提供的監(jiān)控組件，規(guī)模小時用它也沒有問題，但是規(guī)模大時使用它可能會存在問題，因?yàn)樗禽喸儷@取所有節(jié)點(diǎn)監(jiān)控信息的。

后記

以上內(nèi)容是 58 同城架構(gòu)線針對容器技術(shù)如何落地進(jìn)行的相關(guān)探索，很多技術(shù)選型無關(guān)優(yōu)劣，只選擇適合 58 相關(guān)應(yīng)用場景的。整個云平臺要解決的技術(shù)點(diǎn)有很多，這里選取了其中幾個關(guān)鍵的點(diǎn)和大家進(jìn)行分享。