日韩黑丝制服一区视频播放|日韩欧美人妻丝袜视频在线观看|九九影院一级蜜桃|亚洲中文在线导航|青草草视频在线观看|婷婷五月色伊人网站|日本一区二区在线|国产AV一二三四区毛片|正在播放久草视频|亚洲色图精品一区

分享

OpenStack VS Kubernetes,誰是你心中的王者?

 2016xing 2019-05-15

當(dāng)下云計(jì)算的領(lǐng)域里熱度最高的兩個(gè)項(xiàng)目,無疑是OpenStack和Kubernetes。如果云計(jì)算是一個(gè)風(fēng)起云涌的江湖,毫不夸張的說OpenStack和Kubernetes就是江湖里的泰山北斗。

OpenStack就像是少林,基礎(chǔ)扎實(shí)、沉穩(wěn)厚重,而Kubernetes就是武當(dāng),輕巧空靈、飄逸精妙。使用過這兩種系統(tǒng)的人都應(yīng)該有這樣的感受,OpenStack出身于虛擬化技術(shù),穩(wěn)定但速度慢,Kubernetes則來自于容器技術(shù),快速但有局限。兩種不同的技術(shù)就決定了有著不同的人生軌跡。那么究竟兩者有著怎樣的際遇呢?我們分析分析。

一、出身對比

OpenStack:

2010年7月,RackSpace公司和美國國家航空航天局NASA合作,分別貢獻(xiàn)出了RackSpack云文件平臺代碼和NASA平臺代碼,發(fā)布OpenStack的第一個(gè)版本Austin。2010的Rackspace是美國第二大云計(jì)算廠商,但規(guī)模只能占到亞馬遜的5%。只依靠內(nèi)部的力量來超越或者追趕亞馬遜不大可能,這家公司就把自己的項(xiàng)目開源了,也就是后來的 OpenStack 的存儲源碼(swift)。與此同時(shí)NASA也對自己使用的 Eucalyptus 云計(jì)算管理平臺很不爽。NASA想給Eucalyptus開源版本貢獻(xiàn),結(jié)果Eucalyptus不接受。當(dāng)時(shí)NASA 的六個(gè)開發(fā)人員,用了一個(gè)星期時(shí)間拿Python做出來一套原型,結(jié)果虛擬機(jī)在這上面運(yùn)行的很成功,這就是Nova(計(jì)算源碼)的起源。Austin只有swift和Nova這兩個(gè)項(xiàng)目,即目前的對象存儲和計(jì)算服務(wù)。此后OpenStack大概保持著每半年發(fā)布一次版本的頻率,截止到目前最新的版本是Rocky。在最新的版本中項(xiàng)目已經(jīng)達(dá)到60多個(gè)。

Kubernetes:

Kubernetes是Google在2014年發(fā)布的一個(gè)開源項(xiàng)目。Google開發(fā)了一個(gè)叫Brog的系統(tǒng)來調(diào)度內(nèi)部數(shù)量龐大的容器和工作負(fù)載。在積累了多年經(jīng)驗(yàn)之后,Google決定重寫這個(gè)容器管理,并將其貢獻(xiàn)到開源社區(qū),讓全世界都能夠受益。在2014年第一個(gè)版本發(fā)布以來,Kubernetes迅速受到開源社區(qū)的的追捧,目前Kubernetes已經(jīng)成為發(fā)展最快,市場占有率最高的容器編排引擎。截止到現(xiàn)在,Kubernetes的最新版本是1.11版本。

Kubernetes版本發(fā)布表:

二、技術(shù)實(shí)現(xiàn)

OpenStack:虛擬化

