虛擬機和Linux Container的性能比較
IBM研究部門發(fā)表了一篇關(guān)于容器和虛擬機環(huán)境性能比較的論文。這篇論文使用了Docker和KVM作為研究對象，闡述了Docker使用NAT或AUFS時的開銷，并且質(zhì)疑了在虛擬機上運行容器的實踐方法。
論文作者在原生、容器和虛擬化環(huán)境中運行了CPU、內(nèi)存、網(wǎng)絡和I/O的benchmark。其中，分別使用KVM和Docker作為虛擬化和容器技術(shù)的代表。Benchmark也包含了對不同環(huán)境下Redis和MySQL負載的采樣。通過小數(shù)據(jù)包和多客戶端，Redis側(cè)重于網(wǎng)絡棧的性能。而MySQL側(cè)重于內(nèi)存，網(wǎng)絡和文件系統(tǒng)的性能。
結(jié)果顯示，在每一項測試中，Docker的性能等同于或超出KVM的性能。在CPU和內(nèi)存性能方面，KVM和Docker都引入了明顯的，但可略不計的開銷。但是，對于I/O密集型的應用，兩者都需要進行調(diào)整以減少開銷帶來的影響。
當使用AUFS存儲文件時，Docker的性能會降低。而相比之下，使用卷（volume）能夠獲得更好的性能。卷是一種專門設計的目錄，存在于一個或多個容器內(nèi)。通過這種目錄能夠繞過聯(lián)合文件系統(tǒng)（union file system）。這樣它就沒有了存儲后端可能帶來的開銷。默認的AUFS后端會引起顯著的I/O開銷，特別是當有多層目錄深度嵌套的時候。
Docker的默認網(wǎng)絡選項，--net=bridge，由于NAT會重寫數(shù)據(jù)包，也引入了性能開銷。當數(shù)據(jù)包收發(fā)率變高時，這種開銷會變得很明顯。可以通過使用--net=host改善網(wǎng)絡的性能。這個選項告訴Docker不要為容器創(chuàng)建一個獨立的網(wǎng)絡棧，并允許容器擁有宿主機網(wǎng)絡接口的完全訪問權(quán)限。但是，使用這個選項時要小心。因為它允許容器內(nèi)的進程像其他根進程一樣，使用數(shù)值較小的端口；并允許容器內(nèi)的進程訪問本地網(wǎng)絡服務，如D-bus。這使得容器內(nèi)的進程可以做一些預料之外的事情，如重啟宿主機。
盡管自誕生以來，KVM性能有了相當大的提升，但它仍然不適用于對延時敏感或高I/O訪問率的工作負載。因為每次I/O操作，它都會增加一些開銷。這個開銷對于耗時較少的I/O操作是有意義的，但對于耗時較長的I/O操作是可以忽略的。
根據(jù)這些測試結(jié)果，論文對使用虛擬機實現(xiàn)IaaS的方法提出了質(zhì)疑：
傳統(tǒng)觀點（在某種程度上，這種觀點存在于年輕的云生態(tài)圈中）認為使用虛擬機實現(xiàn)IaaS，使用容器實現(xiàn)PaaS。我們沒有找到技術(shù)方面的理由來證明必須這么做，尤其是證明容器基于IaaS能提供更好的性能或者更容易部署。由于容器提供了控制手段，并在不使用虛擬機的情況下能達到物理機的性能，所以它能夠消除IaaS和非虛擬化的服務器間的差異。
盡管在虛擬環(huán)境中運行容器是一種常見的實踐方法，但是論文建議直接在物理的Linux服務器上運行它們。否則，相比于直接運行在非虛擬化的Linux上的方法，由于虛擬機的性能開銷，這種實踐方法不會得到任何額外的好處。
參考英文原文：Comparing Virtual Machines and Linux Containers Performance
