【51CTO.com原創(chuàng)稿件】眾所周知，微服務(wù)和容器本身結(jié)合較為密切，隨著云服務(wù)的普及，它們從企業(yè)機(jī)房內(nèi)部的服務(wù)器上逐漸延伸到了各種云服務(wù)的場景中。

[[240438]]

因此面對常見的混合云服務(wù)，我們該如何用基于容器的模式來進(jìn)行管理呢？

2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運維技術(shù)峰會在北京召開。

在“微服務(wù)架構(gòu)設(shè)計”分論壇上，來自餓了么計算力交付部門的資深工程師李健帶來了主題為《餓了么基于容器的混合云實踐》的精彩演講。

本文將按照如下四個部分展開分享：

• 計算力交付
• 技術(shù)選型
• 基于 Kubernetes 的“算力外賣”
• Kubernetes 的擴(kuò)展方案

隨著業(yè)務(wù)的快速增長，對應(yīng)的資源規(guī)模也在迅速增長之中。而這種增長直接導(dǎo)致了服務(wù)器類型的增多、管理任務(wù)的加劇、和交付需求的多樣性。

比如在某些場景下，我們需要在交付的服務(wù)器上，預(yù)安裝某種應(yīng)用；而有些時候，我們需要交付出一個“有依賴性”的服務(wù)、或是一組服務(wù)的集合。

計算力交付

盡管我們所面對的物理資源和虛擬機(jī)資源的數(shù)量是龐大的，但我們運維人員卻是有限的，無法做到無限量地擴(kuò)張。因此我們需要將物理資源統(tǒng)一抽象出來，從而輸出給開發(fā)人員。

而這種標(biāo)準(zhǔn)化式的抽象，能夠給企業(yè)帶來兩大好處：極大地減少了成本和增加了服務(wù)器管理上的運能。同時，這種統(tǒng)一抽象催生了我們計算力交付部門的出現(xiàn)。

具體而言，平時我們所交付的服務(wù)器，包括以云服務(wù) IaaS 形式的交付，實際上與應(yīng)用的交付，如 SaaS 形式是一樣的。

在如今虛擬化的云時代，我們通過簡單的命令輸入，就能為某個文件系統(tǒng)準(zhǔn)備好 CentOS 或 Ubuntu 操作系統(tǒng)。因此，服務(wù)器實際上也成為了一種軟件服務(wù)、或是一種 App。

通過以抽象的方式對服務(wù)器和應(yīng)用采取標(biāo)準(zhǔn)化，我們可以把所有的物理資源抽象出來，形成一種具有管控能力的計算力，從而達(dá)到對于系統(tǒng)的協(xié)調(diào)能力?？梢哉f，一切交付的行為都屬于應(yīng)用。

因此我們計算力交付的關(guān)鍵也就落腳在了對應(yīng)用的管理之上，這同時也是我們關(guān)注度的轉(zhuǎn)變。

容器技術(shù)的原型始于七十年代末，但直到 2013 年 Docker 的問世，容器才成為了主流的技術(shù)。

Docker 對于容器技術(shù)的最大貢獻(xiàn)在于：通過真正地面向應(yīng)用的方式，它具有跨平臺的可移植特性，將所有的服務(wù)，統(tǒng)一以 Image 打包的方式來進(jìn)行應(yīng)用的交付。

另外，它是應(yīng)用的一種封裝標(biāo)準(zhǔn)。在此標(biāo)準(zhǔn)之上，我們可以讓應(yīng)用運行在任何一個平臺之中。

同時，這也進(jìn)一步促進(jìn)了自動化運維、AIOps 和大數(shù)據(jù)等應(yīng)用的發(fā)展。因此，它在降低人力成本的同時，也提高了資源的利用率。

我們將計算力交付分為三大類：

