[[171670]]

繼OpenStack之后，這些天我被問(wèn)到的最多的話題是容器及其在企業(yè)及原生云應(yīng)用上的前景。很多人對(duì)容器取代類似VMware ESX或Linux KVM(多數(shù)OpenStack部署的默認(rèn)選項(xiàng))這類Hypervisor的前景尤其有興趣。然而，還存在一些誤區(qū)。很多人分不清容器與虛擬機(jī)的差異。還有些人為支持虛擬機(jī)，喜歡揮動(dòng)安全性大旗，堅(jiān)稱容器不安全。

這其中缺失的不僅是對(duì)基礎(chǔ)設(shè)施層面上容器是什么的正確理解，還有未來(lái)伴隨著各類瑣碎的更新后的容器可以是什么的正確理解。同時(shí)缺失的還有對(duì)VMware ESX這類正快速衰退的傳統(tǒng)Haypervisor價(jià)值的理解。從我的角度來(lái)看，虛擬機(jī)的時(shí)光正在消逝，只是這種變化發(fā)生有多快的問(wèn)題。

在此期間，容器需要運(yùn)行于虛擬機(jī)之上么?或者，運(yùn)行于裸機(jī)上的容器將簡(jiǎn)單地完全取代Hypervisor?

最后，OpenStack在這其中的位置是什么?與ESX不同，OpenStack不是一個(gè)Haypervisor，實(shí)際上，它可以與容器、虛擬機(jī)或裸機(jī)等友好共處。

我們來(lái)探討一下。

容器作為基礎(chǔ)設(shè)施 vs 容器作為以應(yīng)用程序?yàn)橹行牡拇虬c管理工具也許將來(lái)我會(huì)更多地討論這個(gè)話題，不過(guò)重要的是要理解，與虛擬機(jī)不同，容器具有兩個(gè)視角：它們是基礎(chǔ)設(shè)施(即“輕量級(jí)虛擬機(jī)”)?或是應(yīng)用程序管理與配置系統(tǒng)?事實(shí)是，它們兩者皆是。如果你是基礎(chǔ)設(shè)施人員，你可能會(huì)將其視為前者，如果是開(kāi)發(fā)人員，則可能會(huì)將其視為后者。

這指向了用于扁平化部分云技術(shù)棧的一個(gè)事實(shí)上的途徑，并提供了用于簡(jiǎn)化底層基礎(chǔ)設(shè)施及其與應(yīng)用程序交互的能力。我會(huì)在未來(lái)的文章中對(duì)此進(jìn)行詳述。

本文中，我將主要討論容器作為基礎(chǔ)設(shè)施工具的一面。

