Kubernetes 還是 DC/OS？實(shí)現(xiàn)云原生的路上，選型只是開(kāi)始！

作者 | 甜梨

根據(jù)CNCF發(fā)布2019年年度調(diào)查報(bào)告顯示,容器在實(shí)際生產(chǎn)環(huán)境中的使用率逐年增加,2016年和2018年的容器使用率分別是23%和73%,到了2019年,這一比例上升到了84%。除了使用率,容器的部署規(guī)模也在增加,在調(diào)查中,58%的受訪(fǎng)者表示其容器部署數(shù)量在250個(gè)以上。

當(dāng)容器數(shù)量達(dá)到一定規(guī)模時(shí),就需要容器編排平臺(tái)了。最開(kāi)始,業(yè)內(nèi)能夠稱(chēng)得上容器編排平臺(tái)的就只有Kubernetes,Swarm 只能算是一個(gè)管理平臺(tái),同時(shí)還需要Compose 和 Docker Machine等工具的配合,Mesos雖然作為資源調(diào)度平臺(tái)能夠管理容器,但還需要編排工具和組件服務(wù)的配合。

不過(guò),Kubernetes “獨(dú)步天下”的局面沒(méi)有持續(xù)很久,在容器編排平臺(tái)領(lǐng)域就出現(xiàn)了一個(gè)競(jìng)爭(zhēng)者——DC/OS。DC/OS 是 D2iQ公司(原名:Mesosphere)牽頭開(kāi)源的一個(gè)項(xiàng)目,其核心是基于 Mesos 實(shí)現(xiàn)的,可以集中基礎(chǔ)設(shè)施資源,并實(shí)現(xiàn)跨多個(gè)分布式應(yīng)用來(lái)共享資源。

選型指南:DC/OS 還是 Kubernetes ?

“尺有所短寸有所長(zhǎng)”,在企業(yè)實(shí)際生產(chǎn)環(huán)境中,Kubernetes和DC/OS應(yīng)該如何選型呢?一般來(lái)說(shuō),技術(shù)選型要分多種情況,下面我們就從集群規(guī)模、工作負(fù)載和復(fù)雜度三個(gè)方面來(lái)看看選型結(jié)果。

大集群選DC/OS,小集群選Kubernetes

我們把集群規(guī)?？梢苑譃閮蓚€(gè)部分來(lái)談?wù)?分別是集群數(shù)量和單個(gè)集群規(guī)模。

集群數(shù)量

這里的集群數(shù)量指的是集群中虛擬機(jī)或?qū)嶓w機(jī)的數(shù)量,包括開(kāi)發(fā)、測(cè)試、生產(chǎn)以及其它業(yè)務(wù)。一般我們是以500個(gè)集群為界限的,如果超過(guò)500,就可以認(rèn)為是大集群,應(yīng)該選擇DC/OS,如果少于500,那么就認(rèn)為是中小集群,更適合選擇Kubernetes。

單個(gè)集群規(guī)模

顧名思義,單個(gè)集群規(guī)模指的是在單個(gè)集群中的節(jié)點(diǎn)數(shù)量。一般來(lái)說(shuō),如果單集群節(jié)點(diǎn)為8-10個(gè),建議使用Kubernetes,而單集群節(jié)點(diǎn)超過(guò)100,則建議使用DC/OS。

多定制使用DC/OS,少定制使用Kubernetes

如果從工作負(fù)載的角度來(lái)看,DC/OS和Kubernetes應(yīng)該怎么選呢?業(yè)界比較普遍的選型方法是,如果是千節(jié)點(diǎn)集群且定制較少使用Kubernetes,而如果是萬(wàn)節(jié)點(diǎn)集群且定制較多,更適合使用DC/OS。

DC/OS的內(nèi)核是Mesos,Mesos的優(yōu)勢(shì)在于雙層調(diào)度機(jī)制,第一層調(diào)度先將整個(gè)Node分配給Framework,之后再進(jìn)行二次調(diào)度。如果有多個(gè)Framework,還可以進(jìn)行并行調(diào)度。

