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

[[228661]]

一、全容器化部署？

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

二、環(huán)境管理

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

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

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

三、鏡像倉庫

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

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

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

四、集群部署

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

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

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

五、控制節(jié)點

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

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

六、基礎組件部署

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

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

七、中間件部署

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

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

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

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

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

參考文獻

1.https://blog.openai.com/scaling-kubernetes-to-2500-nodes/?utm_source=digg