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

一、全容器化部署？

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

二、環(huán)境管理

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

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

各個環(huán)境保持獨立而又通過鏡像倉庫聯(lián)系起來，鏡像是聯(lián)系各個環(huán)境的標準交付物。

三、鏡像倉庫

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

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

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

四、集群部署

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

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

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

五、控制節(jié)點

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

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

六、基礎組件部署

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

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

七、中間件部署

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

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

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

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

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