關(guān)于容器云部署問題

周末參加一個(gè)的技術(shù)研討會(huì)上，提到容器云平臺(tái)組件、中間件、微服務(wù)等的部署問題，是虛擬機(jī)、物理機(jī)、還是容器化部署好？這個(gè)問題我們前面的文章也討論過一點(diǎn)，也可能沒有標(biāo)準(zhǔn)答案，仁者見仁、智者見智，所謂兵無常勢(shì)、水無常形，需要根據(jù)具體的業(yè)務(wù)環(huán)境、業(yè)務(wù)需求、技術(shù)要求等選擇合適的方案。不過正好我們也在考慮決定容器云測(cè)試、UAT、生產(chǎn)環(huán)境應(yīng)該采用什么樣的部署架構(gòu)和方式，在此也分享一下我們的思考，希望對(duì)大家能有所助益。

一、全容器化部署？

目前應(yīng)該是幾乎所有的容器云廠商在容器云交流和PoC時(shí)都強(qiáng)調(diào)所有組件都容器化。這樣實(shí)施安裝部署相對(duì)容易，一鍵部署、半小時(shí)搭建容器云平臺(tái)。但我們?cè)赑oC測(cè)試中也發(fā)現(xiàn)了一些問題，比如容器資源分配的問題，Kubernetes多集群部署問題，控制節(jié)點(diǎn)高可用部署問題，鏡像倉(cāng)庫(kù)定位和部署問題，中間件和不同的環(huán)境部署和定位問題等；也發(fā)現(xiàn)容器云平臺(tái)容器異常，新的容器創(chuàng)建，舊的依然在，導(dǎo)致很多無用的容器占用資源，也帶來一些理解上的困難。雖然是平臺(tái)自身實(shí)現(xiàn)的問題，但明顯是在設(shè)計(jì)時(shí)一些問題沒考慮到。

二、環(huán)境管理

全容器化部署的好處是可以快速的構(gòu)建一致性的環(huán)境，這也是實(shí)現(xiàn)DevOps的一個(gè)重要方面。所以在開發(fā)測(cè)試環(huán)境全容器化部署是沒有問題的。因?yàn)檫@些環(huán)境需求變化快，傳統(tǒng)維護(hù)開發(fā)測(cè)試環(huán)境需要花費(fèi)大量的時(shí)間和人力，如果采用容器化方式，可以快速構(gòu)建一個(gè)開發(fā)測(cè)試環(huán)境域，用于完成服務(wù)的測(cè)試。主要完成功能性方面的測(cè)試，對(duì)于可能涉及到性能測(cè)試，我們建議放到UAT環(huán)境來做。UAT和生產(chǎn)環(huán)境保持軟硬件和部署架構(gòu)一致。UAT和生產(chǎn)環(huán)境容器云基礎(chǔ)組件建議部署到虛擬機(jī)或物理機(jī)上，比如集中日志、監(jiān)控、服務(wù)注冊(cè)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)等組件。這樣部署的目的一方面是為了更好的利用容器云的輕量化特性，另一方面也是基于安全、運(yùn)維管理等考慮。

我們也一直說要用簡(jiǎn)單的方式解決復(fù)雜的問題，基于容器云基礎(chǔ)設(shè)施，我們希望建設(shè)企業(yè)級(jí)服務(wù)中臺(tái)，一家企業(yè)只需要維護(hù)一套日志系統(tǒng)，一套監(jiān)控系統(tǒng)，沒必要每次都重復(fù)建設(shè)。這些組件相對(duì)固定，并不需要經(jīng)常改變，而且數(shù)據(jù)需要保證絕對(duì)的安全。通常集中日志系統(tǒng)、監(jiān)控系統(tǒng)等都需要集群化部署，不是一臺(tái)機(jī)器一個(gè)實(shí)例能滿足需求的。所以在開發(fā)測(cè)試環(huán)境是為了利用容器的快速構(gòu)建特性，在UAT、生產(chǎn)環(huán)境則要保持穩(wěn)定、安全。采用容器云在環(huán)境管理環(huán)境部署方面可以有所差別。

各個(gè)環(huán)境保持獨(dú)立而又通過鏡像倉(cāng)庫(kù)聯(lián)系起來，鏡像是聯(lián)系各個(gè)環(huán)境的標(biāo)準(zhǔn)交付物。

