一、全容器化部署？

目前應該是幾乎所有的容器云廠商在容器云交流和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比較合適，支持幾百個節點。