OpenStack作為一個(gè)開源的云計(jì)算平臺,利用虛擬化技術(shù)和底層存儲服務(wù),提供了可擴(kuò)展,靈活,適應(yīng)性強(qiáng)的云計(jì)算服務(wù)。虛擬化是云計(jì)算的基礎(chǔ)。簡單的說,虛擬化使得在一臺物理的服務(wù)器上可以跑多臺虛擬機(jī),虛擬機(jī)共享物理機(jī)的CPU、內(nèi)存、IO硬件資源,但邏輯上虛擬機(jī)之間是相互隔離的。宿主機(jī)一般使用hypervisor程序?qū)崿F(xiàn)硬件資源虛擬化,并提供給客戶機(jī)使用。如下圖所示是一種虛擬化的架構(gòu)。

每一個(gè)虛擬機(jī)都擁有自己的內(nèi)核和文件系統(tǒng),完全是一個(gè)獨(dú)立的操作系統(tǒng)。而上圖是兩種虛擬化方式中的其中一種:半虛擬化——KVM。在目前的環(huán)境中,KVM虛擬化技術(shù)是使用率最高的技術(shù)。

虛擬化優(yōu)點(diǎn):隔離性強(qiáng),所有的虛擬機(jī)都有自己的協(xié)議棧,各個(gè)虛擬機(jī)底層相互隔離。

虛擬化缺點(diǎn):資源占用多,虛擬化技術(shù)本身占用資源,宿主機(jī)性能有10%左右的消耗。

Kubernetes:docker

Kubernetes是容器管理編排引擎,那么底層實(shí)現(xiàn)自然是容器技術(shù)。容器是一種輕量級、可移植、自包含的軟件打包技術(shù),打包的應(yīng)用程序可以在幾乎任何地方以相同的方式運(yùn)行。以容器典型代表docker為例,docker起源于2013年3月,是基于LXC為基礎(chǔ)構(gòu)建的容器引擎,通過namespace和cgourp實(shí)現(xiàn)了資源隔離和調(diào)配,使用分層存儲來構(gòu)建鏡像。它基于Google公司推出的Go語言實(shí)現(xiàn)。docker相比KVM虛擬化技術(shù)最明顯的特點(diǎn)就是啟動快,資源占用小。虛擬化啟動虛擬機(jī)是分鐘級別的,而docker是秒級別的。如下是docker的架構(gòu)圖。

docker的啟動速度快,占用資源少,原因在于技術(shù)架構(gòu):

一個(gè)操作系統(tǒng)分為內(nèi)核+文件系統(tǒng)。容器技術(shù)就是使用宿主機(jī)的內(nèi)核系統(tǒng)加上自身的文件系統(tǒng)。運(yùn)行容器時(shí)是在使用宿主機(jī)的內(nèi)核情況下加載文件系統(tǒng),精簡的文件系統(tǒng)可以小到100MB以內(nèi),所以比虛擬機(jī)自然要快很多??梢詫⑷萜骺醋魇窃趦?nèi)核上運(yùn)行的獨(dú)立代碼單元,它們非常輕。因此占用的資源也少。

容器優(yōu)點(diǎn):啟動快,資源占用小,移植性好

容器缺點(diǎn):隔離性不好,共用宿主機(jī)的內(nèi)核,底層能夠訪問。依賴宿主機(jī)內(nèi)核所以容器的系統(tǒng)選擇有限制。

三、架構(gòu)對比

OpenStack:

OpenStack的服務(wù)分為核心功能和非核心功能。核心功能是指運(yùn)行OpenStack系統(tǒng)必須的功能,其中核心功能有:

其工作模式如下:

在“為什么選擇OpenStack”的用戶調(diào)查中得出一個(gè)比例很高的結(jié)果是:開放平臺和標(biāo)準(zhǔn)化的API。OpenStack貫徹松耦解耦的思想,各個(gè)服務(wù)之間使用標(biāo)準(zhǔn)的API接口調(diào)用,并且這些接口是能夠開發(fā)給非OpenStack程序去調(diào)用。

