Kubernetes 还是 DC/OS？实现云原生的路上，选型只是开始！

根据 CNCF 发布 2019 年年度调查报告显示，容器在实际生产环境中的使用率逐年增加，2016 年和 2018 年的容器使用率分别是 23% 和 73%，到了 2019 年，这一比例上升到了 84%。除了使用率，容器的部署规模也在增加，在调查中，58% 的受访者表示其容器部署数量在 250 个以上。

当容器数量达到一定规模时，就需要容器编排平台了。最开始，业内能够称得上容器编排平台的就只有 Kubernetes，Swarm 只能算是一个管理平台，同时还需要 Compose 和 Docker Machine 等工具的配合，Mesos 虽然作为资源调度平台能够管理容器，但还需要编排工具和组件服务的配合。

不过，Kubernetes “独步天下”的局面没有持续很久，在容器编排平台领域就出现了一个竞争者——DC/OS。DC/OS 是 D2iQ 公司（原名：Mesosphere）牵头开源的一个项目，其核心是基于 Mesos 实现的，可以集中基础设施资源，并实现跨多个分布式应用来共享资源。

1 选型指南：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。那么问题来了，在企业具体实践中，复杂度都表现在什么地方呢？

• 存储资源的复杂度，当企业内的数据中心或机房超过一个时，那么就需要关心如何降低运维的难度，如何按需对业务系统提供即时支持；

• 多需求的复杂度，当企业存在多部门、多业务，且需求不同的时候，那么就要关心如何满足平台提供方与资源提供方的定制化需求；

• 管理流程和人员的复杂性，如何做到集中和统一管理，减少差异化带来的额外成本。

......

2 选型结束，才是开始

选型结束，就万事大吉了吗？不，现在才是开始！即使选择了合适的平台或工具，在实际应用中也难免会踩坑。

我们总结了企业在使用开源解决方案时，通常会遇到的坑：

• 版权升级常出故障；

• 运维复杂性；

• 公有云托管存在弊端；

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

• 无法为任务关键型应用提供可靠支持；

......

如何“避坑”呢？最简单直接的方法就是采用企业级解决方案。相比于开源解决方案，企业级方案更适合大多数企业使用，因为它会针对企业场景进行测试和验证，能够提供质量有保证的版本，同时也会支持和维护旧的版本。同时，企业级解决方案背后的厂商还会提供相应的服务级别协议（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 等复杂服务的时间和工作量；

• 增强互操作性：提供多个服务互操作性测试和支持；

• 保证分布式工作负载安全：减少对安全威胁的暴露，简化策略执行，保证合规性；

• 多租户：跨多个团队使用统一基础设施，提高资源利用率，控制跨资源和工作负载的访问。

3 躬行践履，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 万。

更详细的技术细节请参考这篇文章：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 周，且测试环境已经实现了每天一次定时发布。

优化之后的 CI 和 CD 流程

第二阶段：数据统一管控平台建设

第一阶段完成之后，该游戏公司有了进一步优化的目标，想要实现各个业务线之间的充分信息共享，因此，决定开发数据统一管控平台。该平台的主要目标是实现信息资源的整合，提高技术响应的速度，实现信息共享，实现大数据分析和提升数据质量。

该游戏公司整个应用系统的数据可以根据需求分为三大类：

• 大数据聚合类：负责业务交易日志，性能数据聚合等；

• 实时交易类数据：需提供较高的读写性能，与数据一致性要求；

• 业务管理类数据：主要负责存储账户，权限，配制等信息。

针对这三类数据，D2iQ 的 KUDO 有状态数据服务框架及其开源数据服务提供了相应的支撑：

• 针对大数据聚合类数据，KUDO 提供了不同的数据处理方案，例如对于隔夜 Batch 数据，KUDO 项目提供 Cassandra、Spark 满足客户业务交易日志的分析、聚合与存储；对于实时的性能数据流，KUDO 项目提供 Kafka、Kafka Connect、Spark Streaming 来支撑客户性能数据的聚合处理；

• 针对实时交易类数据，基于 KUDO 框架的 MySQL 容器化高可用解决方案提供了容器化的数据选型思路；

• 针对业务管理类数据，KUDO 提供了高可用的 HDFS 集群，满足客户的分布式存储需求。

4 独木难成林，生态建设必不可少

根据 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提供的相关服务，请点击阅读原文详细了解。