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

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

[[207200]]

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

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

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

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

01資源利用率問(wèn)題

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

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

02混合部署交叉影響

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

02容器層

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

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

03資源管理

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

04應(yīng)用層

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

05基礎(chǔ)組件

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

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

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

07鏡像中心

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

08日志中心

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

09監(jiān)控中心

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

10統(tǒng)一門(mén)戶

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

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

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

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

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

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

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

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

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

01容器管理

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

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

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

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

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

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

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

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

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

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

 

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

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

• 性能較好，組網(wǎng)簡(jiǎn)單，可以與現(xiàn)有網(wǎng)絡(luò)無(wú)縫對(duì)接;可以很好的實(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)部框架改動(dòng)小。

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

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

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

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

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

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

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

03鏡像倉(cāng)庫(kù)

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

 

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

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

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

04日志系統(tǒng)

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

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

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

私有云平臺(tái)采用的方案如下：

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

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

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

05監(jiān)控告警

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

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

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

后記

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