根據CNCF發佈2019年年度調查報告顯示，容器在實際生產環境中的使用率逐年增加，2016年和2018年的容器使用率分別是23%和73%，到了2019年，這一比例上升到了84%。除了使用率，容器的部署規模也在增加，在調查中，58%的受訪者表示其容器部署數量在250個以上。
當容器數量達到一定規模時，就需要容器編排平臺了。最開始，業內能夠稱得上容器編排平臺的就只有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周，且測試環境已經實現了每天一次定時發佈。
第二階段：數據統一管控平臺建設
第一階段完成之後，該遊戲公司有了進一步優化的目標，想要實現各個業務線之間的充分信息共享，因此，決定開發數據統一管控平臺。該平臺的主要目標是實現信息資源的整合，提高技術響應的速度，實現信息共享，實現大數據分析和提升數據質量。
該遊戲公司整個應用系統的數據可以根據需求分爲三大類：
-
大數據聚合類：負責業務交易日誌，性能數據聚合等；
-
實時交易類數據：需提供較高的讀寫性能，與數據一致性要求；
-
業務管理類數據：主要負責存儲賬戶，權限，配製等信息。
針對這三類數據，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自身的解決方案也會與整個生態系統中的其它技術做整合，用戶可以自由選擇關鍵的技術和組件。
據瞭解，目前已經整合的技術和組件包括存儲平臺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提供的相關服務，請點擊閱讀原文詳細瞭解。