Kubernetes數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)層次比較細(xì),更符合微服務(wù)的設(shè)計(jì)思想。例如從容器->Pods->Deployment,每個(gè)運(yùn)行的容器都可能被封裝為這么多的層次,且每一層都可以拆分組合,并具備自己的作用。

至于在定制方面的適用場(chǎng)景,我們用一個(gè)例子來(lái)類(lèi)比,就像我們常見(jiàn)的搭積木,Mesos是零散的積木,需要自己組裝來(lái)實(shí)現(xiàn)業(yè)務(wù)模型,而Kubernetes就是組裝好的積木,直接拿來(lái)用就好了。

除此之外,應(yīng)用狀態(tài)也是一個(gè)需要考慮的因素。通常,應(yīng)用的狀態(tài)分為有狀態(tài)和無(wú)狀態(tài)兩部分,兩者的關(guān)鍵區(qū)別在于狀態(tài)信息是由請(qǐng)求方還是響應(yīng)方保存,如果是請(qǐng)求方保存就是無(wú)狀態(tài),反之亦然。

無(wú)狀態(tài)應(yīng)用無(wú)需關(guān)心響應(yīng)方是誰(shuí),也無(wú)需同步各個(gè)響應(yīng)方之間的信息,甚至被刪除也不會(huì)影響其它。而有狀態(tài)應(yīng)用需要及時(shí)同步數(shù)據(jù),不能丟失數(shù)據(jù),消耗內(nèi)存資源保存數(shù)據(jù)等,因此更需要謹(jǐn)慎對(duì)待。相比于Kubernetes,DC/OS捆綁了很多組件,且是分布式部署,因此能夠支持更多的有狀態(tài)服務(wù),即使是復(fù)雜的分布式系統(tǒng)也可以在幾分鐘內(nèi)部署完成。

復(fù)雜度:多租戶(hù)/多部門(mén)協(xié)作選DC/OS,反之選Kubernetes

按照慣例,我們先給出選型結(jié)論:如果企業(yè)內(nèi)部有多個(gè)業(yè)務(wù)部門(mén),多個(gè)開(kāi)發(fā)、測(cè)試、生產(chǎn)系統(tǒng),需要協(xié)作完成相關(guān)工作,復(fù)雜度較高,那么建議選擇DC/OS,反之,則建議選擇Kubernetes。那么問(wèn)題來(lái)了,在企業(yè)具體實(shí)踐中,復(fù)雜度都表現(xiàn)在什么地方呢?

存儲(chǔ)資源的復(fù)雜度,當(dāng)企業(yè)內(nèi)的數(shù)據(jù)中心或機(jī)房超過(guò)一個(gè)時(shí),那么就需要關(guān)心如何降低運(yùn)維的難度,如何按需對(duì)業(yè)務(wù)系統(tǒng)提供即時(shí)支持;

多需求的復(fù)雜度,當(dāng)企業(yè)存在多部門(mén)、多業(yè)務(wù),且需求不同的時(shí)候,那么就要關(guān)心如何滿(mǎn)足平臺(tái)提供方與資源提供方的定制化需求;

管理流程和人員的復(fù)雜性,如何做到集中和統(tǒng)一管理,減少差異化帶來(lái)的額外成本。

......

選型結(jié)束,才是開(kāi)始

選型結(jié)束,就萬(wàn)事大吉了嗎?不,現(xiàn)在才是開(kāi)始!即使選擇了合適的平臺(tái)或工具,在實(shí)際應(yīng)用中也難免會(huì)踩坑。

我們總結(jié)了企業(yè)在使用開(kāi)源解決方案時(shí),通常會(huì)遇到的坑:

版權(quán)升級(jí)常出故障;

運(yùn)維復(fù)雜性;

公有云托管存在弊端;

缺乏成熟度和互操作性;

無(wú)法為任務(wù)關(guān)鍵型應(yīng)用提供可靠支持;

......

