DockOne微信分享（一六六）：Kubernetes on DC/OS最佳实践

【编者的话】本次分享内容主要包括Kubernetes on DC/OS的原理与技术实现，图文演示Kubernetes on DC/OS的一些关键功能和特性，以及Kubenetes on DC/OS的应用场景、优势、整体解决方案设计与最佳实践。

考虑大家的知识背景有所不同，在介绍Kubernetes on DC/OS的原理与技术实现之前，我觉得还是有必要先简单地介绍一下Mesos，DC/OS以及Kubernetes之间的关系与区别。

准确的说Mesos与Kubernetes的定位不同，因此不可以简单横向的进行比较。

如图所示，Mesos的定位是分布式资源管理框架，Mesos集群由Mesos Master与Mesos Agent组成，Mesos Master与Mesos Agent安装在通用的Linux操作系统之上，不久的将来，也将会很好地支持Power Linux和Windows。

Mesos Master可以将Mesos Agent的资源进行统一管理，并将Mesos Agent的资源以offer的方式上报给Framework，这些Framework包括Marathon（用于实现容器的管理与调度），Chronos（用于实现任务的管理与调度），第三方应用的Framework，如Spark、Kafka、HDFS、Cassandra等，还有今天我们要分享的Kubernetes。

运行在Mesos之上的Framework需要按照Mesos的接口或者SDK来编写，除了Mesos支持的Certified Framework以及Community Framework之外，用户也可以根据自己的需求来编写Framework，关于Mesos SDK的详情可参考 https://mesosphere.github.io/d ... uide/ 。

可以看出，与容器编排平台Kubernetes不同的是，Mesos其定位是分布式资源管理框架，它仅负责将数据中心的计算资源、存储资源、网络资源以及GPU资源等进行细粒度的拆分，然后将资源提供给上层的Framework来使用，也就是我们常说的二次调度，Framework聚焦在应用本身的调度，而Mesos则仅聚焦在基础资源的调度。

以上便是Meoss的简单介绍，接下来我们再简单说说DC/OS，DC/OS核心基于Mesos实现，但是除了Mesos之外，还包括了Marathon，Metronom，Mesos-DNS，Spartan等三十多个组件，这些组件互相集成、共同协作。目前DC/OS包括两个版本，一个是开源的版本，由Mesosphere以及社区共同维护，另一个是企业版本，由Mesosphere发行并提供服务。

通过使用DC/OS，用户可以以容器的方式运行传统长应用，任务型应用，分布式应用以及微服务，因此个人认为，将DC/OS与Kubernetes进行比较比将Mesos与Kubernetes进行比较更加合理。

对于Kubernetes，想必大家都很了解，在此我不做过多赘述。用一段话总结他们的关系，就是DC/OS核心基于Mesos实现，它和容器编排平台Kubernetes在容器管理上有很多相似的功能，但是应用范围和定位比Kubernetes更广泛。

与众多Framework类似，Kubernetes可以作为一种服务运行在DC/OS平台之上，而接下来我要和大家分享的就是Kubernetes运行在DC/OS的技术实现和关键功能。

如图所示，与其它服务类似，在DC/OS下，Kubernetes是通过服务的方式运行在DC/OS平台之上，用户可以在DC/OS的服务目录中搜索到Kubernetes服务，单击图标对关键的参数进行配置后一键完成Kubernetes平台的部署。

Kubernetes on DC/OS整体的部署流程描述如下：

1、DC/OS中的Marathon会接受Mesos的资源offer，然后将Kubernetes的Framework通过容器的方式部署在Mesos Agent节点上。

2、当Kubernetes的Framework容器运行之后，会与Mesos进行注册，然后接受Mesos资源offer，按照顺序完成Kubernetes各组件的部署。

Kubernetes Framework本身不包括与Kubernetes有关的任何组件，它的作用就是接收Mesos的资源offfer，并按照既定的顺序和策略完成Kubernetes组件的部署与管理。

为了更好的说明运行原理，我对一些关键操作进行了截图。

首先，用户在DC/OS上部署Kuberntes之前，需要在界面上输入相关的参数。

输入Kubernetes的服务名称和一些元数据信息。

输入 Kubernetes CLUSTER IP 的范围，以及节点的数量。

输入etcd服务的配置信息。

输入scheduler的配置信息。

输入Apiserver的配置信息。

输入kubeproxy的配置信息。

可以看出，在Kubernetes on DC/OS场景下，Kubernetes的管理组件采用了模块化拆分，与常规方案不同的是，etcd, Kube-api, Kube-scheduler以及 Kube-controller等组件没有通过二进制的方式集中部署在一台或多台管理节点上，而是通过容器的方式分布式的运行在Mesos的Agent之上。

