容器雲測試、UAT、生產環境應該採用什麼樣的部署架構和方式

一、全容器化部署
目前應該是幾乎所有的容器雲廠商在容器雲交流和PoC時都強調所有元件都容器化。這樣實施安裝部署相對容易，一鍵部署、半小時搭建容器雲平臺。但我們在PoC測試中也發現了一些問題，比如容器資源分配的問題，Kubernetes多叢集部署問題，控制節點高可用部署問題，映象倉庫定位和部署問題，中介軟體和不同的環境部署和定位問題等；也發現容器雲平臺容器異常，新的容器建立，舊的依然在，導致很多無用的容器佔用資源，也帶來一些理解上的困難。雖然是平臺自身實現的問題，但明顯是在設計時一些問題沒考慮到。

二、環境管理

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

我們也一直說要用簡單的方式解決複雜的問題，基於容器雲基礎設施，我們希望建設企業級服務中臺，一家企業只需要維護一套日誌系統，一套監控系統，沒必要每次都重複建設。這些元件相對固定，並不需要經常改變，而且資料需要保證的安全。通常集中日誌系統、監控系統等都需要叢集化部署，不是一臺機器一個例項能滿足需求的。所以在開發測試環境是為了利用容器的快速構建特性，在UAT、生產環境則要保持穩定、安全。採用容器雲在環境管理環境部署方面可以有所差別。

各個環境保持獨立而又通過映象倉庫聯絡起來，映象是聯絡各個環境的標準交付物。

三、映象倉庫

映象倉庫在容器雲平臺如何定位？在DevOps中起什麼樣的價值？這是我們考慮採用容器雲平臺過程中也一直考慮的問題。以前的討論中我們提到過，考慮把映象倉庫作為開發測試和生產之間的媒介，開發測試都止於映象倉庫，生產起於映象倉庫。映象作為標準交付物，在各個環境間傳遞，映象倉庫通過映象的安全檢查等機制保證映象安全。也就是DevOps持續整合止於映象倉庫，映象倉庫是部署運營的起點。

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

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

四、叢集部署

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

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

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

五、控制節點

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

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

六、基礎元件部署

我們討論過多次，要建設容器雲平臺，僅有Kubernetes是遠遠不夠，還需要很多的基礎元件來支撐整個業務應用。比如日誌、監控、配置、註冊發現、服務閘道器等元件。這些元件是容器化部署好還是虛擬機器/物理機上部署好，都是繞不開的問題。

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

七、中介軟體部署

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

在開發測試環境我們還是建議使用容器化環境。在生產根據實際的情況和業務場景選擇合適的部署方式。資料庫什麼的可能就不是很合適，雖然也支援，可以部署，但從運維、安全、元件穩定性等方面考慮，非容器化部署可能更合適。

八、微服務/業務服務部署

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

我們還討論過容器化部署時，每個映象可能會不小，幾百兆、甚至上G，跟我們傳統ESB服務部署對資源需求就有很大不同。容器化隔離更好，但是每個容器都會重複佔用資源。比如Java應用，通常一臺機器安裝一個JDK就可以了，可以執行很多個Java應用。但對於容器來說，每個容器都需要一個JDK，所以每個映象都需要打包JDK，在網路傳輸、儲存、執行時資源佔用，似乎都沒有節約。
人工智慧、大資料、雲端計算和物聯網的未來發展值得重視，均為前沿產業，多智時代專注於人工智慧和大資料的入門和科譜，在此為你推薦幾篇優質好文：
企業為何採用雲端計算？主要用途是什麼？
http://www.duozhishidai.com/article-14574-1.html
企業雲端計算的基本特徵是什麼，在建設過程中主要分為哪幾個階段？
http://www.duozhishidai.com/article-13379-1.html
什麼是雲端計算技術，對雲端計算技術的產生、概念、原理、應用和前景又在哪裡？
http://www.duozhishidai.com/article-527-1.html

---

多智時代-人工智慧和大資料學習入門網站|人工智慧、大資料、物聯網、雲端計算的學習交流網站