如何“避坑”呢?最簡(jiǎn)單直接的方法就是采用企業(yè)級(jí)解決方案。相比于開(kāi)源解決方案,企業(yè)級(jí)方案更適合大多數(shù)企業(yè)使用,因?yàn)樗鼤?huì)針對(duì)企業(yè)場(chǎng)景進(jìn)行測(cè)試和驗(yàn)證,能夠提供質(zhì)量有保證的版本,同時(shí)也會(huì)支持和維護(hù)舊的版本。同時(shí),企業(yè)級(jí)解決方案背后的廠(chǎng)商還會(huì)提供相應(yīng)的服務(wù)級(jí)別協(xié)議(SLA),企業(yè)的關(guān)鍵任務(wù)型應(yīng)用系統(tǒng)可在某個(gè)時(shí)間段內(nèi)獲得支持。更重要的是,大部分企業(yè)級(jí)解決方案是預(yù)編譯的,即開(kāi)即用。

毫無(wú)疑問(wèn),Kubernetes和DC/OS開(kāi)源解決方案在使用時(shí)也會(huì)遇到某些問(wèn)題,想要擁有更好的使用體驗(yàn),那就要采用企業(yè)級(jí)解決方案。而D2iQ 恰好同時(shí)提供Kubernetes和DC/OS的企業(yè)級(jí)解決方案——Ksphere和DC/OS企業(yè)版。

D2iQ原名為Mesosphere,是一家2013年成立于美國(guó)的企業(yè)級(jí)云平臺(tái)提供商。2014年,D2iQ獲得了1050萬(wàn)美元的A輪融資之后,成立了德國(guó)分公司,2015年發(fā)布了眾所周知的DC/OS,2017年正式進(jìn)軍中國(guó),成立北京分公司——北京美索斯菲爾科技有限公司,2018年,完成D輪融資1.25億美元,2019 年,將公司名稱(chēng)從 Mesosphere 更為D2iQ,并在同年發(fā)布 KUDO 和 Konvoy。

D2iQ(Day-2-IQ)是什么意思呢?Day 2是一個(gè)幾年前就已經(jīng)被提出的 DevOps概念,指的是實(shí)現(xiàn)初始部署并投入生產(chǎn)環(huán)境后,應(yīng)用程序開(kāi)發(fā)生命周期的持續(xù)迭代,以及基礎(chǔ)設(shè)施和應(yīng)用的健康監(jiān)控和運(yùn)維階段。在這一階段,企業(yè)會(huì)面臨升級(jí)、安全和維護(hù)等等諸多問(wèn)題,IQ 則代表了更加先進(jìn)、智能化的解決思路和能力,例如為企業(yè)提供自動(dòng)化運(yùn)維服務(wù)、產(chǎn)品智能化等等。D2iQ表明這個(gè)公司不再只是支持Mesos或Kubernetes技術(shù),而是更聚焦于如何幫助企業(yè)使用開(kāi)源工具,簡(jiǎn)化復(fù)雜和耗時(shí)的工作。

Ksphere:針對(duì)Kubernetes的云原生解決方案

Ksphere= Kubernetes+Kommander(K8s聯(lián)邦式多集群管理)+全棧云原生生產(chǎn)運(yùn)維組件+KUDO云原生組件倉(cāng)庫(kù)

相比于單純安裝Kubernetes,運(yùn)行Kubernetes平臺(tái)和部署云原生應(yīng)用要復(fù)雜得多,僅僅是部署可用的Kubernetes集群,就需要許多核心組件作為補(bǔ)充。而Ksphere解決方案提供了必需的企業(yè)級(jí)能力,主要由五大部分組成:

Konvoy:是專(zhuān)為初次使用Kubernetes的企業(yè)設(shè)計(jì)的,可以在跨本地、云和邊緣環(huán)境中將容器和應(yīng)用程序自動(dòng)化;

Kommander:Kubernetes聯(lián)邦式多集群管理。主要針對(duì)同時(shí)采用Konvoy和其它Kubernetes服務(wù)造成的集群擴(kuò)張現(xiàn)象,提供多集群?jiǎn)我豢刂泼姘?具備集中化安全性和監(jiān)控功能,支持混合云/多云/邊緣云/本地部署的任意Kubernetes發(fā)行版;