如下图所示，用户在输入完相关的参数后，Kubernetes Framework会按照etcd, Kube-api, Kube-controller 以及Kube-scheduler的顺序依次完成Kubernetes 各组件的部署，若用户启用了HA模式，那么每个组件容器实例部署的数量为3个，DC/OS中的Minuteman以及Mesos-DNS组件会为服务提供VIP和域名服务，从而实现服务之间的发现与通信。此功能类似于Kubernetes中的CLUSTER IP和Kube-dns。

在完成Kubernetes管理组件的创建后，Framework会继续创建Kubelet，Kubelet 是通过容器的方式运行的，这一点也与通用的方案不太一样。在通用方案中，每个Kubernetes节点安装在一台物理服务器或者一台虚拟机上，每个Kubernetes节点主要包括Kubelet与Kube-proxy组件。

但是在Kubernetes on DC/OS 场景下，Kubelet、Kube-proxy、CoreDNS分别运行在不同的三个UCR容器上（UCR容器是Mesos支持的另外一种容器运行时），Kubelet、Kube-proxy与CoreDNS会一起创建，也就是用户每新增一个Kubernetes节点，就会有Kubelet、Kube-proxy、CoreDNS三个容器同时创建。到目前为止，每个Mesos Agent上仅支持运行一个Kubelet、Kube-proxy以及CoreDNS。

Kubelet成功创建后，Framework会继续运行一些短任务，这些任务的主要作用是在Kubelet节点上创建Kube add-on组件。

这些短任务也是通过容器的方式运行，由Framework创建，但是与Kubernetes服务不同的是，这些任务运行结束后，就会被自动kill掉。

当Kubernetes服务完成安装后，用户可以单击Proxy的图标，访问Kubernetes的Dashboard，如下图所示。

若用户希望增加kubelet节点，可以随时调整node数量，之后Framework再不影响既有平台的同时，完成新的资源扩充，如下图所示。

所以说在Kubernetes on DC/OS场景下，Kubernetes实际上是DC/OS平台下的一个服务，就像Spark、Cassandra以及Kafka等服务一样。在这种场景下，一个很大的特点就是全容器化部署，无论是Kubernetes管理服务还是Kubelet、Kube-proxy以及CoreDNS。

通过Kubernetes on DC/OS，用户可以实现在同一套基础设施上融合所有业务，一个DC/OS主机上不仅可以运行kubelet节点，也可以运行Nginx实例、Cassasndra Node、Kafka Broker、Jenkins Slave、Tensforflow worker、Spark task等等。

Kubelet采用了容器化方式部署，因此这里用到了容器嵌套的技术。但是与虚拟化的嵌套不一样的是，Kubernetes on DC/OS 嵌套的性能损耗非常小，对于CPU和内存来讲，除了Kubelet进程消耗一些额外的资源之外，没有操作系统层面的开销。对于网络，Kubelet容器与Mesos Agent共享Namespace，Pod跨主机通信通过VXLAN实现，Kubelet与DC/OS Agent共享一个VTEP IP，不存在网络多层封装的问题，因此也没有额外的开销。

以上就是Kubernetes on DC/OS的原理与实现方式，接下来我们在介绍一下Kubernetes on DC/OS的方案优势和适用场景。

首先，通过DC/OS部署Kubernetes，用户可以实现Kubernetes的全自动化部署、配置、升级与扩容。这种优势在节点越多的时候体现的越明显，用户可以在一个小时之内部署上百个节点规模的Kubernetes，再输入完必要的参数后，一键即可完成部署。

其次，通过DC/OS部署Kubernetes，用户可以综合地利用Mesos与Kubernetes的优势，目前Kubernetes在容器编排领域无疑是最优秀的平台，但其目前对分布式应用如Kafka、Cassandra、Spark、Tensorflow等应用支持的还不够好，而DC/OS早已支持Kafka、Cassandra、Spark、Tensorflow这些分布式应用并得到大规模的生产验证，所以若希望通过全融合的方式搭建一套基础设施，该方案是比较理想的。

因此总结起来，Kubernetes on DC/OS非常适用希望构建全融合数据中心的用户，特别是大规模、混合云的场景。这种场景下用户的数据中心平台不仅仅用于承载新一代的无状态的容器应用以及微服务，也可以同时承载传统应用、DevOps工具以及分布式应用。

最后我们再聊一聊方案设计。

1、业务规划