具體到OpenStack就是Resutful(表述性狀態(tài)轉(zhuǎn)移)和RPC(遠(yuǎn)程過程調(diào)用)。服務(wù)與服務(wù)之間使用Restful API通信,最大程度的減少了服務(wù)之間的依賴。例如創(chuàng)建虛擬機(jī)時(shí),nova服務(wù)要調(diào)用glance服務(wù),要調(diào)用neutron服務(wù),這些都是通過Restful api 來完成的。服務(wù)內(nèi)部的模塊之間的調(diào)用使用了RPC,增加了橫向擴(kuò)展能力。例如nova-api接收到創(chuàng)建虛擬機(jī)的請求,要先后調(diào)用nova-scheduler 選定創(chuàng)建虛擬機(jī)的主機(jī),nova-compte完成虛擬機(jī)創(chuàng)建的具體工作。此外,opnestack用到的通用技術(shù)還有:

1. 消息總線 AMQP

2. ORM模型數(shù)據(jù)庫 SQLalchemy

3. WSGI Web服務(wù)器網(wǎng)管接口

4. Eventlet 協(xié)程

OpenStack采用開源技術(shù),避免重復(fù)制造輪子,這對團(tuán)隊(duì)的技術(shù)選擇有著借鑒意義。

Kubernetes:

Kubernetes的思想是盡量保證用戶的理想狀態(tài)。通俗來說就是用戶創(chuàng)建了3個(gè)容器,Kubernetes要保證這三個(gè)容器的生命,時(shí)時(shí)刻刻都是健康的三個(gè)容器,受到斷電等故障的情況能夠及時(shí)補(bǔ)上。Kubernetes是由Master和Node組成,Master是大腦,Node是計(jì)算節(jié)點(diǎn)。

如下圖的構(gòu)成:

在Master節(jié)點(diǎn)上運(yùn)行的服務(wù)有:

1. API Server:提供Restful api。各種客戶端工具或者其他組件可以調(diào)用其完成資源調(diào)用。

2. Scheduler:調(diào)度服務(wù),決定將容器創(chuàng)建在哪個(gè)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é)點(diǎn)的服務(wù):

1. kubelet :接收Master節(jié)點(diǎn)發(fā)來的創(chuàng)建請求信息,并向Master報(bào)告運(yùn)行狀態(tài)。

2. kube-proxy :訪問控制。

同樣以創(chuàng)建一個(gè)服務(wù)的方式來解析整個(gè)系統(tǒng)的運(yùn)作流程。Kubernetes 客戶端發(fā)送創(chuàng)建請求到系統(tǒng),API server接收到請求,并通知controller創(chuàng)建一個(gè)deployment資源,controller負(fù)責(zé)具體的創(chuàng)建過程,調(diào)用Scheduler選擇哪個(gè)主機(jī)創(chuàng)建,然后將請求發(fā)往Node節(jié)點(diǎn),Node節(jié)點(diǎn)上的kubelet接收到請求,創(chuàng)建具體的docker。

Kubernetes同樣遵循標(biāo)準(zhǔn)化API接口。

Kubernetes API是集群系統(tǒng)中的重要組成部分,Kubernetes中各種資源(對象)的數(shù)據(jù)通過該API接口被提交到后端的持久化存儲(etcd)中,Kubernetes集群中的各部件之間通過該API接口實(shí)現(xiàn)解耦合,同時(shí)集群中一個(gè)重要且便捷的管理工具kubectl也是通過訪問該API接口實(shí)現(xiàn)其強(qiáng)大的管理功能的。系統(tǒng)中大多數(shù)情況下,API定義和實(shí)現(xiàn)都符合標(biāo)準(zhǔn)的HTTP REST格式,比如通過標(biāo)準(zhǔn)的HTTP動詞(POST、PUT、GET、DELETE)來完成對相關(guān)資源對象的查詢、創(chuàng)建、修改、刪除等操作。但同時(shí)Kubernetes 也為某些非標(biāo)準(zhǔn)的REST行為實(shí)現(xiàn)了附加的API接口,例如Watch某個(gè)資源的變化、進(jìn)入容器執(zhí)行某個(gè)操作等。

