當下雲計算的領域裡熱度最高的兩個專案，無疑是OpenStack和Kubernetes。如果雲計算是一個風起雲湧的江湖，毫不誇張的說OpenStack和Kubernetes就是江湖裡的泰山北斗。OpenStack就像是少林，基礎紮實、沉穩厚重，而Kubernetes就是武當，輕巧空靈、飄逸精妙。使用過這兩種系統的人都應該有這樣的感受，OpenStack出身於虛擬化技術，穩定但速度慢，Kubernetes則來自於容器技術，快速但有侷限。兩種不同的技術就決定了有著不同的人生軌跡。那麼究竟兩者有著怎樣的際遇呢？我們分析分析。
出身對比：
OpenStack：
2010年7月，RackSpace公司和美國國家航空航天局NASA合作，分別貢獻出了RackSpack雲檔案平臺程式碼和NASA平臺程式碼，釋出OpenStack的第一個版本Austin。2010的Rackspace是美國第二大雲計算廠商，但規模只能佔到亞馬遜的5%。只依靠內部的力量來超越或者追趕亞馬遜不大可能，這家公司就把自己的專案開源了，也就是後來的 OpenStack 的儲存原始碼（swift）。與此同時NASA也對自己使用的 Eucalyptus 雲計算管理平臺很不爽。NASA想給Eucalyptus開源版本貢獻，結果Eucalyptus不接受。當時NASA 的六個開發人員，用了一個星期時間拿Python做出來一套原型，結果虛擬機器在這上面執行的很成功，這就是Nova（計算原始碼）的起源。Austin只有swift和Nova這兩個專案，即目前的物件儲存和計算服務。此後OpenStack大概保持著每半年釋出一次版本的頻率，截止到目前最新的版本是Rocky。在最新的版本中專案已經達到60多個。
Kubernetes：
Kubernetes是Google在2014年釋出的一個開源專案。Google開發了一個叫Brog的系統來排程內部數量龐大的容器和工作負載。在積累了多年經驗之後，Google決定重寫這個容器管理，並將其貢獻到開源社群，讓全世界都能夠受益。在2014年第一個版本釋出以來，Kubernetes迅速受到開源社群的的追捧，目前Kubernetes已經成為發展最快，市場佔有率最高的容器編排引擎。截止到現在，Kubernetes的最新版本是1.11版本。
Kubernetes版本釋出表：
技術實現
OpenStack：虛擬化
OpenStack作為一個開源的雲計算平臺，利用虛擬化技術和底層儲存服務，提供了可擴充套件，靈活，適應性強的雲計算服務。虛擬化是雲計算的基礎。簡單的說，虛擬化使得在一臺物理的伺服器上可以跑多臺虛擬機器，虛擬機器共享物理機的CPU、記憶體、IO硬體資源，但邏輯上虛擬機器之間是相互隔離的。宿主機一般使用hypervisor程式實現硬體資源虛擬化，並提供給客戶機使用。如下圖所示是一種虛擬化的架構。
每一個虛擬機器都擁有自己的核心和檔案系統，完全是一個獨立的作業系統。而上圖是兩種虛擬化方式中的其中一種：半虛擬化——KVM。在目前的環境中，KVM虛擬化技術是使用率最高的技術。
虛擬化優點:隔離性強，所有的虛擬機器都有自己的協議棧，各個虛擬機器底層相互隔離。
虛擬化缺點：資源佔用多，虛擬化技術本身佔用資源，宿主機效能有10%左右的消耗。
Kubernetes：docker
Kubernetes是容器管理編排引擎，那麼底層實現自然是容器技術。容器是一種輕量級、可移植、自包含的軟體打包技術，打包的應用程式可以在幾乎任何地方以相同的方式執行。以容器典型代表docker為例，docker起源於2013年3月，是基於LXC為基礎構建的容器引擎，透過namespace和cgourp實現了資源隔離和調配，使用分層儲存來構建映象。它基於Google公司推出的Go語言實現。docker相比KVM虛擬化技術最明顯的特點就是啟動快，資源佔用小。虛擬化啟動虛擬機器是分鐘級別的，而docker是秒級別的。如下是docker的架構圖。
docker的啟動速度快，佔用資源少，原因在於技術架構：
一個作業系統分為核心+檔案系統。容器技術就是使用宿主機的核心系統加上自身的檔案系統。執行容器時是在使用宿主機的核心情況下載入檔案系統，精簡的檔案系統可以小到100MB以內，所以比虛擬機器自然要快很多。可以將容器看作是在核心上執行的獨立程式碼單元，它們非常輕。因此佔用的資源也少。
容器優點：啟動快，資源佔用小，移植性好
容器缺點：隔離性不好，共用宿主機的核心，底層能夠訪問。依賴宿主機核心所以容器的系統選擇有限制。
架構對比
OpenStack：
OpenStack的服務分為核心功能和非核心功能。核心功能是指執行OpenStack系統必須的功能，其中核心功能有：
其工作模式如下：
在“為什麼選擇OpenStack”的使用者調查中得出一個比例很高的結果是：開放平臺和標準化的API。OpenStack貫徹松耦解耦的思想，各個服務之間使用標準的API介面呼叫，並且這些介面是能夠開發給非OpenStack程式去呼叫。
具體到OpenStack就是Resutful（表述性狀態轉移）和RPC（遠端過程呼叫）。服務與服務之間使用Restful API通訊，最大程度地減少了服務之間的依賴。例如建立虛擬機器時，nova服務要呼叫glance服務，要呼叫neutron服務，這些都是透過Restful api 來完成的。服務內部的模組之間的呼叫使用了RPC，增加了橫向擴充套件能力。例如nova-api接收到建立虛擬機器的請求，要先後呼叫nova-scheduler 選定建立虛擬機器的主機，nova-compte完成虛擬機器建立的具體工作。此外，opnestack用到的通用技術還有：
1. 訊息匯流排 AMQP
2. ORM模型資料庫 SQLalchemy
3. WSGI Web伺服器網管介面
4. Eventlet 協程
OpenStack採用開源技術，避免重複製造輪子，這對團隊的技術選擇有著借鑑意義。
Kubernetes：
Kubernetes的思想是儘量保證使用者的理想狀態。通俗來說就是使用者建立了3個容器，Kubernetes要保證這三個容器的生命，時時刻刻都是健康的三個容器，受到斷電等故障的情況能夠及時補上。Kubernetes是由Master和Node組成，Master是大腦，Node是計算節點。
如下圖的構成：
在Master節點上執行的服務有：
1. API Server：提供Restful api。各種客戶端工具或者其他元件可以呼叫其完成資源呼叫。
2. Scheduler：排程服務，決定將容器建立在哪個Node上。
3. Controller Manager：管理系統中各種資源，保證資源處於預期的狀態。
4. Etcd:儲存系統的配置資訊和各種資源的狀態資訊。
5. Pod網路：可以是macvlan、flannel、weave、calico等其中的一種。
Node節點的服務：
1. kubelet ：接收Master節點發來的建立請求資訊，並向Master報告執行狀態。
2. kube-proxy ：訪問控制。
同樣以建立一個服務的方式來解析整個系統的運作流程。Kubernetes 客戶端傳送建立請求到系統，API server接收到請求，並通知controller建立一個deployment資源，controller負責具體的建立過程，呼叫Scheduler選擇哪個主機建立，然後將請求發往Node節點，Node節點上的kubelet接收到請求，建立具體的docker。
Kubernetes同樣遵循標準化API介面。
Kubernetes API是集群系統中的重要組成部分，Kubernetes中各種資源（物件）的資料透過該API介面被提交到後端的持久化儲存（etcd）中，Kubernetes叢集中的各部件之間透過該API介面實現解耦合，同時叢集中一個重要且便捷的管理工具kubectl也是透過訪問該API介面實現其強大的管理功能的。系統中大多數情況下，API定義和實現都符合標準的HTTP REST格式，比如透過標準的HTTP動詞（POST、PUT、GET、DELETE）來完成對相關資源物件的查詢、建立、修改、刪除等操作。但同時Kubernetes 也為某些非標準的REST行為實現了附加的API介面，例如Watch某個資源的變化、進入容器執行某個操作等。
使用場景
OpenStack：
場景一：安全和隔離。OpenStack適用於搭建私有云以及基於私有云的使用的場景。OpenStack底層使用了虛擬化技術，其基因中就有著隔離性好，穩定，部署靈活等特點。在OpenStack的成功案例中，雲桌面是典型的例子。有不少的企業都已經將自己的生產環境搬到雲端，例如企業上雲，工作環境就是使用雲桌面的形式。第一是降低了裝置成本，上雲之前是每人一臺主機，到現在幾十個人使用一臺伺服器，如果考慮cpu，記憶體使用率，成本肯定降下來了。第二是安全，所有的資料都不是儲存在身邊，在一些安全係數高的行業中尤為重要。OpenStack一直受到金融行業的青睞，這裡少不了看中OpenStack安全的特性。
場景二：提供基礎設施。OpenStack是定位於laas平臺的專案，其優點是能夠提供虛擬機器這種很底層的設施。如果在業務場景中很依賴虛擬機器，例如編譯核心，或者驅動開發等這些場景，那麼OpenStack是很好的選擇。
場景三：儲存需求。儲存是OpenStack另一個優勢所在。OpenStack第一個版本的專案組成就是儲存和計算，在後期不斷的開發中，儲存作為一個重要的功能一直不斷的完善和創新。如cinder塊儲存，ceph共享儲存能。在儲存需求很大的場景下，OpenStack能夠提供高效，安全的儲存方案，這也是為什麼電信行業看好OpenStack的一個原因。
場景四：動態資料場景。即不需要反覆地建立和銷燬這些服務的執行環境。虛擬機器優勢在於穩定，那麼OpenStack優勢也在於執行穩定的專案。
Kubernetes：
場景一：Kubernetes適用於業務變化快，業務量未知的靜態使用場景。所謂靜態使用場景是指在其建立的容器中不會實時產生資料的場景。例如：網站架構，一次部署，長時間使用。特別是遇到一些線上業務量不確定的場景，Kubernetes能夠動態擴充套件，靈活伸縮，從5W的併發量到10W的併發量，完全可以秒級處理。
場景二：需要反覆地建立和銷燬這些服務的執行環境。docker的優勢就在於啟動快速，消耗資源小。所以在需要頻繁建立和銷燬的場景中，Kubernetes是一個不錯的選擇。
場景三：需要業務模組化和可伸縮性：容器可以很容易地將應用程式的功能分解為單個元件，符合微服務架構的設計模式。
場景四：應用雲化。將已有應用、要新開發的應用打造成雲原生應用，發揮雲平臺的可擴充套件、彈性、高可用等特性，並藉助PaaS層提供的API實現更高階的特性，比如自動恢復、定製化的彈性伸縮等。
場景五：微服務架構和API管理。服務拆分來抽象不同系統的許可權控制和任務，以方便業務開發人員透過服務組合快速的建立企業應用。有的企業在沒有對應的管理平臺之前就已經將應用拆分成很多服務，如何部署這些微服務和進行API許可權控制，則成了需要解決的問題，而Kubernetes代表的PaaS則是理想的選擇。
社群對比
對於開源專案來說，社群火熱程度代表著生命力和潛力。如何判斷一個專案的未來發展，關注社群肯定是最基本的要求。
OpenStack：
OpenStack是開源專案的代表作之一。
OpenStack從第一個版本開始到現在的R版本的開發過程，為探索開源生態交出一份高分數的答卷，其生態環境做的已經很完善，運作模式可以當做其他開源專案的典範。最明顯的標誌是每個發行版本的程式碼貢獻量。程式碼的貢獻量是衡量某個企業實力的重要標準，代表開源社群的話語權，更代表著為自身爭取權益的能力。所以擁抱OpenStack的企業花費人力物力為社群程式碼做出貢獻。
另一方面OpenStack的出現大大加速了IT架構演進程序。社群對於OpenStack開發流程的把控是十分有效的，無論是程式碼質量保證，還是測試如單元測試和整合測試都是值得借鑑的。
Kubernetes：
Kubernetes社群起步晚於OpenStack，目前尚沒有OpenStack的火熱，但是Kubernetes在中國開發中的普及度還是很高的。Kubernetes中文社群為國內的愛好者提供了教程，中文文件，安裝教程等，大大減少了國內使用者的開發使用難度。
融合
雖然說OpenStack和Kubernetes是雲計算領域裡兩個領導者，那麼兩者一定是水火不容嗎？其實恰恰相反，兩者一直積極地相互融合當中。OpenStack中可以整合Docker，目前有三種方案：
1. Docker Driver for Nova
2. Docker Plugin for Heat
3. Magnum
OpenStack來部署Kubernetes是另一種融合的方式,很多公司已經實現將 Kubernetes部署到OpenStack中。反過來使用docker來部署OpenStack的服務也是一個很成功的部署方式。在需要頻繁部署OpenStack環境的場景下，docker可以做到分鐘級別的部署實施，大大減少了部署的困難度和耗時。
從長遠來看，兩者之間的融合趨勢不可避免。
總結
OpenStack是定位於laaS平臺的專案，Kubernetes是定位於PaaS平臺的專案，兩者在自己的領域中已經做的很好了。如果說OpenStack不如Kubernetes靈活，那麼同樣Kubernetes不如OpenStack沉穩。就像說武當功夫基礎肯定強不過少林，而少林拳腳沒有武當功夫將講究悟性。事實上根據業務需求，懂得靈活使用這兩種不同風格的系統才是制勝之道。
透過對兩種系統的出身，技術架構，使用場景和社群對比，希望能在選擇上給讀者一些有益的借鑑。