• 客戶應(yīng)用的部署。在接到服務(wù)請求后，我們會著手部署，并讓服務(wù)順利運行起來。
• 標(biāo)準(zhǔn)服務(wù)的一鍵交付。例如某部門的大數(shù)據(jù)業(yè)務(wù)需要有一套環(huán)境，該環(huán)境里所包含的許多種服務(wù)，相互之間默認(rèn)是相互隔離的，但同時也要保證部分服務(wù)能夠相互聯(lián)系。

那么我們就需要準(zhǔn)備好一些可復(fù)制的標(biāo)準(zhǔn)化服務(wù)模板，以保證就算在復(fù)雜的 SOA 體系中，也能實現(xiàn)應(yīng)用服務(wù)的順暢發(fā)現(xiàn)。

• 服務(wù)器的交付。如前所述，服務(wù)器交付的標(biāo)準(zhǔn)化，正是我們計算力交付部門能力的一種體現(xiàn)。

技術(shù)選型

如今，可選的容器技術(shù)有很多，包括 Kubernetes、Swarm、和 AWSECS 等，其中 Kubernetes 比較熱門。

因此我們在選型時，需要考慮如下因素：

• Kubernetes 項目已成為了容器編排的事實標(biāo)準(zhǔn)。由于大家都在普遍使用，如果碰到了問題，可以到社區(qū)里去搜尋答案。這無形中帶來了成本下降的優(yōu)勢。
• 實際需求情況和技術(shù)的契合度。
• 擴(kuò)展性與生態(tài)發(fā)展。一些由大公司的采用作為背書的技術(shù)，一般都有著強(qiáng)大的后臺支持和一定的前瞻性，同時也方便建立起一定的生態(tài)體系。

基于 Kubernetes 的“算力外賣”

我們開發(fā)人員平時對于應(yīng)用服務(wù)類型的需求和本公司所做的點餐服務(wù)是極其類似的。上圖中的綠色 Box，實際上就像我們抽象出的一個外賣盒。

其中每一種服務(wù)相互之間的調(diào)用，都是通過 DomainName 去實現(xiàn)的。而且這些 Box 具有復(fù)制性，我們可以依據(jù)模板來創(chuàng)建出多個 Box。

而每個 Box 內(nèi)部在調(diào)用不同的服務(wù)時，它的域名在系統(tǒng)中是唯一的。因此，它們可以橫跨不同的環(huán)境進(jìn)行調(diào)用，從而減少了開發(fā)人員的工作量。

過去，在服務(wù)啟動的時候，系統(tǒng)會自動生成一個網(wǎng)絡(luò)標(biāo)識，而當(dāng) IP 地址或域名發(fā)生變化時，他們不得不進(jìn)行相應(yīng)的配置修改。

如今，只要容器環(huán)境和相應(yīng)的應(yīng)用運行起來了，不同服務(wù)之間就能夠根據(jù)唯一的網(wǎng)絡(luò)標(biāo)識實現(xiàn)相互調(diào)用。

在具體實現(xiàn)中，我們利用 Kubernetes 做出了一個底層的容器引擎。在其中的每個 Unit 里，都會包括有 Domain 和 Pod。而且每個 Unit 都有自己的副本，以實現(xiàn)負(fù)載均衡。

我們通過使用 Systemd，這種啟動方式去了解各個服務(wù)之間的相互依賴關(guān)系。

它通過啟動樹，在 Box 中實現(xiàn)了同樣的功能，以保證 Box 在啟動的時候，能夠根據(jù)我們既定的依賴描述，按照先后次序?qū)?yīng)用啟動運行起來。

雖然從技術(shù)發(fā)展的角度來說，服務(wù)之間不應(yīng)該存在過多的依賴關(guān)系，但是由于我們部門是面向業(yè)務(wù)部門提供服務(wù)的，所以我們需要做的只是去推動標(biāo)準(zhǔn)化，從而去兼容開發(fā)的習(xí)慣和他們當(dāng)前的項目。

如上圖所示，每個 Unit 中還有一個 Hook，它可以協(xié)助服務(wù)的啟/停與初始化。例如，在某些服務(wù)完成了之后，它會去調(diào)用另外一個 Pod 進(jìn)行初始化。