KUDO:隨著Kubernetes應(yīng)用的增多,驅(qū)動(dòng)應(yīng)用程序的數(shù)據(jù)服務(wù)也在不斷擴(kuò)張。而KUDO可以簡(jiǎn)化Data Service Operator的構(gòu)建,更有效利用有狀態(tài)數(shù)據(jù)服務(wù);

Dispatch:Kubernetes原生的GitOps CI/CD平臺(tái),可用于快速構(gòu)建和部署云原生微服務(wù)應(yīng)用程序;

MKE引擎:基于DC/OS,提供單一的控制平面,可管理在同一操作系統(tǒng)上運(yùn)行的多個(gè)集群和高密度多Kubernetes。

值得注意的是,Ksphere的所有GA產(chǎn)品都通過(guò)大規(guī)?；旌瞎ぷ髫?fù)載測(cè)試,證實(shí)了關(guān)鍵服務(wù)互操作性,并且針對(duì)企業(yè)生產(chǎn)運(yùn)維階段的不同需求,也有不同的解決方案。

DC/OS 企業(yè)級(jí)解決方案

DC/OS=Mesos+Marathon+云原生組件

DC/OS是專(zhuān)為大規(guī)模生產(chǎn)部署設(shè)計(jì)的,可滿(mǎn)足企業(yè)大規(guī)模集群需求,并可在多云/混合云和邊緣計(jì)算基礎(chǔ)設(shè)施上運(yùn)行和管理容器和數(shù)據(jù)服務(wù)。目前最新的版本是DC/OS 2.0,支持云原生應(yīng)用程序、批處理作業(yè)、主流J2EE應(yīng)用程序、主流Windows應(yīng)用程序、D2iQ數(shù)據(jù)科學(xué)引擎(DSE)和分布式數(shù)據(jù)服務(wù)。

在企業(yè)實(shí)際生產(chǎn)環(huán)境中,DC/OS企業(yè)級(jí)解決方案可以提供多方面的便利條件:

部署靈活:一個(gè)接口可跨多個(gè)云、數(shù)據(jù)中心和邊緣計(jì)算環(huán)境;

工作量少:提供“即服務(wù)”的部署方式,可減少安裝、擴(kuò)展、修補(bǔ)和升級(jí)Kubernetes、Spark和Kafka等復(fù)雜服務(wù)的時(shí)間和工作量;

增強(qiáng)互操作性:提供多個(gè)服務(wù)互操作性測(cè)試和支持;

保證分布式工作負(fù)載安全:減少對(duì)安全威脅的暴露,簡(jiǎn)化策略執(zhí)行,保證合規(guī)性;

多租戶(hù):跨多個(gè)團(tuán)隊(duì)使用統(tǒng)一基礎(chǔ)設(shè)施,提高資源利用率,控制跨資源和工作負(fù)載的訪(fǎng)問(wèn)。

躬行踐履,DC/OS與Ksphere的實(shí)踐之路

“紙上得來(lái)終覺(jué)淺,絕知此事要躬行?！?/p>

選得好,還要用得好,如何才能用好Ksphere和DC/OS企業(yè)版呢?我們來(lái)看看中國(guó)聯(lián)通和游戲公司是怎么做的?

支撐數(shù)千節(jié)點(diǎn),8萬(wàn)在線(xiàn)實(shí)例,中國(guó)聯(lián)通的DC/OS實(shí)踐之路

電信核心業(yè)務(wù)運(yùn)營(yíng)支撐系統(tǒng)(cBSS)是中國(guó)聯(lián)通用于支持前臺(tái)銷(xiāo)售、客戶(hù)服務(wù)及內(nèi)部支撐全流程的業(yè)務(wù)管理系統(tǒng)。自2014年開(kāi)始,cBSS支持的用戶(hù)數(shù)量一直在快速增長(zhǎng),2019年已經(jīng)達(dá)到了2.5億多,用戶(hù)量激增促使系統(tǒng)不得不進(jìn)行升級(jí)改造。