三、鏡像倉(cāng)庫(kù)

鏡像倉(cāng)庫(kù)在容器云平臺(tái)如何定位？在DevOps中起什么樣的價(jià)值？這是我們考慮采用容器云平臺(tái)過程中也一直考慮的問題。以前的討論中我們提到過，考慮把鏡像倉(cāng)庫(kù)作為開發(fā)測(cè)試和生產(chǎn)之間的媒介，開發(fā)測(cè)試都止于鏡像倉(cāng)庫(kù)，生產(chǎn)起于鏡像倉(cāng)庫(kù)。鏡像作為標(biāo)準(zhǔn)交付物，在各個(gè)環(huán)境間傳遞，鏡像倉(cāng)庫(kù)通過鏡像的安全檢查等機(jī)制保證鏡像安全。也就是DevOps持續(xù)集成止于鏡像倉(cāng)庫(kù)，鏡像倉(cāng)庫(kù)是部署運(yùn)營(yíng)的起點(diǎn)。

鏡像倉(cāng)庫(kù)要不要部署于容器？其實(shí)這個(gè)在我們看來不是很重要。首先鏡像倉(cāng)庫(kù)是基礎(chǔ)組件，不會(huì)經(jīng)常需要更改變化，所以其實(shí)更適合穩(wěn)定的部署。另外公共鏡像和私有鏡像會(huì)需要很多的磁盤空間，IO能力會(huì)成為一個(gè)因素。鏡像倉(cāng)庫(kù)可以作為鏡像的分發(fā)中心，也就是我們所說的各環(huán)境之間的媒介，或者不同集群之間的媒介。從這個(gè)角度來說，鏡像倉(cāng)庫(kù)可以作為一個(gè)獨(dú)立的部分，只是為容器云平臺(tái)提供鏡像分發(fā)服務(wù)和鏡像管理服務(wù)。它可以獨(dú)立部署，不依賴于容器云平臺(tái)。物理機(jī)或虛擬機(jī)部署或許更合適一點(diǎn)，當(dāng)然，部署于容器也不是不可以。

鏡像倉(cāng)庫(kù)高可用部署是需要考慮的，這也是很多容器云廠商宣傳的一個(gè)重要的功能點(diǎn)。如果有充足的資源，我們還是建議鏡像倉(cāng)庫(kù)部署高可用，畢竟這樣可以多一份保障，減少一些意外，但高可用節(jié)點(diǎn)不是越多越好，通常主備節(jié)點(diǎn)就可以了。不部署高可用通常也不會(huì)有太大問題，只要數(shù)據(jù)不丟失，很快的恢復(fù)，沒有大的影響。

四、集群部署

Kubernetes理論上可以管理成千上萬的節(jié)點(diǎn)，但現(xiàn)實(shí)總會(huì)有不小的差距。有測(cè)試顯示Kubernetes集群節(jié)點(diǎn)數(shù)超過500就會(huì)出現(xiàn)超時(shí)，增加Kube Master節(jié)點(diǎn)并不能真的解決問題，所以每個(gè)Kubernetes集群節(jié)點(diǎn)數(shù)有一定的限制，在達(dá)到500左右時(shí)就需要考慮優(yōu)化措施，或者按業(yè)務(wù)條線分集群部署。

通常我們這樣的傳統(tǒng)企業(yè)，節(jié)點(diǎn)數(shù)也不會(huì)很快達(dá)到500以上，單一集群一定時(shí)間內(nèi)也可以滿足需求。隨著節(jié)點(diǎn)數(shù)的增加，Kube Master節(jié)點(diǎn)數(shù)也需要增加。其實(shí)最初我們考慮只要Kubernetes能保證在Master節(jié)點(diǎn)宕機(jī)時(shí)不影響到業(yè)務(wù)應(yīng)用的正常運(yùn)行，Kubernetes集群的管理工作我們可以忍受一段時(shí)間的中斷，所以我們沒考慮Master節(jié)點(diǎn)高可用，但節(jié)點(diǎn)數(shù)的增加可能必須部署Master節(jié)點(diǎn)的高可用，否則可能無法支持kubectl的正常操作。隨著節(jié)點(diǎn)數(shù)的增加master節(jié)點(diǎn)數(shù)也需要增加。但master節(jié)點(diǎn)數(shù)超過10就也會(huì)帶來一些問題，所以通常master節(jié)點(diǎn)數(shù)是3、5或7比較合適，支持幾百個(gè)節(jié)點(diǎn)。