當(dāng)Hypervisor消亡時(shí)當(dāng)Intel通過(guò)Intel-VTx(https://en.wikipedia.org/wiki/X86_virtualization)指令集在芯片中直接提供Hypervisor所特有的眾多功能時(shí)，Hypervisor的喪鐘就已經(jīng)敲響。在此之前，VMware和Xen具有兩種特有的方法來(lái)提供Hypervisor功能：二進(jìn)制翻譯及半虛擬化。關(guān)于哪種方法更快的爭(zhēng)論不休，但是Intel-VTx一出現(xiàn)，憑借其在芯片中的優(yōu)勢(shì)，立即成為了事實(shí)上的速度贏家。在之后，VMware ESX及Xen都默認(rèn)使用了Intel-VTx。100%依賴于Intel-VTx芯片組這些功能的KVM應(yīng)運(yùn)而生。最為重要的可能是，它消除了“類型1”和“類型2”Hypervisor之間絕大部分的差異。

當(dāng)然，現(xiàn)在你會(huì)說(shuō)，Hypervisor依然有價(jià)值，不過(guò)這種價(jià)值已大不如前，并且主要集中在異構(gòu)環(huán)境中為傳統(tǒng)應(yīng)用程序提供支持。實(shí)際上，Hypervisor允許你在訪客系統(tǒng)(虛擬機(jī))中運(yùn)行不同的操作系統(tǒng)。

我來(lái)解釋一下。

Hypervisor中的半虛擬化驅(qū)動(dòng)層

Intel-VTx出現(xiàn)之后，管理現(xiàn)存的傳統(tǒng)“寵物”型(譯者注：有狀態(tài)應(yīng)用，需要關(guān)注其每個(gè)具體實(shí)例的運(yùn)行狀態(tài))工作負(fù)載的最大問(wèn)題在于支持各種各樣的操作系統(tǒng)。這是如今企業(yè)環(huán)境的現(xiàn)狀，支持異構(gòu)系統(tǒng)的關(guān)鍵在于支持這些系統(tǒng)。不幸的是，當(dāng)你在Intel-VTx上運(yùn)行未經(jīng)修改的內(nèi)核，涉及網(wǎng)絡(luò)和磁盤(pán)的系統(tǒng)調(diào)用依然會(huì)訪問(wèn)仿真硬件。Intel-VTx主要解決的問(wèn)題是：分離、隔離并允許高效訪問(wèn)直接的CPU調(diào)用及內(nèi)存訪問(wèn)(通過(guò)擴(kuò)展頁(yè)表[Extended Page Table，EPT]，https://en.wikipedia.org/wiki/Second_Level_Address_Translation)。Intel-VT未解決網(wǎng)絡(luò)與磁盤(pán)的訪問(wèn)，雖然SR-IOV、VT-d等嘗試解決這個(gè)問(wèn)題，但還離實(shí)現(xiàn)還很遠(yuǎn)。

為了維持更高的網(wǎng)絡(luò)和磁盤(pán)性能，主流Hypervisor都采用了半虛擬化驅(qū)動(dòng)。半虛擬化驅(qū)動(dòng)非常類似于Xten的半虛擬化內(nèi)核。在Hypervisor及其訪客操作系統(tǒng)中有一個(gè)用于網(wǎng)絡(luò)或磁盤(pán)的特殊的半虛擬化驅(qū)動(dòng)。你可以想像一下，這個(gè)驅(qū)動(dòng)被Hypervisor內(nèi)核與訪客內(nèi)核“劈成兩半”，從而允許更高的吞吐量。

取決于不同的工作負(fù)載，還是會(huì)有5-30%的網(wǎng)絡(luò)與磁盤(pán)性能影響。半虛擬化驅(qū)動(dòng)終究還是無(wú)法像裸機(jī)那樣操作。

除了性能問(wèn)題之外，半虛擬化(PV)驅(qū)動(dòng)還有其他問(wèn)題。其中之一：PV驅(qū)動(dòng)由不同的操作系統(tǒng)提供商編寫(xiě)，每個(gè)Hypervisor(ESX、Xen、KVM等等)以及每個(gè)訪問(wèn)操作系統(tǒng)(Windows 7、Windows 10、RHEL、Ubuntu、FreeBSD等等)都需要不同的PV驅(qū)動(dòng)。這會(huì)產(chǎn)生大量代碼、更大的可能被入侵的攻擊面、一個(gè)巨大的支持與測(cè)試矩陣，以及顯著的質(zhì)量差異。

最重要的是，Hypervisor自身只是用于支持PV驅(qū)動(dòng)的一層，而后者也是用于支持異構(gòu)操作系統(tǒng)的一層。

我們不得不問(wèn)道：“在企業(yè)數(shù)據(jù)中心，異構(gòu)操作系統(tǒng)還需要維持多久?”

企業(yè)數(shù)據(jù)中心的同質(zhì)化意味著容器將最終勝出在向原生云應(yīng)用程序及第三方平臺(tái)遷移時(shí)，我們都強(qiáng)烈地意識(shí)到需要對(duì)底層操作系統(tǒng)進(jìn)行標(biāo)準(zhǔn)化和規(guī)范化。如果你運(yùn)行著20個(gè)不同的操作系統(tǒng)，你無(wú)法獲得更高的運(yùn)維效率。如果你想要容器，那么你也將尋求在同質(zhì)化或近同質(zhì)化的環(huán)境中運(yùn)行它們。如果你正向任何類型的PaaS平臺(tái)遷移，你也是在標(biāo)準(zhǔn)化底層操作系統(tǒng)。隨處可見(jiàn)，我們正在遠(yuǎn)離異構(gòu)性。

在這樣的環(huán)境中，半虛擬化驅(qū)動(dòng)層(或者說(shuō)是Hypervisor)價(jià)值很小，甚至不存在。

Hypervisor的主要爭(zhēng)論是在于支持那些需要高級(jí)功能的工作負(fù)載，比如用于可用性的VMware DRS和HA、操作系統(tǒng)異構(gòu)性以及通過(guò)隔離獲得的“更高的安全性”。

對(duì)Hypervisor來(lái)說(shuō)不幸的是，在容器里所有這些功能都以這種或那種方式實(shí)現(xiàn)了。異構(gòu)性可能除外，但這完全不是問(wèn)題。

容器與安全性

有個(gè)流行的論調(diào)，認(rèn)為容器比Hypervisor“不安全”，無(wú)視一個(gè)事實(shí)：對(duì)一些人來(lái)說(shuō)，容器的初衷是作為一項(xiàng)應(yīng)用程序安全機(jī)制。它們可以將應(yīng)用程序打包進(jìn)一個(gè)非常低的攻擊面里，在一個(gè)隔離的牢籠中以非特權(quán)用戶進(jìn)行運(yùn)行。這遠(yuǎn)比典型的基于虛擬機(jī)的方式要好得多，在后者你面對(duì)的是整個(gè)操作系統(tǒng)，不得不對(duì)其定期打補(bǔ)丁和維護(hù)。

不過(guò)很多人會(huì)指出Hypervisor用于提供隔離性的魔法，比如擴(kuò)展頁(yè)表(EPT)。但是，EPT，以及Hypervisor很多功能已經(jīng)不再由Hypervisor自身提供，而是由Intel-VTx指令集提供。讓Linux內(nèi)核調(diào)用這些指令并沒(méi)什么特殊之處。實(shí)際上，斯坦福的DUNE項(xiàng)目(http://dune.scs.stanford.edu/)釋出的代碼就能為常規(guī)應(yīng)用程序做到這點(diǎn)。將其整合到容器平臺(tái)中也是小菜一碟。

可以期待的是，Intel將繼續(xù)豐富Intel-VTx指令集，且Linux內(nèi)核和容器將不需要Hypervisor作為中介即可利用這些功能。

在去除了Hypervisor虛擬機(jī)中強(qiáng)制包裹著應(yīng)用程序的絕大部分操作系統(tǒng)，容器可能實(shí)際已經(jīng)比Hypervisor模式要安全。不過(guò)，我們可以肯定地說(shuō)，經(jīng)過(guò)些時(shí)日，這必然成真。

容器與彈性

接著，我們必須問(wèn)這個(gè)問(wèn)題：“DRS和HA呢?”考慮到這些功能很大程度在于支持“寵物”型工作負(fù)載這一事實(shí)，容器并無(wú)此需求，現(xiàn)實(shí)的情況就是，在一個(gè)彈性的第三方平臺(tái)中，DRS和HA完全是多余的。PaaS工具如Cloud Foundry、容器管理系統(tǒng)如Kubernetes、Rancher、Mesos，及類似的管理工具已經(jīng)設(shè)計(jì)用于擴(kuò)展工作負(fù)載。它們會(huì)在運(yùn)行的應(yīng)用程序里檢測(cè)性能和失效問(wèn)題，并提前應(yīng)對(duì)。

這能讓我們明白：Hypervisor唯一的價(jià)值在于使用PV驅(qū)動(dòng)支持多種操作系統(tǒng)，下一代數(shù)據(jù)中心并無(wú)此需求。

變化的圖景

為幫助你理解變化的可能樣子，游戲的結(jié)局視圖是這樣的，它假定Hypervisor在第二代平臺(tái)“勝出”，并作為支持傳統(tǒng)工作負(fù)載的關(guān)鍵工具;而容器則在原生云應(yīng)用程序的第三代平臺(tái)“勝出”，并成為支持現(xiàn)代數(shù)據(jù)中心及其工作負(fù)載的主要工具

這個(gè)圖示有些過(guò)于簡(jiǎn)單，不過(guò)我這里想展示的是：如果你無(wú)須考慮多個(gè)訪問(wèn)操作系統(tǒng)，如果你將斯坦福的DUNE庫(kù)整合到容器中，如果你依賴于標(biāo)準(zhǔn)的Linux用戶權(quán)限，如果你只想與物理資源直接通訊，容器是：

性能卓越

只要正確配置，可能就跟任何Hypervisor一樣安全

遠(yuǎn)比Hypervisor簡(jiǎn)單，額外開(kāi)銷和操作系統(tǒng)占用更少

第三點(diǎn)值得多說(shuō)幾句。要詳細(xì)說(shuō)明這一點(diǎn)，可能需要額外一篇博客文章，不過(guò)以下是它的基本概念。以容器為中心的模式不僅如你所見(jiàn)極大簡(jiǎn)化了應(yīng)用程序架構(gòu)，消除了Hypervisor層帶來(lái)的額外層及消耗，還允許進(jìn)一步“扁平化”基礎(chǔ)設(shè)施棧。這是什么意思?我是說(shuō)，當(dāng)我們變得以容器為中心時(shí)，我們自然變得以應(yīng)用程序?yàn)橹行摹?yīng)用無(wú)須關(guān)心基礎(chǔ)設(shè)施拓?fù)洹Ｋ鼈冇卸嗌賶K磁盤(pán)，是什么類型的，是什么樣的網(wǎng)絡(luò)。全都無(wú)所謂。應(yīng)用及現(xiàn)代原生云應(yīng)用開(kāi)發(fā)人員只關(guān)心基礎(chǔ)設(shè)施約定：調(diào)用一個(gè)API，將獲得基礎(chǔ)設(shè)施資源，其性能可能能達(dá)到它的SLA也可能不能，如果它不能達(dá)到就殺掉并使用其他資源來(lái)替代，如果所請(qǐng)求的基礎(chǔ)設(shè)施的資源即將耗盡，我會(huì)請(qǐng)求另外一個(gè)(水平擴(kuò)展)。