2015年,中國(guó)聯(lián)通開(kāi)始針對(duì)cBSS系統(tǒng)開(kāi)始做去IOE、減負(fù)分流、x86化改造等相關(guān)工作,并取得了一些成果。改造之后,cBSS 系統(tǒng)中共有上千臺(tái)x86的多套子系統(tǒng)集群,這些集群彼此獨(dú)立,并采用了人工運(yùn)維的方式,因此在多個(gè)方面遇到了挑戰(zhàn),例如資源利用率低、人工部署運(yùn)維方式易出錯(cuò),各子系統(tǒng)環(huán)境不一致導(dǎo)致人員重復(fù)分配,存在大量重復(fù)工作等。

2016年,中國(guó)聯(lián)通開(kāi)始對(duì)cBSS做容器化改造,整體的技術(shù)選型是以Mesos、Marathon為核心實(shí)現(xiàn)容器資源的分布式調(diào)度與協(xié)調(diào),以Haproxy、Confd、Etcd為核心實(shí)現(xiàn)服務(wù)注冊(cè)和業(yè)務(wù)的引流,以DC/OS為基礎(chǔ)實(shí)現(xiàn)數(shù)據(jù)中心資源實(shí)時(shí)調(diào)度與管理。

據(jù)了解,cBSS系統(tǒng)總共完成了7大類(lèi)55種計(jì)費(fèi)應(yīng)用的容器化改造,容器進(jìn)程峰值達(dá)8.5萬(wàn),日均支撐100億條話(huà)單數(shù)據(jù)處理。

2017年,中國(guó)聯(lián)通將cBSS實(shí)踐在集團(tuán)內(nèi)部進(jìn)行了推廣,落地了多租戶(hù)容器化調(diào)度管理平臺(tái)——“天宮1.0”,該平臺(tái)是在DC/OS開(kāi)源版基礎(chǔ)上定制開(kāi)發(fā)的,其特性包括:實(shí)現(xiàn)跨地域、高效協(xié)作、即時(shí)申請(qǐng)、即時(shí)開(kāi)發(fā)、持續(xù)集成、灰度發(fā)布規(guī)范治理。

2018年,中國(guó)聯(lián)通發(fā)布了功能更為強(qiáng)大的升級(jí)版本——“天宮2.0”平臺(tái)。與天宮 1.0相比,該版本選擇了在DC/OS企業(yè)版上運(yùn)行Kubernetes,在現(xiàn)有平臺(tái)基礎(chǔ)上,增加了Kubernetes集群,實(shí)現(xiàn)了Kubernetes+DC/OS雙引擎架構(gòu)。

2019年,中國(guó)聯(lián)通推出了“天宮 3.0”平臺(tái),共支撐總部+21個(gè)分子公司+政企客戶(hù)的93個(gè)應(yīng)用,資源利用率提升60%,運(yùn)維效率提升50%。據(jù)了解,天宮 3.0的工作負(fù)載統(tǒng)一調(diào)度由Mesos兩層調(diào)度機(jī)制實(shí)現(xiàn),平臺(tái)架構(gòu)以包括D2iQ的Mesos、Marathon、DC/OS等開(kāi)源軟件為基礎(chǔ)進(jìn)行升級(jí)改造,支持Intel和ARM CPU雙核體系架構(gòu),可獨(dú)立或混合部署不同架構(gòu)服務(wù)器;采用混動(dòng)雙擎——Kubernetes和DC/OS架構(gòu),實(shí)現(xiàn)應(yīng)用無(wú)縫遷移,組件拿來(lái)即用。

目前,天宮平臺(tái)在北京和西咸兩地設(shè)有數(shù)據(jù)中心,共有數(shù)千節(jié)點(diǎn),不僅支撐了覆蓋全國(guó)32個(gè)省業(yè)務(wù)的cBSS系統(tǒng),而且也支撐了營(yíng)業(yè)、AI新客服、店獎(jiǎng)等新上線(xiàn)的業(yè)務(wù)系統(tǒng),在線(xiàn)運(yùn)行應(yīng)用實(shí)例數(shù)達(dá)到了8萬(wàn)。

