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