當(dāng)然，我們也涉及到對公共服務(wù)的使用。例如，Box1 和 Box2 都要通過一個公共服務(wù)來傳遞數(shù)據(jù)。而公共服務(wù)的唯一性網(wǎng)絡(luò) ID，則可能因為重啟等外部因素而發(fā)生變化。

因此為了保持一致性，我們嘗試著將上述提到的內(nèi)部標(biāo)識轉(zhuǎn)換為外部標(biāo)識。實際上，我們的內(nèi)部標(biāo)識是永遠(yuǎn)不變的，而外面關(guān)系則需要通過服務(wù)發(fā)現(xiàn)的機(jī)制，與內(nèi)部服務(wù)動態(tài)建立關(guān)聯(lián)。

這樣一來，內(nèi)部的服務(wù)就不必考慮配置變更、以及服務(wù)發(fā)現(xiàn)等問題了。上圖就是我們對于外賣服務(wù)方式的一種最簡單的抽象。

眾所周知，Kubernetes 的服務(wù)主要依賴于 Etcd 的啟動，但是 Etcd 本身在 Kubernetes 的應(yīng)用場景下并不能支持大量的業(yè)務(wù)。

因此，考慮到了業(yè)務(wù)量的逐漸增大和對于服務(wù)的穩(wěn)定性要求，我們需要對 Kubernetes 盡量進(jìn)行拆分。

在拆分的過程中，我們將原來單個機(jī)房網(wǎng)絡(luò)中的資源池拆分成三到四個 Kubernetes 集群。

在拆分完成之后，我們曾碰到了一個問題：由于拆分得太細(xì)，集群資源出現(xiàn)了利用率不均的情況：有的集群負(fù)載不夠、而有的集群則負(fù)載過多。

因此，我們運用不同的 Etcd 對應(yīng)不同的 Kubernetes 集群，通過調(diào)度的方式，讓服務(wù)能夠在集群之間飄移，從而既解決了資源效率的問題，又解決了可靠性的問題。

在上述簡單的結(jié)構(gòu)中，除了黃色的部分，其他都是 Kubernetes 原生的組件，包括藍(lán)色部分里具有調(diào)度 Pod 功能的調(diào)度器（Scheduler）。

我們根據(jù)上述不同 Node 層的屬性和服務(wù)信息進(jìn)行判斷，以確定要調(diào)用哪個集群。

由于我們采取的是兩層調(diào)度的方式，因此在調(diào)到第一層的時候，我們并沒有該集群的實時信息，也無法知道此集群把服務(wù)調(diào)到了何處。

對此，我們自行開發(fā)了一個 Scheduler（如黃色部分所示）。另外，我們還開發(fā)了一個類似于 Kubernetes 的 APIServer 服務(wù)。

可見，我們的目的就在于：以外圍的方式去擴(kuò)展 Kubernetes 集群，而不是去改動 Kubernetes 本身。

即：在 Kubernetes 的外圍，增加了一層 APIServer 和 Scheduler。此舉的直接好處體現(xiàn)在：我們節(jié)約了在框架上的開發(fā)與維護(hù)成本。

下面我們來具體看看真實的容器環(huán)境：

• 如前所述，我們是基于 Kubernetes 的。
• 在網(wǎng)絡(luò)上我們使用的是阿里云的虛擬機(jī)。如果規(guī)模小的話，我們會用 Vroute 的方式；如果是自建機(jī)房的話，我們就使用 LinuxBridge 的方式。同時，我們的 Storage Driver 用的是 Overlay2。
• 在操作系統(tǒng)方面，我們都使用的是 Centos7-3.10.0-693。
• 在 Docker 的版本上，我們用的是 17.06。值得補(bǔ)充的是：如今社區(qū)里傳聞該版本即將被停止維護(hù)了，因此我們近期會著手升級。

Registry

