【详解】为什么选择Kubernetes作为云平台的微服务治理框架

导读：本文以“为什么选择Kubernetes作为云平台的微服务治理框架”为例，介绍了普元在做与云平台相关的开源技术选型时的一些方法和经验。

如何做开源技术选型？

很多同学在做技术选型的时候，往往过于关注技术/功能上的比较，陷入技术细节和功能特性上的争论。比如A产品有个X功能，看起来很棒，B产品有个Y功能，也不错，选哪个，好纠结……或者A产品的当前版本看起来不错，B就很一般，可是B的Roadmap里写，下一个版本会有个很强大的功能出来，是不是要再等等看，好纠结……

有时候勉强选了A，又看到B发展的也不错，心里不踏实。

其实在我们看来，技术/功能只是技术选型过程中需要考量的诸多维度中的一个，只要这些开源产品大体上能满足我们的需求，架构上没有明显的缺陷，开发语言和现有团队比较匹配、Roadmap比较完善，就没什么大问题，就可以进入其他维度的考量。

我们认为，技术/功能在技术选型中的权重，可能只有四分之一。有很多技术/功能上非常领先的开源项目，并没有得到很好的发展，比如ZFS，比如CloudStack，令人惋惜，这里不一一列举。那么技术选型过程中，除了技术/功能之外，我们还应该关注哪些事情呢？

项目的运作模式

开源项目的运作模式中，我们重点关注以下三点：

1、使用哪种开源License

2、开发模式和测试模式

3、被一家公司掌控还是松散的社区决策？

其中最重要的是License。在很多技术人员的眼中，License问题依然没有得到足够的重视。（对这个问题感兴趣的同学可以移步 http://choosealicense.com/ 查看各种开源License的差异。）

开发模式，值得关注，但是一般知名的开源项目，在开发模式上都不会有太大的问题，更重要的是测试模式。很多开源项目自身不重视测试，把填坑的事情丢给参与厂商，这种项目，如果贵司不是动不动就能派出几十人上百人的大厂，必须慎用。会认真做测试框架、定期发测试报告的项目，必须好评。

项目运作是被一家公司掌控还是松散的社区决策，以前都说大教堂不如集市，那是因为以前大教堂基本上不搞开源，搞开源的大教堂和集市，就难说哪个好了，参与过OpenStack厂商扯皮的同学，应该对这个深有体会。

技术提供者的产业背景

在项目技术提供者的产业背景中，我们重点关注以下三点：

1、技术提供者的产业经验

2、自己有没有大规模使用？

3、是从自身需求沉淀出来的产品还是按设想的需求开发的产品？

现在都讲“吃自己的狗粮”，很多最为成功的产品，都是在自己内部的长期的、大规模的使用中反复锤炼，再发布给公众使用的，最好的例子就是AWS。从自身的实际需求出发的、给自己做的产品，往往会比按设想需求出发的、给客户做的产品更好。所以我们往往更加青睐大型互联网公司释放出来的开源项目，比如Netflix的一系列开源项目。

生态环境

在项目所处于的生态环境中，我们重点关注以下三点：

1、技术和技术提供者在产业链中的位置

2、与友商的合作/竞争关系

3、是众望所归还是单打独斗？

互联网时代，没有生态、就等于没有未来。良好的合作、清晰的分工界面，会让项目得到更好的发展，总想占点上下游的便宜，动别人的奶酪，或者妄图以一己之力对抗全行业，当然也有成功的，但是概率真的很低。

我们的选择

现在回到故事的大背景中，看下我们为什么选择Kubernetes作为普元新一代云平台的微服务治理框架。

首先，以下为我们在云计算项目中遇到的需求：

云计算技术经过近十年的变迁，需求重点已经从早期的虚拟化资源池管理、单体应用的“栈”管理，过渡到了微服务的“图”管理。

管理微服务时，我们需要对这些微服务和它们的调用关系进行注册、为其分配资源、创建一定数量的节点副本、并发布到集群中去，同时还要为其配置好网络和负载均衡，使这些微服务能够被外部访问；在这些微服务的运行过程中，需要始终保持其可用性，一旦有节点出现问题，需要立即创建新的节点将其替换掉；运行过程中需要对这些微服务进行监控和日志收集；在负载发生变化的时候，还要能够迅速调整资源分配。

