上海随缘企业登记根据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?实现云原生的路上，选型只是开始。_随缘企登
！毫无疑问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=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万 。
Kubernetes 还是 DC/OS?实现云原生的路上 ！选型只是开始 ，_随缘企登
。更详细的技术细节请参考这篇文章：https://mp.weixin.qq.com/s/Qp0P0LqOSJIztj32HjZGQA，
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项目的代码提交行数在全球企业中排名前十（数据来源：https://www.stackalytics.com/cncf?project_type=kubernetes&metric=loc） ，在社区中不仅创建了容器存储接口标准(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提供的相关服务 ，请点击文末了解更多详细了解。