我認(rèn)為有一點(diǎn)是值得考慮的，Hypervisor及“寵物”型思維模式將驅(qū)使我們創(chuàng)造過(guò)度的、復(fù)雜的基礎(chǔ)設(shè)施拓?fù)洌@是現(xiàn)代應(yīng)用程序完全不需要的。

OpenStack 容器，還是OpenStack vs 容器?對(duì)有些人來(lái)說(shuō)，會(huì)有一個(gè)問(wèn)題，原生云應(yīng)用程序和現(xiàn)代數(shù)據(jù)中心中占主導(dǎo)地位的是OpenStack還是容器生態(tài)系統(tǒng)。對(duì)其他人來(lái)說(shuō)，這些系統(tǒng)則是協(xié)同工作的。雙方都有很好的論點(diǎn)。一方面，OpenStack看起來(lái)像是用于點(diǎn)燃基礎(chǔ)設(shè)施即服務(wù)(IaaS)的復(fù)雜的、過(guò)度的嘗試。另一方面，沒(méi)有其他生態(tài)系統(tǒng)能像它這樣全面，包括了DNS服務(wù)器、網(wǎng)絡(luò)服務(wù)、存儲(chǔ)、虛擬機(jī)、裸機(jī)、容器、數(shù)據(jù)庫(kù)服務(wù)、密鑰管理等等。