1億會(huì)員、500+個(gè)微服務(wù)子系統(tǒng),游戲公司的Ksphere實(shí)踐之路

為了適應(yīng)市場(chǎng)需求變化和技術(shù)革新,某游戲娛樂(lè)公司決定通過(guò)技術(shù)來(lái)實(shí)現(xiàn)全國(guó)集團(tuán)中心的整體統(tǒng)一,并為將來(lái)業(yè)務(wù)系統(tǒng)預(yù)留擴(kuò)展能力。

該游戲公司的Ksphere實(shí)踐總共分為兩個(gè)階段:

第一階段:500+個(gè)微服務(wù)子系統(tǒng)的CI/CD能力建設(shè)

游戲公司在第一階段的系統(tǒng)建設(shè),涉及了超過(guò)500個(gè)微服務(wù)子系統(tǒng)的構(gòu)建與集成,其中支持的渠道終端設(shè)備超過(guò)了30萬(wàn)個(gè),會(huì)員賬戶(hù)超過(guò)1億,授權(quán)管理用戶(hù)2.3萬(wàn)(管理人員3千人,工作人員2萬(wàn)人)。并且,系統(tǒng)數(shù)據(jù)保存要求在線(xiàn)實(shí)時(shí)可查的全量數(shù)據(jù)保存6個(gè)月,歷史數(shù)據(jù)由存儲(chǔ)設(shè)備保存5年,而關(guān)鍵數(shù)據(jù)永久保存。

由于支持的微服務(wù)子系統(tǒng)數(shù)量較多,CI/CD能力就成為了系統(tǒng)的瓶頸。因此,該公司想要重新建設(shè)一套CI/CD方案,并希望這套方案能夠滿(mǎn)足以下需求:

方案必須完全基于CNCF開(kāi)源社區(qū),避免廠(chǎng)商技術(shù)鎖定;

方案需要保證 Kubernetes 云原生,能夠充分利用Kubernetes的資源管理與調(diào)度能力,提高集群的資源利用率;

支持多租戶(hù)場(chǎng)景,在微服架構(gòu)下,能夠滿(mǎn)足各產(chǎn)品團(tuán)隊(duì)對(duì)于持續(xù)集成/持續(xù)發(fā)布的自服務(wù)能力;

支持單點(diǎn)登錄集成(SSO)與基于RBAC的用戶(hù)身份認(rèn)證與授權(quán)。

基于這些選型需求,游戲公司選擇了D2iQ提供的Dispatch解決方案,在原有的CI流程基礎(chǔ)上,優(yōu)化了在Kubernetes云原生環(huán)境下的CI流程與CD流程。據(jù)了解,優(yōu)化之后,原本2個(gè)月一次的產(chǎn)品生產(chǎn)環(huán)境發(fā)布,已經(jīng)縮短到了2周,且測(cè)試環(huán)境已經(jīng)實(shí)現(xiàn)了每天一次定時(shí)發(fā)布。

優(yōu)化之后的CI和CD流程

第二階段:數(shù)據(jù)統(tǒng)一管控平臺(tái)建設(shè)

第一階段完成之后,該游戲公司有了進(jìn)一步優(yōu)化的目標(biāo),想要實(shí)現(xiàn)各個(gè)業(yè)務(wù)線(xiàn)之間的充分信息共享,因此,決定開(kāi)發(fā)數(shù)據(jù)統(tǒng)一管控平臺(tái)。該平臺(tái)的主要目標(biāo)是實(shí)現(xiàn)信息資源的整合,提高技術(shù)響應(yīng)的速度,實(shí)現(xiàn)信息共享,實(shí)現(xiàn)大數(shù)據(jù)分析和提升數(shù)據(jù)質(zhì)量。