所以初始情況下，可以用簡(jiǎn)單的方式，化繁為簡(jiǎn)，化大為小，采用按業(yè)務(wù)條線多集群部署方式。這樣每個(gè)集群確保不會(huì)有超過500以上的節(jié)點(diǎn)。超過的話考慮新建集群進(jìn)行拆分。但有些情況下可能需要很大的集群，這個(gè)目前采用Mesos可能是更好的方案，從《scaling kubernetes to 2500 nodes》一文中我們了解到Kubernetes可能需要采取不少的優(yōu)化措施。我們還遠(yuǎn)未達(dá)到這樣的集群數(shù)量，也沒有條件進(jìn)行測(cè)試，所以目前還不能確切知道是否可行。也不知道是否有什么潛在的問題，廠商似乎在這方面也沒有太多經(jīng)驗(yàn)。所以如果可能的話，把大集群拆分為多個(gè)小集群，按業(yè)務(wù)條線、或者按區(qū)域等劃分，應(yīng)該是一個(gè)可行的方案。

五、控制節(jié)點(diǎn)

控制節(jié)點(diǎn)就是我們說的master節(jié)點(diǎn)，是集群中的大腦和中樞神經(jīng)，控制和指揮著整個(gè)集群的運(yùn)轉(zhuǎn)?？刂乒?jié)點(diǎn)不可用，整個(gè)集群就會(huì)陷入癱瘓。最初我們考慮，是否有必要占用那么多的資源來部署控制節(jié)點(diǎn)高可用，對(duì)我們來說我們可以忍受一段時(shí)間內(nèi)控制節(jié)點(diǎn)不可用，只要能及時(shí)恢復(fù)。部署并不是每時(shí)每刻發(fā)生，只要部署的業(yè)務(wù)服務(wù)能正常運(yùn)行，業(yè)務(wù)不受影響，控制節(jié)點(diǎn)暫時(shí)的不可用是不會(huì)有太大的影響。所以最初我們只考慮部署一個(gè)控制節(jié)點(diǎn)，不考慮高可用部署。這也是基于我們ESB運(yùn)維的經(jīng)驗(yàn)。ESB的控制監(jiān)控節(jié)點(diǎn)故障，不影響業(yè)務(wù)服務(wù)，所以我們有充足的時(shí)間來調(diào)試恢復(fù)ESB控制監(jiān)控節(jié)點(diǎn)。不過Kubernetes跟ESB不同的是，隨著節(jié)點(diǎn)數(shù)的增加，可能需要部署更多控制節(jié)點(diǎn)，實(shí)現(xiàn)控制節(jié)點(diǎn)高可用部署。

Kubernetes控制節(jié)點(diǎn)有多個(gè)組件，包括kube-apiserver、kube-controller、kube-scheduler和etcd等，這些組件是分開部署還是一個(gè)節(jié)點(diǎn)上部署？隨著集群節(jié)點(diǎn)數(shù)的增加，可能也是一個(gè)不得不考慮的問題。Etcd應(yīng)該需要單獨(dú)部署，不同的場(chǎng)景選擇合適的磁盤，以及是否使用不同的etcd集群，比如配置中心如果使用etcd，是否和平臺(tái)合用同一個(gè)etcd還是新建一個(gè)，需要根據(jù)具體節(jié)點(diǎn)數(shù)量等情況來確定。從《scaling kubernetes to 2500 nodes》文中我們知道，etcd使用了串行 I/O， 導(dǎo)致 I/O 之間的延遲疊加，在節(jié)點(diǎn)數(shù)超過500的時(shí)候延遲就增加很多，導(dǎo)致Kubectl操作超時(shí)，所以etcd在改用本地SSD磁盤后，etcd終于正常了。另外Kubernetes Events 也可以存儲(chǔ)在一個(gè)單獨(dú)的 etcd 集群里，這樣對(duì) Events 的操作就不會(huì)影響到主 etcd 集群的正常工作。但這也帶來了更多的資源投入，以及管理的復(fù)雜度。

