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