對習慣虛擬化以及基于hypervisor云的IT員工來說，容器虛擬化的概念是業務模式上的一個重大變化。接受新技術必須以強大的價值主張作為判斷依據，而容器應該能夠勝任此任務。
回想起來，容器概念相當微妙。傳統虛擬化出錯源于過于靈活。每個虛擬機運行一個完整的系統鏡像，包括操作系統及工具，盡管目標是允許虛擬機能夠運行任何操作系統，包括Windows、Linux，但結果就是在運行應用前已經有大概多達60%的內存被消耗掉了。
選擇容器
數百臺運行相同操作系統的虛擬機，使用了數TB的內存用于復制操作系統的副本。為什么不限制一臺服務器只安裝一個操作系統呢?這樣一個系統鏡像能夠服務該服務器上所有的工作負載或者是所有容器。混合及匹配操作系統版本丟掉了某些靈活性，但坦白來講，這無關緊要。
一臺服務器只運行一個操作系統的經濟效益是驚人的。首先每臺服務器能夠運行更多的工作負載而且效率更高。當然效率依賴于配置，好的做法是同樣的硬件能夠支持的容器數量應該是虛擬機數量的2到3倍。
每個容器獲得的CPU時間可能僅僅為虛擬機的一半，為更高效地使用內存必須進行調整，減少內存交換時間以及其他因素。當工作負載很小時，容器獲得更少的CPU時間片可能無關緊要。
大多數虛擬機的I/O需求都很大，每臺虛擬機僅獲得了與軟盤相等效的性能。大部分I/O流量實際來自于操作系統。尤其是開啟虛擬機時更是如此。
使用容器虛擬化，只有一個操作系統鏡像應該會減少I/O流量。這抵消了在更多的實例之間分配可用I/O所帶來的不良影響。然而在產生大量I/O流量的用例中，每個容器的I/O需求量將會增大。
這時，我們可以選擇在服務器內配置基于hypervisor的虛擬機，也可以配置數量為虛擬機兩倍的容器實例——每個實例的運行速度更慢，仍舊將服務器規模減少為原來的一半。另一種選擇是保持容器數量與虛擬機數量相同，這樣容器容量就更大，能夠使用更多的內存。
這并非理想的選擇，因為我們的確喜歡擴展I/O速率以及內存容量。這可能會迫使我們升級網絡設施。例如，采用兩個10Gb以太網連接而不是一個。和購買更高配置的服務器相比，這樣更節省成本。
采用更快的網絡、快速SSD有助于進一步改善IPOS，能夠節約成本使得難以拒絕容器虛擬化。實際上不需要購買額外的服務器就能夠將集群規模——以交付的工作負載作為衡量依據——擴大為原來的兩倍。我們可能需要在高速網絡上進行一些投入，而且可能要購買一些SSD，但總投資節省的費用還是相當可觀的。還需要考慮運營成本的節約，更少的服務器意味著更低的功耗、制冷以及更少的支持人員。
技術上存在障礙嗎?
容器仍舊在發展，這意味著某些功能還不成熟。這只是一個短期問題。系統對多租戶的支持仍舊在發展，用戶只有對多租戶支持感到滿意才會選擇使用容器。長期來看—大概是3年——我們將會看到容器虛擬化模式將會更多地采用經過壓縮的DRAM以及近線閃存的替代品。
容器倡議者談到容器增加了靈活性，能夠更快速地部署應用，而且安裝容器不像傳統hypervisor廠商那樣需要大量的許可費用。如果上述事實發生，那么成本將會大大節省。
不管在哪個方面，容器都勝出了。盡管容器會對服務器以及hypervisor廠商的收入帶來一些影響，它會大大降低企業成本。
京公網安備 11010502049343號