繼OpenStack之后，這些天我被問到的最多的話題是容器及其在企業(yè)及原生云應(yīng)用上的前景。很多人對容器取代類似VMware ESX或Linux KVM(多數(shù)OpenStack部署的默認選項)這類Hypervisor的前景尤其有興趣。然而，還存在一些誤區(qū)。很多人分不清容器與虛擬機的差異。還有些人為支持虛擬機，喜歡揮動安全性大旗，堅稱容器不安全。
這其中缺失的不僅是對基礎(chǔ)設(shè)施層面上容器是什么的正確理解，還有未來伴隨著各類瑣碎的更新后的容器可以是什么的正確理解。同時缺失的還有對VMware ESX這類正快速衰退的傳統(tǒng)Haypervisor價值的理解。從我的角度來看，虛擬機的時光正在消逝，只是這種變化發(fā)生有多快的問題。
在此期間，容器需要運行于虛擬機之上么?或者，運行于裸機上的容器將簡單地完全取代Hypervisor?
最后，OpenStack在這其中的位置是什么?與ESX不同，OpenStack不是一個Haypervisor，實際上，它可以與容器、虛擬機或裸機等友好共處。
我們來探討一下。
容器作為基礎(chǔ)設(shè)施 vs 容器作為以應(yīng)用程序為中心的打包與管理工具也許將來我會更多地討論這個話題，不過重要的是要理解，與虛擬機不同，容器具有兩個視角：它們是基礎(chǔ)設(shè)施(即“輕量級虛擬機”)?或是應(yīng)用程序管理與配置系統(tǒng)?事實是，它們兩者皆是。如果你是基礎(chǔ)設(shè)施人員，你可能會將其視為前者，如果是開發(fā)人員，則可能會將其視為后者。
這指向了用于扁平化部分云技術(shù)棧的一個事實上的途徑，并提供了用于簡化底層基礎(chǔ)設(shè)施及其與應(yīng)用程序交互的能力。我會在未來的文章中對此進行詳述。
本文中，我將主要討論容器作為基礎(chǔ)設(shè)施工具的一面。
當Hypervisor消亡時當Intel通過Intel-VTx(https://en.wikipedia.org/wiki/X86_virtualization)指令集在芯片中直接提供Hypervisor所特有的眾多功能時，Hypervisor的喪鐘就已經(jīng)敲響。在此之前，VMware和Xen具有兩種特有的方法來提供Hypervisor功能：二進制翻譯及半虛擬化。關(guān)于哪種方法更快的爭論不休，但是Intel-VTx一出現(xiàn)，憑借其在芯片中的優(yōu)勢，立即成為了事實上的速度贏家。在之后，VMware ESX及Xen都默認使用了Intel-VTx。100%依賴于Intel-VTx芯片組這些功能的KVM應(yīng)運而生。最為重要的可能是，它消除了“類型1”和“類型2”Hypervisor之間絕大部分的差異。
當然，現(xiàn)在你會說，Hypervisor依然有價值，不過這種價值已大不如前，并且主要集中在異構(gòu)環(huán)境中為傳統(tǒng)應(yīng)用程序提供支持。實際上，Hypervisor允許你在訪客系統(tǒng)(虛擬機)中運行不同的操作系統(tǒng)。
我來解釋一下。
Hypervisor中的半虛擬化驅(qū)動層
Intel-VTx出現(xiàn)之后，管理現(xiàn)存的傳統(tǒng)“寵物”型(譯者注：有狀態(tài)應(yīng)用，需要關(guān)注其每個具體實例的運行狀態(tài))工作負載的最大問題在于支持各種各樣的操作系統(tǒng)。這是如今企業(yè)環(huán)境的現(xiàn)狀，支持異構(gòu)系統(tǒng)的關(guān)鍵在于支持這些系統(tǒng)。不幸的是，當你在Intel-VTx上運行未經(jīng)修改的內(nèi)核，涉及網(wǎng)絡(luò)和磁盤的系統(tǒng)調(diào)用依然會訪問仿真硬件。Intel-VTx主要解決的問題是：分離、隔離并允許高效訪問直接的CPU調(diào)用及內(nèi)存訪問(通過擴展頁表[Extended Page Table，EPT]，https://en.wikipedia.org/wiki/Second_Level_Address_Translation)。Intel-VT未解決網(wǎng)絡(luò)與磁盤的訪問，雖然SR-IOV、VT-d等嘗試解決這個問題，但還離實現(xiàn)還很遠。
為了維持更高的網(wǎng)絡(luò)和磁盤性能，主流Hypervisor都采用了半虛擬化驅(qū)動。半虛擬化驅(qū)動非常類似于Xten的半虛擬化內(nèi)核。在Hypervisor及其訪客操作系統(tǒng)中有一個用于網(wǎng)絡(luò)或磁盤的特殊的半虛擬化驅(qū)動。你可以想像一下，這個驅(qū)動被Hypervisor內(nèi)核與訪客內(nèi)核“劈成兩半”，從而允許更高的吞吐量。
取決于不同的工作負載，還是會有5-30%的網(wǎng)絡(luò)與磁盤性能影響。半虛擬化驅(qū)動終究還是無法像裸機那樣操作。
除了性能問題之外，半虛擬化(PV)驅(qū)動還有其他問題。其中之一：PV驅(qū)動由不同的操作系統(tǒng)提供商編寫，每個Hypervisor(ESX、Xen、KVM等等)以及每個訪問操作系統(tǒng)(Windows 7、Windows 10、RHEL、Ubuntu、FreeBSD等等)都需要不同的PV驅(qū)動。這會產(chǎn)生大量代碼、更大的可能被入侵的攻擊面、一個巨大的支持與測試矩陣，以及顯著的質(zhì)量差異。
最重要的是，Hypervisor自身只是用于支持PV驅(qū)動的一層，而后者也是用于支持異構(gòu)操作系統(tǒng)的一層。
我們不得不問道：“在企業(yè)數(shù)據(jù)中心，異構(gòu)操作系統(tǒng)還需要維持多久?”
企業(yè)數(shù)據(jù)中心的同質(zhì)化意味著容器將最終勝出在向原生云應(yīng)用程序及第三方平臺遷移時，我們都強烈地意識到需要對底層操作系統(tǒng)進行標準化和規(guī)范化。如果你運行著20個不同的操作系統(tǒng)，你無法獲得更高的運維效率。如果你想要容器，那么你也將尋求在同質(zhì)化或近同質(zhì)化的環(huán)境中運行它們。如果你正向任何類型的PaaS平臺遷移，你也是在標準化底層操作系統(tǒng)。隨處可見，我們正在遠離異構(gòu)性。
在這樣的環(huán)境中，半虛擬化驅(qū)動層(或者說是Hypervisor)價值很小，甚至不存在。
Hypervisor的主要爭論是在于支持那些需要高級功能的工作負載，比如用于可用性的VMware DRS和HA、操作系統(tǒng)異構(gòu)性以及通過隔離獲得的“更高的安全性”。
對Hypervisor來說不幸的是，在容器里所有這些功能都以這種或那種方式實現(xiàn)了。異構(gòu)性可能除外，但這完全不是問題。
容器與安全性
有個流行的論調(diào)，認為容器比Hypervisor“不安全”，無視一個事實：對一些人來說，容器的初衷是作為一項應(yīng)用程序安全機制。它們可以將應(yīng)用程序打包進一個非常低的攻擊面里，在一個隔離的牢籠中以非特權(quán)用戶進行運行。這遠比典型的基于虛擬機的方式要好得多，在后者你面對的是整個操作系統(tǒng)，不得不對其定期打補丁和維護。
不過很多人會指出Hypervisor用于提供隔離性的魔法，比如擴展頁表(EPT)。但是，EPT，以及Hypervisor很多功能已經(jīng)不再由Hypervisor自身提供，而是由Intel-VTx指令集提供。讓Linux內(nèi)核調(diào)用這些指令并沒什么特殊之處。實際上，斯坦福的DUNE項目(http://dune.scs.stanford.edu/)釋出的代碼就能為常規(guī)應(yīng)用程序做到這點。將其整合到容器平臺中也是小菜一碟。
可以期待的是，Intel將繼續(xù)豐富Intel-VTx指令集，且Linux內(nèi)核和容器將不需要Hypervisor作為中介即可利用這些功能。
在去除了Hypervisor虛擬機中強制包裹著應(yīng)用程序的絕大部分操作系統(tǒng)，容器可能實際已經(jīng)比Hypervisor模式要安全。不過，我們可以肯定地說，經(jīng)過些時日，這必然成真。
容器與彈性
接著，我們必須問這個問題：“DRS和HA呢?”考慮到這些功能很大程度在于支持“寵物”型工作負載這一事實，容器并無此需求，現(xiàn)實的情況就是，在一個彈性的第三方平臺中，DRS和HA完全是多余的。PaaS工具如Cloud Foundry、容器管理系統(tǒng)如Kubernetes、Rancher、Mesos，及類似的管理工具已經(jīng)設(shè)計用于擴展工作負載。它們會在運行的應(yīng)用程序里檢測性能和失效問題，并提前應(yīng)對。
這能讓我們明白：Hypervisor唯一的價值在于使用PV驅(qū)動支持多種操作系統(tǒng)，下一代數(shù)據(jù)中心并無此需求。
變化的圖景
為幫助你理解變化的可能樣子，游戲的結(jié)局視圖是這樣的，它假定Hypervisor在第二代平臺“勝出”，并作為支持傳統(tǒng)工作負載的關(guān)鍵工具;而容器則在原生云應(yīng)用程序的第三代平臺“勝出”，并成為支持現(xiàn)代數(shù)據(jù)中心及其工作負載的主要工具
這個圖示有些過于簡單，不過我這里想展示的是：如果你無須考慮多個訪問操作系統(tǒng)，如果你將斯坦福的DUNE庫整合到容器中，如果你依賴于標準的Linux用戶權(quán)限，如果你只想與物理資源直接通訊，容器是：
性能卓越
只要正確配置，可能就跟任何Hypervisor一樣安全
遠比Hypervisor簡單，額外開銷和操作系統(tǒng)占用更少
第三點值得多說幾句。要詳細說明這一點，可能需要額外一篇博客文章，不過以下是它的基本概念。以容器為中心的模式不僅如你所見極大簡化了應(yīng)用程序架構(gòu)，消除了Hypervisor層帶來的額外層及消耗，還允許進一步“扁平化”基礎(chǔ)設(shè)施棧。這是什么意思?我是說，當我們變得以容器為中心時，我們自然變得以應(yīng)用程序為中心。應(yīng)用無須關(guān)心基礎(chǔ)設(shè)施拓撲。它們有多少塊磁盤，是什么類型的，是什么樣的網(wǎng)絡(luò)。全都無所謂。應(yīng)用及現(xiàn)代原生云應(yīng)用開發(fā)人員只關(guān)心基礎(chǔ)設(shè)施約定：調(diào)用一個API，將獲得基礎(chǔ)設(shè)施資源，其性能可能能達到它的SLA也可能不能，如果它不能達到就殺掉并使用其他資源來替代，如果所請求的基礎(chǔ)設(shè)施的資源即將耗盡，我會請求另外一個(水平擴展)。
我認為有一點是值得考慮的，Hypervisor及“寵物”型思維模式將驅(qū)使我們創(chuàng)造過度的、復(fù)雜的基礎(chǔ)設(shè)施拓撲，這是現(xiàn)代應(yīng)用程序完全不需要的。
OpenStack 容器，還是OpenStack vs 容器?對有些人來說，會有一個問題，原生云應(yīng)用程序和現(xiàn)代數(shù)據(jù)中心中占主導(dǎo)地位的是OpenStack還是容器生態(tài)系統(tǒng)。對其他人來說，這些系統(tǒng)則是協(xié)同工作的。雙方都有很好的論點。一方面，OpenStack看起來像是用于點燃基礎(chǔ)設(shè)施即服務(wù)(IaaS)的復(fù)雜的、過度的嘗試。另一方面，沒有其他生態(tài)系統(tǒng)能像它這樣全面，包括了DNS服務(wù)器、網(wǎng)絡(luò)服務(wù)、存儲、虛擬機、裸機、容器、數(shù)據(jù)庫服務(wù)、密鑰管理等等。
當你看到OpenStack之上主要的“PaaS”平臺(http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf)都是基于容器(Kubernetes、Cloud Foundry等等)的，你也許會對此更困惑。越來越多的客戶選擇使用OpenStack和KVM虛擬機作為運行底層。CloudFoundry這類以容器為基礎(chǔ)的平臺為一般的企業(yè)開發(fā)人員提供了集結(jié)和隱藏OpenStack復(fù)雜度的終極工具。
看起來正在發(fā)生的一個前進方向是，Hypervisor和容器會在中短期內(nèi)共存，但隨著時間的推移，技術(shù)棧趨于扁平，我們將開始直接在裸機系統(tǒng)上運行容器，在提供更好的安全性、可用性和性能的同時，去除Hypervisor、簡化技術(shù)棧。最終，我們將看到類似這樣的圖景。
巨輪已經(jīng)出港在我看來，Hypervisor的巨輪已經(jīng)出港。對于下一代原生云應(yīng)用程序而言，現(xiàn)在是容器的時代，剩下的只是時間的問題。在此期間，在虛擬化底層之上運行容器“只是用于啟動”的一種普通方法，而用于直接在裸機上運行容器的底層技術(shù)也會越來越好。現(xiàn)代的數(shù)據(jù)中心將相對同質(zhì)化，就像為我們帶來云計算的Web擴展公司一樣。它將主要托管那些使用類似Cloud Foundry這類平臺來管理自身彈性的原生云應(yīng)用程序，同時隨著容器及其生態(tài)系統(tǒng)的發(fā)展，它將比以往更安全、性能更佳、利用率也更高。
我樂見其成，相信你也一樣。
京公網(wǎng)安備 11010502049343號