2020 Google开发者大会重磅开幕 了解详情

Kubernetes 还是 DC/OS?实现云原生的路上,选型只是开始!

2020 年 4 月 10 日

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 实现的,可以集中基础设施资源,并实现跨多个分布式应用来共享资源。


选型指南: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 周,且测试环境已经实现了每天一次定时发布。



优化之后的 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 自身的解决方案也会与整个生态系统中的其它技术做整合,用户可以自由选择关键的技术和组件。



据了解,目前已经整合的技术和组件包括存储平台 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 提供的相关服务,请点击这里详细了解。


2020 年 4 月 10 日 18:11 5094

评论 2 条评论

发布
用户头像
很好的文章
2020 年 04 月 24 日 14:31
回复
用户头像
不错
2020 年 04 月 10 日 19:43
回复
没有更多评论了
发现更多内容

dubbo-go 中使用 sentinel

apache/dubbo-go

golang dubbo sentinel

这16道Redis最常见面试问题,你能回答上来几个?

火羊哥

java\

JVM参数手册

Rayjun

JVM GC

机器学习基石第五节 学习笔记

半亩房顶

Machine Learning

职场求生攻略答疑篇之 2 —— 无所适从的向上沟通

臧萌

Go: 并发访问 Map — Part III

陈思敏捷

go golang 并发 map sync

Android Development最佳实践

teoking

密码朋克的社会实验(三):比特币发明了什么

腾讯安全云鼎实验室

比特币 区块链 密码学

Java七种排序算法以及实现

狸猫换太子

Java 排序算法 实现

新生必备清单:不想成为虚度青春的“小透明”,手机应该怎样选?

脑极体

机器学习基石第二节 学习笔记

半亩房顶

Machine Learning

机器学习基石第三节 学习笔记

半亩房顶

Machine Learning

如何进行需求梳理及埋点方案设计

易观大数据

【面试必问】Spring中的事务管理详解

只喝纯牛奶

机器学习基石第四节 学习笔记

半亩房顶

Machine Learning

这届 Showgirl行不行?AI告诉你谁是ChinaJoy上最漂亮的小姐姐

华为云开发者社区

人工智能 人脸识别 图像识别 展览会论坛会 华为云

最牛逼的Java框架,没有之一

我是苞谷

别在网上乱找代码了,找了一段代码突然爆了!!!

导导

java\

ARTS打卡Week 09

teoking

webRTC框架下的视频主动丢帧

fumingwang

音视频 WebRTC

一年多远程工作经验,说说真实的感受

盛安德软件

秒杀系统

俊俊哥

秒杀

【写作群星榜】7.24~7.31 写作平台优秀作者 & 文章排名

InfoQ写作平台

写作平台 排行榜

格一格你的情欲念

王进行

我收集的 3 个企业经营“失败”案例

泰稳@极客邦科技

JVM系列:通过一个例子分析JIT的汇编代码

简爱W

30岁的二三事

大唐小生

总结 个人感悟

信创舆情一线--抖音、微信读书被判侵害用户个人信息权益

统小信uos

机器学习基石第一节 学习笔记

半亩房顶

Machine Learning

零代码可视化开发平台iVX是什么?

代码制造者

编程语言 可视化 零代码 iVX

数据结构与算法之排序

shirley

排序算法

全球首发的中国原创--“飞算全自动软件工程平台”产品发布会

全球首发的中国原创--“飞算全自动软件工程平台”产品发布会

Kubernetes 还是 DC/OS?实现云原生的路上,选型只是开始!-InfoQ