說到 Registry，在以前規(guī)模小的時候并不存在問題。但是如今我們的規(guī)模已大到橫跨幾個機(jī)房。

因此我們就需要對 Registry 傳過來的數(shù)據(jù)進(jìn)行同步，并“雙寫”到 OSS(Object Storage Service)和 Ceph(一個開源的分布式存儲系統(tǒng)，提供對象存儲、塊存儲和文件系統(tǒng)的存儲機(jī)制)之中了。

由于我們在自己的物理機(jī)房中都有 Ceph，因此在下載時可以遵循就近下載的原則，而不必跨出本機(jī)房。

此舉的好處就在于：降低了在機(jī)房之間傳輸所帶來的帶寬瓶頸問題。

那么我們?yōu)槭裁匆鐾侥?？由于我們的服?wù)一旦被發(fā)布出去，它們就會自動去進(jìn)行異步部署。

但是，有些機(jī)房里可能根本沒有所需的鏡像，那么它們在進(jìn)行“拉取”操作時就會報錯。

因此基于此方面的考慮，我們采用了“同步雙寫”模式，并增加了認(rèn)證的環(huán)節(jié)。

想必大家都知道：Registry 在長時間運行后，鏡像里會有越來越多的 Blob。

我們既可以自行清理，也可以根據(jù)官方提供的方式來清理，但是清理的時間一般都會非常長。

因此清理工作會帶來服務(wù)的運維性中斷，這對于一般公司來說是無法接受的。

對此，我們想到一種“Bucket 輪轉(zhuǎn)”的方法。由于在 CI（持續(xù)集成）的過程中，我們會產(chǎn)生大量的鏡像，因此我們將鏡像以兩個季度為一個保存周期進(jìn)行劃分，即：

• 為第一個季度新建一個 Bucket，用來存儲鏡像。
• 在第二個季度時，將新的鏡像產(chǎn)生到第二個 Bucket 之中。
• 等到了第三個季度，我們就將第一個 Bucket 里的鏡像清理掉，以存入新的鏡像。

以此類推，通過該方法，我們就能夠限制鏡像，不至于無限地增長下去。

我們當(dāng)前的 8 臺 Registry 所服務(wù)的 Docker 對象具有成千上萬的體量規(guī)模。

如果 Registry 一旦出現(xiàn)問題，我們就需要迅速地能夠定位到問題，因此，對于 Registry 采取相關(guān)的監(jiān)控是非常必要的。

同時，我們也需要通過監(jiān)控來實時了解系統(tǒng)的使用程度，以便做出必要的擴(kuò)容。

在實現(xiàn)方式上，我們實際上只是稍微加入了一些自己寫的程序，而整體上仍保留著與其他程序的解耦關(guān)系。

如圖所示，我們通過上傳、下載的速度，包括 Blob 的數(shù)量等監(jiān)控指標(biāo)，能夠?qū)崟r地跟蹤 Registry 的運行狀態(tài)。 

Docker

我們使用 Docker syslog driver 將采集到的用戶進(jìn)程輸出到 ELK 之中進(jìn)行呈現(xiàn)。不過在日志量過于頻繁的時候，ELK 會出現(xiàn)毫秒級別的亂序。

這樣的亂序會給業(yè)務(wù)部門帶來無法進(jìn)行問題排查的困難。因此，我們改動了 Docker 的相關(guān)代碼，給每一條日志都人為增加一個遞增的序列號。

針對一些可靠性要求較高的 Log，我們選擇了 TCP 模式。但是在 TCP 模式下，如果某個日志被輸出到一個服務(wù)時，其接收服務(wù)的 Socket 由于滿載而“夯住”了。

那么該容器就無法繼續(xù)，其 Docker ps 命令也就只能停在那兒了。另外就算 TCP 模式開啟了，但是其接收日志 TCPServer 尚未啟動也是無濟(jì)于事的。

