Kubernetes 还是 DC/OS?

本文转自:https://mp.weixin.qq.com/s/vqx6O9X8-FAlhPCd6gktXg

从集群规模、工作负载和复杂度三个方面来看

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

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

集群规模

大集群选 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 介绍

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 等复杂服务的时间和工作量;

增强互操作性:提供多个服务互操作性测试和支持;

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

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

原文地址:https://www.cnblogs.com/syavingcs/p/12761279.html