四、使用場景

OpenStack:

場景一:安全和隔離。OpenStack適用于搭建私有云以及基于私有云的使用的場景。OpenStack底層使用了虛擬化技術(shù),其基因中就有著隔離性好,穩(wěn)定,部署靈活等特點(diǎn)。在OpenStack的成功案例中,云桌面是典型的例子。有不少的企業(yè)都已經(jīng)將自己的生產(chǎn)環(huán)境搬到云端,例如企業(yè)上云,工作環(huán)境就是使用云桌面的形式。第一是降低了設(shè)備成本,上云之前是每人一臺主機(jī),到現(xiàn)在幾十個(gè)人使用一臺服務(wù)器,如果考慮cpu,內(nèi)存使用率,成本肯定降下來了。第二是安全,所有的數(shù)據(jù)都不是存儲在身邊,在一些安全系數(shù)高的行業(yè)中尤為重要。OpenStack一直受到金融行業(yè)的青睞,這里少不了看中OpenStack安全的特性。

場景二:提供基礎(chǔ)設(shè)施。OpenStack是定位于laas平臺的項(xiàng)目,其優(yōu)點(diǎn)是能夠提供虛擬機(jī)這種很底層的設(shè)施。如果在業(yè)務(wù)場景中很依賴虛擬機(jī),例如編譯內(nèi)核,或者驅(qū)動開發(fā)等這些場景,那么OpenStack是很好的選擇。

場景三:存儲需求。存儲是OpenStack另一個(gè)優(yōu)勢所在。OpenStack第一個(gè)版本的項(xiàng)目組成就是存儲和計(jì)算,在后期不斷的開發(fā)中,存儲作為一個(gè)重要的功能一直不斷的完善和創(chuàng)新。如cinder塊存儲,ceph共享存儲能。在存儲需求很大的場景下,OpenStack能夠提供高效,安全的存儲方案,這也是為什么電信行業(yè)看好OpenStack的一個(gè)原因。

場景四:動態(tài)數(shù)據(jù)場景。即不需要反復(fù)地創(chuàng)建和銷毀這些服務(wù)的運(yùn)行環(huán)境。虛擬機(jī)優(yōu)勢在于穩(wěn)定,那么OpenStack優(yōu)勢也在于運(yùn)行穩(wěn)定的項(xiàng)目。

Kubernetes:

場景一:Kubernetes適用于業(yè)務(wù)變化快,業(yè)務(wù)量未知的靜態(tài)使用場景。所謂靜態(tài)使用場景是指在其創(chuàng)建的容器中不會實(shí)時(shí)產(chǎn)生數(shù)據(jù)的場景。例如:網(wǎng)站架構(gòu),一次部署,長時(shí)間使用。特別是遇到一些線上業(yè)務(wù)量不確定的場景,Kubernetes能夠動態(tài)擴(kuò)展,靈活伸縮,從5W的并發(fā)量到10W的并發(fā)量,完全可以秒級處理。

場景二:需要反復(fù)地創(chuàng)建和銷毀這些服務(wù)的運(yùn)行環(huán)境。docker的優(yōu)勢就在于啟動快速,消耗資源小。所以在需要頻繁創(chuàng)建和銷毀的場景中,Kubernetes是一個(gè)不錯(cuò)的選擇。

場景三:需要業(yè)務(wù)模塊化和可伸縮性:容器可以很容易地將應(yīng)用程序的功能分解為單個(gè)組件,符合微服務(wù)架構(gòu)的設(shè)計(jì)模式。

場景四:應(yīng)用云化。將已有應(yīng)用、要新開發(fā)的應(yīng)用打造成云原生應(yīng)用,發(fā)揮云平臺的可擴(kuò)展、彈性、高可用等特性,并借助PaaS層提供的API實(shí)現(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ù)和進(jìn)行API權(quán)限控制,則成了需要解決的問題,而Kubernetes代表的PaaS則是理想的選擇。