由此可見，在面對一些具體使用中的問題時，我們的需求與開源項目本身所能提供的服務(wù)還是有一定距離的。任何一個開源項目在企業(yè)落地時，都不可能是完美的。

開源項目往往提供的是標(biāo)準(zhǔn)化的服務(wù)，而我們的需求卻經(jīng)常是根據(jù)自己的具體場景而定制化的。

我們企業(yè)的軟件環(huán)境，都是根據(jù)自身環(huán)境一點、一點地長出來的，因此存在差異性是必然的。

我們不可能讓開源軟件為我們而改變，只能通過修改程序，讓開源軟件來適應(yīng)我們當(dāng)前的軟件狀態(tài)與環(huán)境，進(jìn)而解決各種具體的問題。

上圖是 Docker 的一些監(jiān)控，它能夠幫助我們發(fā)現(xiàn)各種問題、Bug、以及“夯住”的地方。

Init 進(jìn)程

在將傳統(tǒng)的業(yè)務(wù)進(jìn)行容器化轉(zhuǎn)變的過程中，我們針對容器定制并改進(jìn)了 Init 進(jìn)程。

該 Init 進(jìn)程能夠切換 Image 基礎(chǔ)層管理的一些目錄和環(huán)境變量，通過也可以替換基礎(chǔ)配置文件的宏代換。

對于一些遷移過來的服務(wù)，其本身就曾帶有配置項，它們通常使用環(huán)境變量來讀取配置信息。那么這對于我們將其修改成容器的工作，就無形中增加了成本。

因此我們所提供的方法是：雖然變量被寫在了配置里，但是我們能夠根據(jù)容器的環(huán)境變量設(shè)置，自動去替換服務(wù)寫“死”的配置。

Init 進(jìn)程的這種方法對于在容器尚未啟動，且不知道服務(wù)的 IP 地址時尤為有用。

對于容器的管理，我們也啟動了 Command，來持續(xù)監(jiān)聽進(jìn)程的狀態(tài)，以避免僵尸進(jìn)程的出現(xiàn)。

另外，由于我們公司有著內(nèi)部的 SOA 體系，在 Docker 產(chǎn)生停止信號之后，需要將流量從公司的整個集群里摘除掉。

因此，我們通過截獲信息，做到了在相關(guān)的流量入口予以服務(wù)的摘除動作。

同時，我們還通過傳遞停止信號給應(yīng)用進(jìn)程，以完成針對軟件的各種掃尾清理操作，進(jìn)而實現(xiàn)了對傳統(tǒng)業(yè)務(wù)予以容器化的平滑過渡。

Kubernetes 資源管理擴(kuò)展

下面通過案例來看看，我們是如何通過擴(kuò)展來滿足業(yè)務(wù)需求的。

我們都知道，Kubernetes 的 APIServer 是較為核心的組件，它使得所有的資源都可以被描述和配置。這與 Linux“一切皆文件”的哲學(xué)具有異曲同工之妙。

Kubernetes 集群將所有的操作，包括監(jiān)控和其他資源，都通過讀文件的方式來掌握服務(wù)的狀態(tài)，并通過寫文件的方式來修改服務(wù)的狀態(tài)。

借用這種方式，我們相繼開發(fā)了不同的組件和 APIServer 的接口，并以 Restful 的接口形式對服務(wù)實現(xiàn)了微服務(wù)化。

在實際部署中，雖然我們并沒有用到 Kubernetes Proxy，但是這樣反而降低了 APIServer 的負(fù)載。

當(dāng)然如果需要的話，我們完全可以按需加載與部署，從而保證并增強(qiáng)系統(tǒng)整體的擴(kuò)展性。

Kubernetes APIServer

上圖直觀地展示了 APIServer 的簡單內(nèi)部結(jié)構(gòu)。所有的資源實際上都要被放入 Etcd 之中。

同時，每一種資源都有一個 InternalObject，它對應(yīng)著 Etcd 里的一些存儲類 Key/Value，這樣保證了每個對象的唯一性。