大体上能满足这些需求的开源项目有Kubernetes、Mesos Marathon、Docker Swarm、OpenShift、Cloud Foundry等等。

我们重点看一下Kubernetes：

可以看到，Kubernetes使用了较为常见的Master-Slave架构，在容器之上又封装了一层Pod结构，很好地适应了多容器服务，也符合Unix的进程模型。Pod通过Label标识为服务（Service），概念简洁明了而且非常灵活。

经常有人问，Mesos资源调度能力更加强大，而且产品推出的时间比较久，更加成熟、稳定，为什么不选择Mesos？还有人拿出了下面这张对比图，证明Mesos的功能更为强大：

需要注意的是，这张图只对比了资源调度，而Kubernetes提供的是从资源调度，到服务发放、变更、退休，到网络管理的全方位能力，而Mesos仅仅是资源调度，服务管理要借助Marathon，而网络管理能力聊胜于无。其他类似的技术，同理，这里就不一一展开了（上面那张图来源于剑桥大学CambridgeSystems at Scale博客的一篇文章，感兴趣的同学可以移步 http://www.cl.cam.ac.uk/research/srg/netos/camsas/blog/2016-03-09-scheduler-architectures.html）。

再来看一下Kubernetes的Roadmap：

我们关注的功能，例如CustomMetrics、Multi-zone、Multi-scheduler、Node affinity等，都在Roadmap之中，还有Device Scheduling这种意想不到的功能，三个月一个版本，进度和我们自己的产品规划也比较吻合。

技术这关到这就算是过了，接下来我们看下Kubernetes项目的运作模式。

Kubernetes使用Apache License，没有对参与厂商做太多的限制。虽然很多厂商在积极贡献代码，但是控制权还是在Google手上，不会出现某些“集体决策”项目因为要不要做一个特性一堆厂商反复扯皮的问题。开源项目的研发过程做到开放透明自然不必多说，在此之上，Kubernetes还做到了接地气，在沟通协作上没有使用所谓的“极客工具”，而是直接使用了Slack、Zoom这样的流行App，每次会议的会议纪要都会发布到Google Docs上，让开发人员之外的技术爱好者也能很方便的获取项目进展的第一手资料。至于测试，有一伙人专门在搞测试框架，对测试的重视程度高于一般开源产品。

评估过了项目的运作模式，我们再来看一下技术提供者的产业背景。大家都知道近两年这一波容器浪潮的推手是Docker，Docker俨然成为容器的代名词，那么Google的位置又在哪里呢？以下为来自Wikipedia的截图：

很多同学可能没注意过，容器的两个根本核心技术之一，cgroups，发起者就是Google，最初的目的是用来管理Google复杂庞大的互联网服务，后来贡献给Linux，至今已经快十年了。而Kubernetes就是源自于Google内部使用、经过多年的锤炼的集群容器管理系统Borg，所以Kubernetes才能做到架构简洁、适应性强而且极具扩展性。有句话说好的架构不是设计出来的，而是进化出来的，这里的反面教材就是Docker，有些同学可能了解Docker的C/S架构和网络设计，带来了多少麻烦，这就是有没有产业经验的区别。

最后，我们来看生态。Kubernetes首先是和CoreOS联合，形成名为Tectonic的端到端容器管理解决方案，而CoreOS又是etcd、rkt、fleet、flannel等一系列优秀开源项目的领头羊，这些开源项目彼此之间做到了很好的对接，避免了使用开源软件时经常碰到的“裁剪”问题。而前段时间的一个新闻更是将Kubernetes所在的生态环境进一步强化：

总结

经过上文的分析，可以看到，Kubernetes在技术/功能、运作模式、产业背景、生态等四个维度有着较为均衡的优势，所以我们选择Kubernetes作为普元新一代云平台的微服务治理框架。下图中浅蓝色的模块基于Kubernetes的能力开发：

（完）

关于作者：

宋潇男

EAII-企业架构创新研究院 专家委员

现任普元云计算架构师，曾任华为云计算产品技术总监。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。