采用Kubernetes on DC/OS的用户，通常也需要同一个平台上同时运行传统业务以及分布式应用，典型的方案是用户使用DC/OS承载DevOps工具，分布式应用以及传统的应用，用Kubernetes承载一些无状态应用或者微服务。用户可利用DevOps工具根据实际情况将应用交付至DC/OS平台或者Kubernetes平台上，运行在Kubernetes上的应用可以与运行在DC/OS上的应用互相通信。

目前为止Kubernetes DNS与Mesos DNS还没有完全实现融合，Kubernetes的服务与DC/OS的服务通信需要通过IP或者借助第三方DNS服务器实现。但是不久之后，两者将会完全融合，因此DC/OS平台上的服务将会与DC/OS的服务采用统一的命名标准，从而更加方便不同平台之间的服务发现与通信。

2、节点规划

DC/OS 部署在通用的操作系统之上，因此对底层的资源无过多限制，用户可以选择将节点部署在物理机上也可以选择将节点部署在虚拟化平台、私有云IaaS资源或者公有云IaaS资源上，也可以根据需求混合部署。

若希望构建多区域的混合云，建议将DC/OS Master部署在同一区域内，例如数据中心A部署DC/OS Master 和 DC/OS Agent，数据中心B只部署DC/OS Agent，若有更多的数据中心，推荐其它数据中心也只部署DC/OS Agent。运行在DC/OS上的Framework具有区域感知功能，会根据策略灵活地将任务调度到不同的数据中心上。

DC/OS即将会支持Kubernetes多集群部署，因此建议在不同的区域上部署不同的Kubernetes集群。

而在同一物理数据中心中，Kubernetes 与 DC/OS 其它服务会融合部署，若用户有硬件资源的隔离需求，也可通过Mesos Placement Constrain的方式将不同的服务部署在不同的物理服务器上，从而却分Kubernetes与其它的服务。

3、网络规划

在网络方面，DC/OS网络支持Host，Bridge以及VXLAN三种模式，用户可以规划多个VXLAN网络从而隔离不同类型的应用。

目前为止，Kubernetes仅能使用DC/OS 的VXLAN模式，每个Kubelet与其所在的DC/OS Agent共享VTEP IP，运行在Kubernetes上的容器若跨主机通信需要VXLAN网络封装。

所以最佳的建议是用户为Kubernetes规划一个单独的VXLAN网络，而对于其它类型的服务，则可以使用Host或Bridge模式的网络，也可以使用与Kubernetes不同的VXLAN网络。

4、存储规划

存储方面的规划取决于实际业务需求，DC/OS支持多种类型的存储，如包本地临时存储、本地持久化存储、分布式共享存储以及集中存储，多种存储也可以同时使用。在存储规划方面，Kubernetes 的存储使用不依赖于DC/OS，用户完全可以按照Kubernetes的标准来为运行在Kubernetes上的应用灵活地选取存储。

Q&A

Q：目前有公司落地这套方案上生产吗？ 在AWS是否实践过这个方案？

A：Kubernetes on DC/OS是去年九月份官方由Mesosphere支持，经过半年的迭代开发，版本已经GA。目前国外的案例较多一些，国内的中国联通与中国石化正在尝试使用，国内的中国联通希望结合着Fabric8一起来使用，中石化希望用来运行微服务。目前AWS Marketplace支持DC/OS，国外很多用户也在用AWS构建混合云方案，Kubernetes on DC/OS屏蔽了底层，所以只要DC/OS运行在AWS上，Kubernetes就没有问题。

Q：Kubelet、Kube-proxy、CoreDNS是一一个Pod中的三个容器运行在Agent节点上？还是以三个独立的UCR容器运行在Agent上？

A：是通过三个UCR独立的容器运行在同一个Mesos Agent上。

Q: 进来的晚了，那个图形管理控制台叫什么名字？

A：Kube-dashboard，是Kubernetes的一个add-on组件。

Q：DC/OS全称是什么？物理机跑虚拟机，虚拟机跑DC/OS，DC/OS又嵌套容器会不会无止境的架构，越来越复杂？

A：全称就是DC/OS，也称Datacenter Operating System，数据中心操作系统。不会无止境的，UCR官方支持嵌套三十二层，但是我们容器层面一般只嵌套一层，而且容器与虚拟机最大的不同就是不会造成OS的开销，所以多几层嵌套问题也不大。

Q：如果同一个集群内部的其他应用没有和Kubernetes在一个VXLAN里面，他们如何通讯，可以通过VIP吗？

A：需要通过负载均衡、Node port或Ingress的方式，不久之后DC/OS的服务会和Kubernetes的服务全面融合。

Q：很高兴能看到关于Mesos的分享，目前发现Mesos越来越被边缘化的趋势，比方说Cassandra Framework已经在GitHub上标记为过时了，我的问题是DC/OS以后会是Mesos主流的部署方式吗？用Mesos如果要使用Framework的话是不是要自己去封装？