該游戲公司整個(gè)應(yīng)用系統(tǒng)的數(shù)據(jù)可以根據(jù)需求分為三大類(lèi):

大數(shù)據(jù)聚合類(lèi):負(fù)責(zé)業(yè)務(wù)交易日志,性能數(shù)據(jù)聚合等;

實(shí)時(shí)交易類(lèi)數(shù)據(jù):需提供較高的讀寫(xiě)性能,與數(shù)據(jù)一致性要求;

業(yè)務(wù)管理類(lèi)數(shù)據(jù):主要負(fù)責(zé)存儲(chǔ)賬戶(hù),權(quán)限,配制等信息。

針對(duì)這三類(lèi)數(shù)據(jù),D2iQ的KUDO有狀態(tài)數(shù)據(jù)服務(wù)框架及其開(kāi)源數(shù)據(jù)服務(wù)提供了相應(yīng)的支撐:

針對(duì)大數(shù)據(jù)聚合類(lèi)數(shù)據(jù),KUDO提供了不同的數(shù)據(jù)處理方案,例如對(duì)于隔夜Batch數(shù)據(jù),KUDO項(xiàng)目提供Cassandra、Spark滿(mǎn)足客戶(hù)業(yè)務(wù)交易日志的分析、聚合與存儲(chǔ);對(duì)于實(shí)時(shí)的性能數(shù)據(jù)流,KUDO項(xiàng)目提供Kafka、Kafka Connect、Spark Streaming來(lái)支撐客戶(hù)性能數(shù)據(jù)的聚合處理;

針對(duì)實(shí)時(shí)交易類(lèi)數(shù)據(jù),基于KUDO框架的MySQL容器化高可用解決方案提供了容器化的數(shù)據(jù)選型思路;

針對(duì)業(yè)務(wù)管理類(lèi)數(shù)據(jù),KUDO提供了高可用的HDFS集群,滿(mǎn)足客戶(hù)的分布式存儲(chǔ)需求。

獨(dú)木難成林,生態(tài)建設(shè)必不可少

根據(jù)451 Research的預(yù)測(cè),截至2022年,應(yīng)用容器技術(shù)的市場(chǎng)規(guī)模預(yù)計(jì)將達(dá)到43億美元,是2019年的兩倍。這一數(shù)據(jù)不僅表示容器市場(chǎng)的前景廣闊,同時(shí)也說(shuō)明了這一領(lǐng)域還有很多空白。想要推動(dòng)容器技術(shù)的向前發(fā)展,單靠一家公司是不可行的,必須依靠集體和生態(tài)的力量。

獨(dú)木難成林,生態(tài)建設(shè)還需要每個(gè)公司和個(gè)體的努力。以D2iQ為例,它是Core Kubernetes早期的三大貢獻(xiàn)者之一,目前在Kubernetes項(xiàng)目的代碼提交行數(shù)在全球企業(yè)中排名前十。在社區(qū)中,不僅創(chuàng)建了容器存儲(chǔ)接口標(biāo)準(zhǔn)(CSI),同時(shí)還支持多個(gè)開(kāi)源項(xiàng)目,例如Helm項(xiàng)目、Kubernetes、Kubebuilder、SIG API Machinery、Controller Runtime和Cluster API。

同時(shí),D2iQ自身的解決方案也會(huì)與整個(gè)生態(tài)系統(tǒng)中的其它技術(shù)做整合,用戶(hù)可以自由選擇關(guān)鍵的技術(shù)和組件。

據(jù)了解,目前已經(jīng)整合的技術(shù)和組件包括存儲(chǔ)平臺(tái)Portworx、Hedvig、OpenEBS和Pure Service Orchestrator,網(wǎng)絡(luò)平臺(tái)Argo Tunnel、Calico、Traefik,安全平臺(tái)NG-WAF、Aqua、Open Policy Agent,數(shù)據(jù)庫(kù)Couchbase、MongoDB、Cassandra、InfluxDB、ArangoDB,應(yīng)用類(lèi)Lightbend和Gitlab,數(shù)據(jù)流/消息Kafka和Flink。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。