五、社區(qū)對比

對于開源項(xiàng)目來說,社區(qū)火熱程度代表著生命力和潛力。如何判斷一個(gè)項(xiàng)目的未來發(fā)展,關(guān)注社區(qū)肯定是最基本的要求。

OpenStack:

OpenStack是開源項(xiàng)目的代表作之一。

OpenStack從第一個(gè)版本開始到現(xiàn)在的R版本的開發(fā)過程,為探索開源生態(tài)交出一份高分?jǐn)?shù)的答卷,其生態(tài)環(huán)境做的已經(jīng)很完善,運(yùn)作模式可以當(dāng)做其他開源項(xiàng)目的典范。最明顯的標(biāo)志是每個(gè)發(fā)行版本的代碼貢獻(xiàn)量。代碼的貢獻(xiàn)量是衡量某個(gè)企業(yè)實(shí)力的重要標(biāo)準(zhǔn),代表開源社區(qū)的話語權(quán),更代表著為自身爭取權(quán)益的能力。所以擁抱OpenStack的企業(yè)花費(fèi)人力物力為社區(qū)代碼做出貢獻(xiàn)。

另一方面OpenStack的出現(xiàn)大大加速了IT架構(gòu)演進(jìn)進(jìn)程。社區(qū)對于OpenStack開發(fā)流程的把控是十分有效的,無論是代碼質(zhì)量保證,還是測試如單元測試和集成測試都是值得借鑒的。

Kubernetes:

Kubernetes社區(qū)起步晚于OpenStack,目前尚沒有OpenStack的火熱,但是Kubernetes在中國開發(fā)中的普及度還是很高的。Kubernetes中文社區(qū)為國內(nèi)的愛好者提供了教程,中文文檔,安裝教程等,大大減少了國內(nèi)用戶的開發(fā)使用難度。

六、融合

雖然說OpenStack和Kubernetes是云計(jì)算領(lǐng)域里兩個(gè)領(lǐng)導(dǎo)者,那么兩者一定是水火不容嗎?其實(shí)恰恰相反,兩者一直積極的相互融合當(dāng)中。OpenStack中可以集成Docker,目前有三種方案:

1. Docker Driver for Nova

2. Docker Plugin for Heat

3. Magnum

OpenStack來部署Kubernetes是另一種融合的方式,很多公司已經(jīng)實(shí)現(xiàn)將 Kubernetes部署到OpenStack中。反過來使用docker來部署OpenStack的服務(wù)也是一個(gè)很成功的部署方式。在需要頻繁部署OpenStack環(huán)境的場景下,docker可以做到分鐘級別的部署實(shí)施,大大減少了部署的困難度和耗時(shí)。

從長遠(yuǎn)來看,兩者之間的融合趨勢不可避免。

七、總結(jié)

OpenStack是定位于laaS平臺的項(xiàng)目,Kubernetes是定位于PaaS平臺的項(xiàng)目,兩者在自己的領(lǐng)域中已經(jīng)做的很好了。如果說OpenStack不如Kubernetes靈活,那么同樣Kubernetes不如OpenStack沉穩(wěn)。就像說武當(dāng)功夫基礎(chǔ)肯定強(qiáng)不過少林,而少林拳腳沒有武當(dāng)功夫?qū)⒅v究悟性。事實(shí)上根據(jù)業(yè)務(wù)需求,懂得靈活使用這兩種不同風(fēng)格的系統(tǒng)才是制勝之道。

通過對兩種系統(tǒng)的出身,技術(shù)架構(gòu),使用場景和社區(qū)對比,希望能在選擇上給讀者一些有益的借鑒。

    本站是提供個(gè)人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點(diǎn)。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點(diǎn)擊一鍵舉報(bào)。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多