OpenStack VS Kubernetes，誰是你心中的王者？

做者簡介：李金葵，郵箱：892697603@qq.com

當下雲計算的領域裏熱度最高的兩個項目，無疑是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沉穩。就像說武當功夫基礎確定強不過少林，而少林拳腳沒有武當功夫將講究悟性。事實上根據業務需求，懂得靈活使用這兩種不一樣風格的系統纔是制勝之道。

經過對兩種系統的出身，技術架構，使用場景和社區對比，但願能在選擇上給讀者一些有益的借鑑。