Categories
程式開發

Kubernetes 還是 DC/OS?實現雲原生的路上,選型只是開始!


根據CNCF發布2019年年度調查報告顯示,容器在實際生產環境中的使用率逐年增加,2016年和2018年的容器使用率分別是23%和73%,到了2019年,這一比例上升到了84% 。除了使用率,容器的部署規模也在增加,在調查中,58%的受訪者表示其容器部署數量在250個以上。
Kubernetes 還是 DC/OS?實現雲原生的路上,選型只是開始! 1

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

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

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

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

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

我們把集群規模可以分為兩個部分來談論,分別是集群數量和單個集群規模。

  • 集群數量

這裡的集群數量指的是集群中虛擬機或實體機的數量,包括開發、測試、生產以及其它業務。一般我們是以500個集群為界限的,如果超過500,就可以認為是大集群,應該選擇DC/OS,如果少於500,那麼就認為是中小集群,更適合選擇Kubernetes。

  • 單個集群規模

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

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

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

DC/OS的內核是Mesos,Mesos的優勢在於雙層調度機制,第一層調度先將整個Node分配給Framework,之後再進行二次調度。如果有多個Framework,還可以進行並行調度。

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

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

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

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

複雜度:多租戶/多部門協作選DC/OS,反之選Kubernetes

按照慣例,我們先給出選型結論:如果企業內部有多個業務部門,多個開發、測試、生產系統,需要協作完成相關工作,複雜度較高,那麼建議選擇DC/OS,反之,則建議選擇Kubernetes。那麼問題來了,在企業具體實踐中,複雜度都表現在什麼地方呢?

  • 存儲資源的複雜度,當企業內的數據中心或機房超過一個時,那麼就需要關心如何降低運維的難度,如何按需對業務系統提供即時支持;

  • 多需求的複雜度,當企業存在多部門、多業務,且需求不同的時候,那麼就要關心如何滿足平台提供方與資源提供方的定制化需求;

  • 管理流程和人員的複雜性,如何做到集中和統一管理,減少差異化帶來的額外成本。

選型結束,才是開始

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

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

  • 版權升級常出故障;

  • 運維複雜性;

  • 公有云託管存在弊端;

  • 缺乏成熟度和互操作性;

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

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

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

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

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

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

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

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

  • Konvoy:是專為初次使用Kubernetes的企業設計的,可以在跨本地、雲和邊緣環境中將容器和應用程序自動化;

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

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

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

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

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

DC/OS 企業級解決方案

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

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

在企業實際生產環境中,DC/OS企業級解決方案可以提供多方面的便利條件:

  • 部署靈活:一個接口可跨多個雲、數據中心和邊緣計算環境;

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

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

  • 保證分佈式工作負載安全:減少對安全威脅的暴露,簡化策略執行,保證合規性;

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

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

“紙上得來終覺淺,絕知此事要躬行。”

選得好,還要用得好,如何才能用好Ksphere和DC/OS企業版呢?我們來看看中國聯通和遊戲公司是怎麼做的?

支撐數千節點,8萬在線實例,中國聯通的DC/OS實踐之路

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

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

2016年,中國聯通開始對cBSS做容器化改造,整體的技術選型是以Mesos、Marathon為核心實現容器資源的分佈式調度與協調,以Haproxy、Confd、Etcd為核心實現服務註冊和業務的引流,以DC/OS為基礎實現數據中心資源實時調度與管理。

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

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

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

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

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

更詳細的技術細節請參考這篇文章

1億會員、500+個微服務子系統,遊戲公司的Ksphere實踐之路

為了適應市場需求變化和技術革新,某遊戲娛樂公司決定通過技術來實現全國集團中心的整體統一,並為將來業務系統預留擴展能力。

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

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

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

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

  • 方案必須完全基於CNCF開源社區,避免廠商技術鎖定;

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

  • 支持多租戶場景,在微服架構下,能夠滿足各產品團隊對於持續集成/持續發布的自服務能力;

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

基於這些選型需求,遊戲公司選擇了D2iQ提供的Dispatch解決方案,在原有的CI流程基礎上,優化了在Kubernetes雲原生環境下的CI流程與CD流程。據了解,優化之後,原本2個月一次的產品生產環境發布,已經縮短到了2週,且測試環境已經實現了每天一次定時發布。
Kubernetes 還是 DC/OS?實現雲原生的路上,選型只是開始! 2

優化之後的CI和CD流程

第二階段:數據統一管控平台建設

第一階段完成之後,該遊戲公司有了進一步優化的目標,想要實現各個業務線之間的充分信息共享,因此,決定開發數據統一管控平台。該平台的主要目標是實現信息資源的整合,提高技術響應的速度,實現信息共享,實現大數據分析和提升數據質量。

該遊戲公司整個應用系統的數據可以根據需求分為三大類:

  • 大數據聚合類:負責業務交易日誌,性能數據聚合等;

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

  • 業務管理類數據:主要負責存儲賬戶,權限,配製等信息。

針對這三類數據,D2iQ的KUDO有狀態數據服務框架及其開源數據服務提供了相應的支撐:

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

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

  • 針對業務管理類數據,KUDO提供了高可用的HDFS集群,滿足客戶的分佈式存儲需求。

獨木難成林,生態建設必不可少

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

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

同時,D2iQ自身的解決方案也會與整個生態系統中的其它技術做整合,用戶可以自由選擇關鍵的技術和組件。
Kubernetes 還是 DC/OS?實現雲原生的路上,選型只是開始! 3

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

本文中涉及D2iQ提供的相關服務,請點擊這裡詳細了解。