當(dāng)有外面請求來訪問服務(wù)時，則需要通過 ExternalObject 和 InternalObject 進(jìn)行轉(zhuǎn)換才能實現(xiàn)。

例如：我們可能使用不同版本的 API 進(jìn)行程序開發(fā)，而此時出現(xiàn)了需求變更，需要我們增加一個字段。

而實際上該字段可能已經(jīng)存在于 InternalObject 之中了，那么我們只需經(jīng)過一些處理便可直接生成該字段。

可見，我們真正要去實現(xiàn)的只是 ExternalObject，而沒必要去改動 InternalObject。

如此，我們在不修改存儲的基礎(chǔ)上，盡量做到了服務(wù)與存儲之間的解耦，以更好地應(yīng)對外界的各種變化。

當(dāng)然，這同時也是 Kubernetes APIServer 里對象服務(wù)的一個過程。

與此同時，我們也將部分 API 劃歸到了一個 APIGroup 之中。在同一個 APIGroup 里，不同的資源相互之間是解耦、并行的，我們能夠以添加接口的方式進(jìn)行資源的擴(kuò)展。

而上述提到的兩個對象之間的轉(zhuǎn)換，以及類型的注冊，都是在圖中的 Scheme 里面完成的。

如果大家想自己做 APIServer 的話，谷歌官方就擁有該項目的對應(yīng)方案，并提供了專門的技術(shù)支持。如果您感興趣的話，可以參考圖中下方對應(yīng)的 Github 項目的網(wǎng)址。

另外，谷歌還提供了自動生成代碼的工具。相應(yīng)地，我們在開發(fā)的過程中也做了一個直接通過對象來生成數(shù)據(jù)庫所有相關(guān)操作的小工具，它節(jié)約了我們大量的時間。

Kubernetes 落地

最后和大家分享一下，我們在 Kubernetes 落地過程中所遇到的一些問題：

• Pod 重啟方式。由于 Pod 所謂的重啟實際上是新建一個 Pod，并且放棄以前那個舊的，因此這對于我們的企業(yè)環(huán)境來說是無法接受的。
• Kubernetes 無法限制容器文件系統(tǒng)大小。有時候程序員在寫業(yè)務(wù)代碼時，由于不慎，會導(dǎo)致日志文件在一天之內(nèi)激增 100 多 GB，從而占滿了磁盤并導(dǎo)致報警。

然而我們發(fā)現(xiàn)，在 Kubernetes 里好像并沒有相關(guān)的屬性去限制文件系統(tǒng)的大小，因此我們不得不對它進(jìn)行了略微的修改。

• DNS 改造。您可以采用自己的 DNS，也可以使用 Kubernetes 的 DNS。不過我們在使用 Kubernetes DNS 之前，專門花時間對它進(jìn)行了定制與改造。
• Memory.kmem.slabinfo。當(dāng)我們創(chuàng)建容器到了一定程度時，會發(fā)現(xiàn)容器再怎么也無法被創(chuàng)建了。我們雖然嘗試過釋放容器，但是發(fā)現(xiàn)還是受到了內(nèi)存已滿的限制。

經(jīng)過分析，我們發(fā)現(xiàn)：由于我們使用的 Kernel 版本為 3，而 Kubelet 激活開啟了 cgroupkernel-memory 這一測試屬性特性，同時 Centos7-3.10.0-693 的 Kernel 3 對于該特性支持并不好，因此耗光了所有的內(nèi)存。

[[240444]]

李健，餓了么 計算力交付部負(fù)責(zé)人，擁有多年豐富的容器系統(tǒng)建設(shè)經(jīng)驗，并推進(jìn)了餓了么平臺容器化；擅長將容器的敏捷性和標(biāo)準(zhǔn)化進(jìn)行企業(yè)級落地，是企業(yè)內(nèi)部多個基于容器的云計算項目的開發(fā)負(fù)責(zé)人。熱愛開源，熱衷于用開源項目解決企業(yè)問題。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】