作者 | 甜梨

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

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

不過,Kubernetes “獨步天下”的局面沒有持續(xù)很久,在容器編排平臺領域就出現(xiàn)了一個競爭者——DC/OS。DC/OS 是 D2iQ公司(原名:Mesosphere)牽頭開源的一個項目,其核心是基于 Mesos 實現(xiàn)的,可以集中基礎設施資源,并實現(xiàn)跨多個分布式應用來共享資源。

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

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

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

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

集群數(shù)量

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

單個集群規(guī)模

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

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

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

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

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

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

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

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

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

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

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

多需求的復雜度,當企業(yè)存在多部門、多業(yè)務,且需求不同的時候,那么就要關心如何滿足平臺提供方與資源提供方的定制化需求;

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

......

選型結束,才是開始

選型結束,就萬事大吉了嗎?不,現(xiàn)在才是開始!即使選擇了合適的平臺或工具,在實際應用中也難免會踩坑。

我們總結了企業(yè)在使用開源解決方案時,通常會遇到的坑:

版權升級常出故障;

運維復雜性;

公有云托管存在弊端;

缺乏成熟度和互操作性;

無法為任務關鍵型應用提供可靠支持;

......

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

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

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

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

Ksphere:針對Kubernetes的云原生解決方案

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

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

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

Kommander:Kubernetes聯(lián)邦式多集群管理。主要針對同時采用Konvoy和其它Kubernetes服務造成的集群擴張現(xiàn)象,提供多集群單一控制面板,具備集中化安全性和監(jiān)控功能,支持混合云/多云/邊緣云/本地部署的任意Kubernetes發(fā)行版;

KUDO:隨著Kubernetes應用的增多,驅動應用程序的數(shù)據(jù)服務也在不斷擴張。而KUDO可以簡化Data Service Operator的構建,更有效利用有狀態(tài)數(shù)據(jù)服務;

Dispatch:Kubernetes原生的GitOps CI/CD平臺,可用于快速構建和部署云原生微服務應用程序;

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

值得注意的是,Ksphere的所有GA產(chǎn)品都通過大規(guī)模混合工作負載測試,證實了關鍵服務互操作性,并且針對企業(yè)生產(chǎn)運維階段的不同需求,也有不同的解決方案。

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

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

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

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

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

工作量少:提供“即服務”的部署方式,可減少安裝、擴展、修補和升級Kubernetes、Spark和Kafka等復雜服務的時間和工作量;

增強互操作性:提供多個服務互操作性測試和支持;

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

多租戶:跨多個團隊使用統(tǒng)一基礎設施,提高資源利用率,控制跨資源和工作負載的訪問。

躬行踐履,DC/OS與Ksphere的實踐之路

“紙上得來終覺淺,絕知此事要躬行?！?/p>

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

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

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

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

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

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

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

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

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

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

1億會員、500+個微服務子系統(tǒng),游戲公司的Ksphere實踐之路

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

該游戲公司的Ksphere實踐總共分為兩個階段:

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

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

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

方案必須完全基于CNCF開源社區(qū),避免廠商技術鎖定;

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

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

支持單點登錄集成(SSO)與基于RBAC的用戶身份認證與授權。

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

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

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

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

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

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

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

業(yè)務管理類數(shù)據(jù):主要負責存儲賬戶,權限,配制等信息。

針對這三類數(shù)據(jù),D2iQ的KUDO有狀態(tài)數(shù)據(jù)服務框架及其開源數(shù)據(jù)服務提供了相應的支撐:

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

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

針對業(yè)務管理類數(shù)據(jù),KUDO提供了高可用的HDFS集群,滿足客戶的分布式存儲需求。

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

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

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

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

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

生成海報

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