六、基礎(chǔ)組件部署

我們討論過多次，要建設(shè)容器云平臺(tái)，僅有Kubernetes是遠(yuǎn)遠(yuǎn)不夠，還需要很多的基礎(chǔ)組件來支撐整個(gè)業(yè)務(wù)應(yīng)用。比如日志、監(jiān)控、配置、注冊(cè)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)等組件。這些組件是容器化部署好還是虛擬機(jī)/物理機(jī)上部署好，都是繞不開的問題。

初始節(jié)點(diǎn)數(shù)量和服務(wù)數(shù)量少的情況下，可能基礎(chǔ)組件容器化部署是個(gè)不錯(cuò)的選擇。其實(shí)就像我們所說的開發(fā)測(cè)試環(huán)境，目的是為了快、敏捷，所以量不會(huì)很大。隨著節(jié)點(diǎn)數(shù)增加，服務(wù)量增加，不只是Kubernetes自身組件會(huì)遇到瓶頸，服務(wù)治理服務(wù)管理等平臺(tái)基礎(chǔ)組件也會(huì)遇到同樣的問題。

七、中間件部署

我們建設(shè)容器云，很重要的原因是希望利用云上中間件的能力。如果沒有中間件服務(wù)，那將需要很多的工作來構(gòu)建這些服務(wù)，不過幸運(yùn)的是，已經(jīng)有很多中間件可以在容器云上部署。不過同樣面臨一個(gè)“量”的問題，量大的情況下，是否能支撐，是否比非容器化需要成倍的資源來支撐，是否給運(yùn)維帶來一些困難。比如某證券的Kafka集群有20多臺(tái)，內(nèi)存配置一般選擇64G，采用SSD硬盤，并做了raid5冗余，這樣的配置在容器云平臺(tái)肯定是不合適的，所以需要部署于虛擬機(jī)或者物理機(jī)上。

在開發(fā)測(cè)試環(huán)境我們還是建議使用容器化環(huán)境。在生產(chǎn)根據(jù)實(shí)際的情況和業(yè)務(wù)場(chǎng)景選擇合適的部署方式。數(shù)據(jù)庫(kù)什么的可能就不是很合適，雖然也支持，可以部署，但從運(yùn)維、安全、組件穩(wěn)定性等方面考慮，非容器化部署可能更合適。

八、微服務(wù)/業(yè)務(wù)服務(wù)部署

微服務(wù)肯定是要部署到容器上。目的就是為了利用容器的輕量、隔離、標(biāo)準(zhǔn)化、彈性伸縮等特性。微服務(wù)/業(yè)務(wù)服務(wù)往往是需要不斷的改進(jìn)、更新，所以服務(wù)整個(gè)生命周期要足夠敏捷，不只是開發(fā)敏捷。其實(shí)從這點(diǎn)我們也可以看到，容器化部署比較適合經(jīng)常變化的、輕量的，那些笨重的、基本沒有太大變化的組件如果容器化部署可能無法展現(xiàn)容器的優(yōu)點(diǎn)。把容器當(dāng)虛擬機(jī)用，有點(diǎn)畫蛇添足。其實(shí)很多公司選擇互聯(lián)網(wǎng)應(yīng)用場(chǎng)景部署于容器云作為采用實(shí)施容器云的開端，也是因?yàn)檫@些原因吧。看來是英雄所見略同。

我們還討論過容器化部署時(shí)，每個(gè)鏡像可能會(huì)不小，幾百兆、甚至上G，跟我們傳統(tǒng)ESB服務(wù)部署對(duì)資源需求就有很大不同。容器化隔離更好，但是每個(gè)容器都會(huì)重復(fù)占用資源。比如java應(yīng)用，通常一臺(tái)機(jī)器安裝一個(gè)JDK就可以了，可以運(yùn)行很多個(gè)Java應(yīng)用。但對(duì)于容器來說，每個(gè)容器都需要一個(gè)JDK，所以每個(gè)鏡像都需要打包JDK，在網(wǎng)絡(luò)傳輸、存儲(chǔ)、運(yùn)行時(shí)資源占用，似乎都沒有節(jié)約。