A：不能说被边缘化，很多大型互联网厂商都是低调的在使用，毕竟技术定位还是不同，而且Mesos确实在资源管理方面有其独特的优势。而且Cassandra虽然在GitHub上过时了，但是在Mesosphere内部从未过时，版本更新的很快，还可以无缝迁移。DC/OS的核心基于Mesos，这个不会变，但是支持Kubernetes是我们的重中之中，这个也不会变。DC/OS的Framework目前已经好几十种，Mesosphere也在不断地扩大生态，感兴趣可以到官方Universe上查看，那里详细地例举了Framework以及不同的版本号。

Q：Server Agent的高可用，以及它们任务调度和Framework上的容器调度，任务调度有关系吗？

A：Server Agent，您是指Mesos Agent吗？DC/OS 与VMware等虚拟化平台在某些方面有类似的功能，比如说，若Agent节点出现故障，DC/OS上的Framework会将task自动重启，或者在其他主机重启，对于有状态服务，建议使用共享存储方案。

Q：如果同一个集群内的其他应用和Kubernetes不在一个VXLAN中，他们之间可以怎样通讯？有什么比较好的解决方案？

A：若DC/OS的服务与Kubernetes不在同一个VXLAN上，目前就需要使用Kubernetes的 NODE IP，Ingress或则LB，这个和开源Kubernetes使用方式一致。当前的Kubernetes内的服务还只能处在一个flat network内，但是可以集成第三方Plugin，这个和DC/OS关系不大，用户可自行选择。

Q：实际使用中Kafka、Elastic组件会出现集群不稳定情况，比如Kafka起三个broker，死活启动不了三个的情况，有好的解决办法吗？补充，因为是Framework的方式感觉不如Docker好管理。

A：起不来的原因有很多，但是我很少遇见一直起不来，有可能是单节点资源不够，有可能是网络原因导致一些镜像或artifacts fetch不下来或者是节点数量不够，但是Framework与Docker的定位毕竟不同，也不属于一个技术。这个我们可以私下交流，我可以帮助您解决一些部署服务的问题。

Q：刚才讲的节点规划，多区域管理是不是说的是企业版的功能？

A：这个是DC/OS 1.11的新功能，多区域，同时Framework支持故障感知。但是是不是只有企业版支持，我需要查看一下，您也可以到DC/OS社区网站查看。

Q：直接用Mesos可以部署DC/OS点Framework吗？

A：可以，只不过操作起来没那么容易，需要一定的专业知识。毕竟Framework就是基于Mesos开发而成，很多互联网厂商也是仅用了Mesos，但是自己开发了很多Framework，既满足自己的业务需求，也为了操作简便。

Q：DC/OS社区版跟企业版有多大的差异？

A：当前的差异主要体现在安全、多租户、Edge-LB等几个方面，其它方面差异不大。

Q：既然Marathon有容器编排功能，为何要弃Marathon，而用Kubernetes，增加体系复杂性，我的问题是，这只是为了满足用户偏好还是确实有设计或性能优势？

A：没有嫌弃不用，Kubernetes的Framework不就是Marathon创建的吗？而且Marathon与Kubernetes的运行机制也不太一样，各有各的优势。只是因为Kubemetes在容器编排方面确实很优秀，而且生态很好，因此为客户提供更多的选择。这个绝对不是为了满足用户偏好，不然公司不会投入这么多，大家每天都在群里面讨论如何优化性能，提供差异化的服务。从发布到现在仅仅六个月，但是方便的话可以体验一下，确实在管理和运维上有很多优势。而且从Roadmap上看未来在性能和安全上会有很多新的提升。

Q：为什么不直接用Kubernetes就好了呢？引入Mesos一套技术栈，投入和产出相比如何？

A：还是分享时说的，Mesos在管理分布式系统上有独特的优势，您可以体验一下，在DC/OS安装Spark、HDFS、Cassandra、Kafka等，再试着用Kubernetes上安装一下，就解释的通了。

以上内容根据2018年4月12日晚微信群分享内容整理。 分享人 曹治政，Mesosphere senior solution architect。曹治政 在Mesosphere 参与过多个大型容器云项目的方案设计和服务支持，在Docker，Mesos以及kubernetes等领域具备比较深刻的认识和丰富的实践经验。在加入Mesosphere前，曹治政曾在华为、华三等公司分别担任数据中心解决方案架构师以及PaaS云平台产品经理，理论基础扎实，实践经验丰富，对传统云数据中心以及新一代的云原生应用数据中心均有较深入和独特的理解 。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesa，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。