當(dāng)你看到OpenStack之上主要的“PaaS”平臺(tái)(http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf)都是基于容器(Kubernetes、Cloud Foundry等等)的，你也許會(huì)對(duì)此更困惑。越來(lái)越多的客戶選擇使用OpenStack和KVM虛擬機(jī)作為運(yùn)行底層。CloudFoundry這類以容器為基礎(chǔ)的平臺(tái)為一般的企業(yè)開(kāi)發(fā)人員提供了集結(jié)和隱藏OpenStack復(fù)雜度的終極工具。

看起來(lái)正在發(fā)生的一個(gè)前進(jìn)方向是，Hypervisor和容器會(huì)在中短期內(nèi)共存，但隨著時(shí)間的推移，技術(shù)棧趨于扁平，我們將開(kāi)始直接在裸機(jī)系統(tǒng)上運(yùn)行容器，在提供更好的安全性、可用性和性能的同時(shí)，去除Hypervisor、簡(jiǎn)化技術(shù)棧。最終，我們將看到類似這樣的圖景。

巨輪已經(jīng)出港在我看來(lái)，Hypervisor的巨輪已經(jīng)出港。對(duì)于下一代原生云應(yīng)用程序而言，現(xiàn)在是容器的時(shí)代，剩下的只是時(shí)間的問(wèn)題。在此期間，在虛擬化底層之上運(yùn)行容器“只是用于啟動(dòng)”的一種普通方法，而用于直接在裸機(jī)上運(yùn)行容器的底層技術(shù)也會(huì)越來(lái)越好。現(xiàn)代的數(shù)據(jù)中心將相對(duì)同質(zhì)化，就像為我們帶來(lái)云計(jì)算的Web擴(kuò)展公司一樣。它將主要托管那些使用類似Cloud Foundry這類平臺(tái)來(lái)管理自身彈性的原生云應(yīng)用程序，同時(shí)隨著容器及其生態(tài)系統(tǒng)的發(fā)展，它將比以往更安全、性能更佳、利用率也更高。

我樂(lè)見(jiàn)其成，相信你也一樣。