當下雲計算的領域里熱度最高的兩個項目，無疑是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沉穩。就像說武當功夫基礎肯定強不過少林，而少林拳腳沒有武當功夫將講究悟性。事實上根據業務需求，懂得靈活使用這兩種不同風格的系統才是制勝之道。
通過對兩種系統的出身，技術架構，使用場景和社區對比，希望能在選擇上給讀者一些有益的借鑒。