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