作为一个开源项目，Kubernetes 的发展速度之快着实令人咋舌。发布至今，2 年时间，Kubernetes 在 GitHub 上的活跃度就已经超过了 99.99% 的项目。这短短的两年间，到底发生了什么？可预见的未来里，Kubernetes 又会扮演怎样的角色？

2015 年 7 月 21 日，Google 宣布成立 CNCF 基金会，并正式发布 Kubernetes 1.0 版本。经过 2 年多时间的迅猛发展，Kubernetes 已经从昔日的小树苗长成了苍天大树，甚至有人说 Kubernetes 已经赢得了容器之战。而就在前段时间，GitHub 宣布他们已经全部切换到 Kubernetes 集群，京东也表示他们有超过 60% 的线上业务跑在 Kubernetes 上，这些典型案例无疑给 Kubernetes 社区注入了一针强心剂。
回顾这两年，容器生态圈到底发生了哪些有意思的事情？Kubernetes 经历了哪些成长和变化？Docker、Mesos、OpenStack 等相关开源项目了？在 Kubernetes 2 周岁之际，InfoQ 邀请才云科技 CEO 张鑫来为大家剖析解读这个来自 Google 的开源项目发展背后的风风雨雨。

生于地震、起于乱世：Kubernetes 发展回顾

皑皑白雪下的避暑山庄
2014 年美国的秋季，寒意来得格外早；而在 Google 内部，一场火热的“地震”却轰轰烈烈地展开，公司内部称之为 “Ursquake”（地震 earthquake 的谐音）。原来，这皆起源于 Google Technical Infrastructure 的老大，瑞士籍 Senior Vice President，Urs Hölzle。Google 公司组织架构的顶层由众多 PA（Product Area）构成，Urs 所领导的 Technical Infrastructure PA 负责管理 Google 上百个数据中心、逾百万台机器的基础架构，为公司内部所有其他业务 PA（例如广告 PA、移动和媒体 PA 等）提供“算力”支持；而这套基础架构，则以 Cluster Management 生态体系为核心，通过全容器化管理、分布式存储、软件定义网络这“三驾马车”，为上层的生产业务（如 Google Search）和批处理任务（如大数据和深度学习）提供外界难以匹敌的功能、性能、和稳定性的保障。

“酒香也怕巷子深”，这套 10 年间饱含上百位 Google 精英工程师的工程杰作，无奈也只能作为业务支持和公司的成本中心；而基础架构的工程们，每每在提交升职申请时，也只能以“支持了什么业务”、为公司“省了多少钱”为度量，颇有为人做嫁衣的感慨，少了诸如广告 PA 的同事们“为公司挣了多少亿”的意气风发。

Urs’ earthquake，即 Ursquake，正是看到了 2014 年云计算的大潮和 AWS 的成功，旨在将幕后英雄推到台前，将 Google 内部一流的基础设施变成公开的盈利产品，将 Technical Infrastructure 这一成本中心变成公司的利润中心。虽然当时在已经上云的企业里，AWS 在 14 年的市场占有率已经超过了 80%，但整体上云的公司比例甚微，Urs 和 Google 志在啃下还未开采过的蛋糕。

“理想很丰满、现实很骨感”，志向在落地时却遇到了两大难题：

AWS 的先发优势和产品成熟度优势如何赶超?
PaaS 和 IaaS 产品之间的矛盾如何解决：Google 的公有云 PaaS 产品 AppEngine 虽有很强的托管性（自动部署、运维），但灵活性较差（只支持固定语言和中间件）；而 IaaS 产品 Compute Engine 虽然灵活性高（近似裸机的可配置性），但管理性很低（用户自行进行应用安装、维护、配置）。

为了解决这一难题，2015 年的 3 月，在皑皑白雪覆盖下的避暑山庄 Woodloch 里，举行了闭门 Google Cloud Summit，经一致讨论决定，解决上述问题的核心，就是通过推出开源的容器编排管理系统 “Project 7”，利用开源社区迅速圈粉、打造生态、“shape people’s mind”，进行市场颠覆。同时，这一开源系统既提供了底层的容器、网络、存储等配置项，又提供了丰富的管理功能，从而打破了上述 PaaS 与 IaaS 产品在灵活性与托管性之间的矛盾。而在问世之后，“Project 7”也很快更名为“Kubernetes”。

标志性的 1.0 与 CNCF

Kubernetes 站在了 Google 内部久经考验的容器管理系统 Borg 的肩膀上；同时也吸取了旨在替代 Borg 但是没有成功的 Omega 项目的失败经验。Omega 项目出现的动机，就是为了解决 Borg 里控制节点（Borgmaster）单体化严重、与集群管理生态中其他组件互动不够、使用和配置极其复杂等问题；而 Omega 项目的失败，则要归咎于工程上无法解决 Omega 调度精度与吞吐量的矛盾、从 Borg 到 Omega 的平滑过度等挑战上。Kubernetes 则很好地规避了上述问题。

2014 年 6 月 6 号，在这一个吉利的日子里，Kubernetes founder 之一 Joe Beta 在 GitHub 上合并了第一个 GitHub commit；在另外两位早期创始人 Brendan Burns 和 Craig McLuckie 的带领下，Kubernetes 团队迅速扩大，其中包括了在 Google 内部曾经带领 Omega 项目的 Brian Grant 和 Borg 技术带头人 Tim Hockin。一年之后，2015 年 7 月 21 日，Kubernetes 宣布发布正式 1.0 版本，达到生产可用。随后，Kubernetes 在以每季度一个新版本的速度快步向前发展，在两岁生日时已经问世了 1.7 版本。

伴随着 Kubernetes 1.0 的发布，Cloud Native Computing Foundation（CNCF）也同时宣布问世，从此为 Kubernetes 撑起了一朵强大的法律、运营、项目维护的保护伞，让 Kubernetes 项目自身可以专注在技术创新上。与 Apache 基金会截然不同，CNCF 并不会把自身的组织架构和管理模式强加在其成员项目上，而是让其成员项目如 Kubernetes 更加自治化地自我管理，并提供如下维度的帮助：

生态绑定：将紧密围绕 Kubernetes 的插件项目（如 linkerd、fluentd、promethues）放在同一个 CNCF 生态下，形成有机的绑定。
法律保护：保障 Kubernetes 的商标、Logo、License、专利、版权等被合理使用和消费。
市场推广：通过 meetups、K8sPort、Kubecon、Blog、Twitter、新闻媒体等线下、线上活动对 Kubernetes 等技术进行推广。
培训认证：制定规范、流程、课程来对 Kubernetes 等技术进行普及和相应的盈利。
最后，协调不同厂商之间的关系和竞争。

在“竞合”乱世中突围

Docker 公司带火了容器技术，也让几乎所有的云计算厂商意识到了新的机会。早在 2009 年问世的 Apache Mesos 项目也在 Docker 问世后通过与 Docker 的整合焕发了第二春，并定位为基于容器的数据中心操作系统（Data Center Operating System, 即 DCOS），在一定程度上与容器集群管理平台 Kubernetes 发生了定位上的重叠。而 Docker 公司也随后意识到容器自身只是一个轻薄的、底层的运行载体，很难大规模盈利并推动企业在复杂生产环境下使用；因此也开始研发自带的集群管理工具 Docker Swarm, 并在 Docker 1.12 版本后将 Swarm 集成在了 Docker 引擎中，引发了社区的一片争议。而后 Docker 公司推出的 Swarmkit，更是将其进军集群管理领域的雄心壮志昭示于天下。

Kubernetes 的领导者们从一开始就意识到了生态“竞合”关系的重要性，在一路上打出了“中立”的旗号，博得社区的认同和好感；同时一直努力支持底层不同的容器运行时和引擎，逐渐解除对 Docker 的依赖。在 Kubernetes 婴儿时期，领导者们选择了更加讨好社区的“老好人”做法，通过借助更多资源帮助自己高速成长。早在 2015 年 5 月，当 Kubernetes 宣布支持除了 Docker 以外的新的容器运行时 AppC 和 rkt 时，Kubernetes 的产品经理 Craig McLuckie 就专门发博客表明此举并非是要替代 Docker，并大肆赞扬了 Docker 为生态所做的贡献。而在更早的 2015 年 4 月 22 日，Kubernetes 官方博客专门报道了 Mesosphere 将 Kubernetes 集成进 DCOS 的消息。

随着 Kubernetes 的壮大，在 2016 年 Kubernetes 愈发明显地赢得了容器管理之战时，Kubernetes 对于其他“兄弟项目”的态度也愈发的强势，例如 2016 年 Kubernetes 布道师 Kelsey Hightowers 和 Docker 高层在 twitter 上的爆发的口水战、在 2016 年西雅图 KubeCon 的多个主题演讲中直白地宣示着 Kubernetes 的领导者地位、到 Kubernetes 社区放大对 container runtime、network plugin 等抽象接口的投入。

连横合纵、落地结果

一个开源项目的壮大，除了领头人和技术社区，还需要众多厂商的支持和有说服力的用户群体。在 2015 年 7 月发布 1.0 之际，Kubernetes 的合作伙伴、厂商、用户还只是聚集在早期贡献者如 Red Hat、Mirantis、Rackspace、CoreOS 和区区几个名不见经传的创业公司。伴随着 Kubernetes 的一个个里程碑式的版本发布，Kubernetes 的功能性、稳定性、实用性得到了不断升华，也吸引了众多 500 强大厂纷纷参与进来，变成了合作伙伴、厂商和终端用户：

2016 年 Q2-Q3: 以 Mirantis 为首的 OpenStack 厂商积极推动与 Kubernetes 的整合，避免站在 Kubernetes 的对立面，成为被 Kubernetes 推翻的“老一代技术”。
2016 年 11 月，CNCF 与 Linux Foundation 联手，正式推出 Kubernetes 认证服务，进一步推动 Kubernetes 的商业化落地和普及。
2016 年 11 月，在西雅图召开的 KubeCon 会议上，包括 Pearson、Box 等数十家 Kubernetes 终端用户向世人展示了 Kubernetes 在其生产环境中的成功应用。
2016 年 12 月，伴随着 Kubernetes 1.5 的发布，Windows Server 和 Windows 容器可以正式支持 Kubernetes，微软生态完美融入。
2017 年 2 月，Kubernetes 官方微博报道了中国京东用 Kubernetes 替代了 OpenStack 中的大量服务和组件，实现全容器化私有云和公有云的建设，中国的 Kubernetes 用户案例首次登上国际舞台。
2017 年 6 月，在北京召开的 LinuxCon 上，中国公司报道了 Kubernetes 在中国金融、电力、互联网行业的成功案例，标志着 Kubernetes 的终端用户群体走向国际化。
2 岁生日之际，Kubernetes 的用户涵盖了诸如金融（摩根斯坦利、高盛）、互联网（eBay、Box、GitHub）、传媒（Pearson、New York Times）、通信（三星、华为）等行业的龙头企业。

State of the Kube：Kubernetes 项目现状

99.99%!
简单地回顾完历史，我们概览下 Kubernetes 今天的模样。如果用一个词来形容 Kubernetes 项目的当今状况，那就是 —— 活跃；如果非要给这个词加一个期限，笔者希望是 —— 十年。通过一组客观的官方数据，我们可以感性地体会到 Kubernetes 项目的活跃程度。

从 2015 年 7 月到 2017 年 7 月两年时间，Kubernetes 的主要代码仓库（github.com/kubernetes/kubernetes）从 1.0 版本时的 10000+ commits 变成了如今的近 50000+ commits，增长近五倍。
发展至今，Kubernetes 已经从一个单体的庞大代码库（github.com/kubernetes/kubernetes）向一个生态型多个代码库演进；除了主体代码库之外，还有约 40 个其他的插件代码库和超过 20 的孵化项目。
截止今日，Kubernetes 生态社区总共有 2505 个开发者，来自于 789 个参与公司
有意思的是，“大象现象”同样存在于社区贡献者中，前 10 的贡献者贡献了超过 26% 的代码。
Kubernetes 的主要代码仓库已经获得了近 25000 个 GitHub Stars，遥遥领先于早期的竞争者（Swarm 和 Mesos 均不到 5000 颗星）。
CNCF 在全球召开了超过 200 场线下 meetups，仅在中国就有过十场。
而最具代表性、最直观的一个数据，莫过于：Kubernetes 的 GitHub 活跃度已经超过了 99.99% 的项目！

快而不散

社区的发展之快如今甚至超过了 Kubernetes 创始人的预期。根据 2016 年 11 月西雅图 KubeCon 上发布的数据，Kubernetes 的缔造者和带头人 Google 所贡献的代码量约为 40%+，超过半数的贡献来自 Google 以外的公司和社区开发者。2000 多位的贡献者在高速推动项目发展的同时，也为保证开源项目的一致性、稳定性和中立性提出了极高的挑战。在 2017 年 6 月 2 号位于美国圣何塞三星公司召开的 Kubernetes Leadership Summit 上，当 Kubernetes 创始人之一 Brendan Burns 被问到是否需要更多的社区贡献者的时候，Mr Burns 的回答却是： “Maybe not”。当然，Kubernetes 的领导者和 CNCF 绝非等闲之辈，也提出了从管理和技术层面两个维度的解决方案。
首先在管理维度上，CNCF 与 Kubernetes 社区一起正式提出了管理架构（如图 1 所示），来帮助更好地分布式地运营这一开源项目，其中包括：

Steering Committee：作为最高决策董事会，肩负了把握项目方向、定义文化、规则、管理团队等使命。同时 Steering Committee 要时刻提醒自己最大程度放权，将具体任务委托给下面相应的管理团队。目前 Steering Committee 设有 13 个席位，由提名、竞选产生。
Special Interest Groups（SIG）：拥有和负责具体的子代码库和功能模块。
Working Group（WG）：根据实现短期任务的需求临时组建，或负责讨论早期的功能点。
Committee: 负责讨论敏感话题（如安全、行为规范），由闭门组织讨论并推行（不面向社区）。
这样的管理组织架构，保证了整个 Kubernetes 的社区能够在有机的层次领导下快而不散，既自治又集权。除了管理，Kubernetes 的项目架构也在进行调整和演化，通过更加模块化、解耦合、分层次的架构，让数千位贡献者能够高效地分布式协作而无需做自己的 fork 版本。

图 1. Kubernetes 项目管理组织架构【1】

苦练内功

如果说早期 Kubernetes 能够迅速走到聚光灯下是因为顶着 Google 的光环，那发展至今天它被各行业用户广泛采纳和应用则是得益于它的真功夫：功能性、稳定性、可扩展性、安全性。直到今天，Kubernetes 社区最大的努力还是花在苦练内功上，致力让每个季度的新版本都有十足的飞跃。以推出新功能为例，我们可以从下面的数据【2】上看到社区的努力和加速的脚步：

在 2017 年 3 月份推出的 Kubernetes 1.6 版本中，总共包含 29 个新的功能点，其中 8 个 Alpha 版本，12 个 Beta 版本，9 个 Stable 版本。1.6 版本关注的领域如下：
存储 (10 个新功能点)
调度 (5 个新功能点)
集群生命周期管理 (4 个新功能点)
认证授权 (RBAC)
在 2017 年 6 月推出的 Kubernetes 1.7 版本中，则一口气发布了 43 个新的功能点，其中 Alpha 版本占 31 个，Beta 占 6 个，Stable 占 3 个。而关注的领域也有了较大的变化：
Apps 子模块让复杂应用的部署和管理更加的便捷。
Federation 子模块让 Kubernetes 可以无限扩展同时提供跨域多活和负载均衡。
Node 子模块更加深化 Container Runtime Interface (CRI) 的整合，加速对容器的普适性并实现与 Docker 的解耦合。
Auth 子模块通过更完善的证书管理、加密、审计来提升安全性。
除了上述功能性的飞速完善，Kubernetes 开发者更是在可扩展性、稳定性和可靠性上下足了功夫。以集群规模为例，两年前的 Kubernetes 1.0 版本只能支持单集群 100 个节点，而在 2017 年 3 月份发布的 1.6 版本中，单集群已经可支持 5000 个节点，同时 API 相应延时更小。而集群联邦功能更是可以跳出单集群的限制，让集群规模几十倍、上百倍的增加。

社区格局与主要玩家

随着 Kubernetes 的壮大，其社区也时刻进行着动态的演化。尤其在国内，也出现了从早期受其他阵营厂商挤兑到现在众人蜂拥而至的变化。从贡献者上来看，Google 仍以 40%+ 的贡献率领跑社区，而个人开发者的贡献量总和也一跃超过了 25%。相比之下，红帽、CoreOS 等早期参与的公司仍持续投入。从 2016 年开始，中国力量也开始登上国际舞台，以代码贡献度为例，如图 2 所示，中兴、华为、浙大、才云为贡献最高的 4 个来自中国的公司或组织，并进入了全球 top 25 贡献度排行榜。除此以外，来自华为、才云的演讲也被选拔连续多次登上 Kubernetes 的国际会议 KubeCon。
2 年来，Kubernetes 的厂商格局也不断演化。在美国，Red Hat、CoreOS 作为 Kubernetes 项目参与者，纷纷推出了自己的商业发行版。早期的 Kubernetes 创业公司如 Kismatic、Deis 在过去一年中纷纷被并购（Kismatic 被 Apprenda 并购，而 Deis 则被微软收购），显示了大厂对 Kubernetes 方向的看好。此外，Kubernetes 早期的三个 founders 也均已不在 Google，其中的 Joe Beta 和 Craig McLuckie 也创办了 Kubernetes 产品公司 Heptio，立志让企业更方便的使用 Kubernetes。
在巨头一端，除了 Google 理所当然的大张旗鼓支持 Kubernetes 并提供商业的 Google Container Engine（GKE），微软也毫不手软，挖走了 Kubernetes 创始人兼原 Google 工程师 Brendan Burns 并收购 Deis。反观 AWS，其对于容器的重视程度毫无疑问，无奈在 Kubernetes 问世之前 AWS 自己研发了 ECS；如今 AWS 虽然支持 Kubernetes，但碍于 ECS 的存在，AWS 并没有在 Kubernetes 上发力过猛，反而显得束手束脚，影响了开发者体验。这不禁让人期待，若干年后再看 Google 当初用开源 Kubernetes 作为秘密武器来牵制 AWS 这一奇招儿是否会真的奏效。
在国内，Kubernetes 的热度丝毫不减，才云、时速云、轻元科技等创业公司在成立之初便以 Kubernetes 作为其底层容器管理平台。随着 Kubernetes 热度的增加，腾讯、华为、京东等大商也纷纷投入了 Kubernetes 阵营。而受大势所趋，一些之前在 Mesos、Swarm 阵营的创业公司也纷纷涌入 Kubernetes 大潮。还有一类公司例如 Rancher，则以兼容并包的定位，在支持自研调度框架、Swarm、Mesos 之外，同时兼容 Kubernetes。

图 2. Kubernetes 社区的主要贡献公司【3】 ## 实践得真知：Kubernetes 的落地与应用

数据之王

在全球范围内，除了各大公有云已经竞相支持 Kubernetes，在企业私有云场景下 Kubernetes 也在互联网、金融、通信、能源、电商和传统行业中获得了极为广泛的应用，并有适配底层裸机环境、OpenStack 环境、VMWare 环境等多种案例。仅在中国，Kubernetes 就已经拥有了诸如京东、国家电网、锦江集团、上汽集团、某大型银行组织等 500 强企业用户。
特别是在私有云场景下，Kubernetes 获得了巨大的成功：根据 2017 年 5 月美国权威调研机构 451 Research 与 CoreOS 发布的调研报告【4】表明，80% 的美国受访企业认为 Kubernetes 足以取代 PaaS，其中 75% 的企业已经在使用 Kubernetes 来管理其容器云平台，以绝对优势领跑其他容器管理工具。在中国市场，2017 年 6 月 Kubernetes 中国社区 K8SMeetup 曾组织了国内首个针对中国容器开发者和企业用户的调研；近 100 个受访用户和企业中给我们带来了有趣的关于 Kubernetes 在中国落地状况的观察：

如图 3 所示，在受访企业中，Kubernetes 以高达近 70% 的使用率成为最受欢迎的容器管理系统。
如图 4 所示，在受访企业中，除了简单的 Web 应用，越来越多的有状态、数据类应用也运行在了 Kubernetes 平台上。

图 3. 容器管理工具在中国受访企业用户中的使用分布

图 4. 在中国受访企业用户中，Kubernetes 平台上运行的应用类型分布

The Good, the Bad, and the Ugly

在数据之外，我们试图透过现象分析本质：为什么 Kubernetes 这么流行？在落地过程中，用户最喜欢和最痛恨 Kubernetes 的哪些方面？Kubernetes 在落地的过程中存在哪些大坑？图 5 和图 6 总结了 K8SMeetup 容器调研中通过受访企业中发现的一些端倪。

图 5. 中国受访企业用户最喜欢 Kubernetes 的方面

图 6. 中国受访企业用户最不喜欢 Kubernetes 的方面特别针对 Kubernetes 在企业落地中的不足和陷阱，笔者结合自己的切身体会总结如下： * 上游默认的 Kubernetes 配置都是基于公有云环境或拥有完善的 IaaS 层 API，而对于私有云裸机环境的支持相对欠缺，需要进行额外开发。 * Kubernetes 的学习曲线较长，基于命令行和 JSON/YAML 的配置文件学习成本不低。传统行业技术债务较重、单体或有状态应用较多，适配 Kubernetes 的现代微服务理念需要额外的二次开发工作或对 Kubernetes 高级配置项的深入理解。 * Kubernetes 集群的部署较为繁琐，尤其是在线升级缺乏成熟的上游开源方案。 * 上游的开源 Kubernetes 项目仍存在一些功能死角，例如多维度多指标的弹性伸缩、对于硬盘和网络资源的细粒度隔离、对于资源配合的合理配置等。然而好消息是，随着 Kubernetes 的快速迭代和开源社区的强有力支持，上述问题有望在 2017 年内获得突破性进展。

基础设施的解放、自由、与开放

Kubernetes 是云原生（Cloud Native Computing）哲学的体现，通过容器技术和抽象的 IaaS 接口，屏蔽了底层基础设施的细节和差异，可实现多环境部署并可以在多环境之间灵活迁移；这样一方面可以实现跨域、多环境的高可用多活灾备，另一方面帮助用户不必被某个云厂商、底层环境所绑定。
如图 7 所示，在中国的容器调研受访企业中，裸机环境、OpenStack、虚拟化、多种公有云供应商形成了 Kubernetes 运行环境的“四分天下”格局。而 Kubernetes 恰恰给了用户足够的灵活度，可以让其自身的业务系统快速部署、运行在不同的底层环境、数据中心、甚至公有云之上，实现业务高可用和商务利益最大化。
笔者相信在相当长的一段时间内，由于存量投入，多基础设施的混合部署会成为 Kubernetes 运行的主流，而将 Kubernetes 绑定到某一种特定的 IaaS 一定违背了云原生的哲学和 Kubernetes 的设计初衷。此外，笔者相信随着 Kubernetes 的成熟和用户的成熟，在新的增量市场环境中，如同 Google 一样用 Kubernetes 直接管理数据中心（运行在裸机之上，同时与对应的存储、网络方案打通）则会成为最长期的趋势和最合理的选择。

图 7. 中国受访企业运行 Kubernetes 的底层环境分布

十字路口：Kubernetes 的彷徨、挑战、应对、与未来

剩下的 90% 问题

Kubernetes 如今获得了巨大的成功，然而在它的领导者的眼里，会给这个成功打多少分？在 Kubernetes 技术带头人 Tim Hockin 2017 年 6 月发表的 Kubernetes 现状总结中，他指出：“所有简单的问题都已经得到了解决，还剩下什么？那是 90% 的疑难杂症！” 而他口中的这些疑难杂症，包括：

代码健康度：测试覆盖率有待提升、测试稳定性有待提升、很多代码模块亟待重构。
开发者体验：新的贡献者上手困难、文档需要完善、现存很多 hacky 脚本难以理解。
稳定性和可预测性需要同开发新功能一样受到足够重视。
社区和开源项目的管理要在开放的同时保持一致和可控。
而社区开发者也反馈了 Kubernetes 项目当前发展中遇到的一些问题，例如：
对于新功能如何被选取、映射到未来某个发布版本中的决策流程感到不够明确。
新功能的讨论、设计和开发门槛极高，沟通成本和设计文档的审核延时阻碍了生产效率。
SIG 产品经理对于新功能产品规划的帮助和理解不够出彩。
此外，持续完善 Kubernetes 的功能，让它能够适用更多的场景也是技术社区投入最多精力的地方。虽然 Kubernetes 1.7 已经解决了“世界上 10% 的问题”，还有另外 90% 的问题亟待解决，而这些问题分布的领域从图 8 中可见一斑：节点、API、Container runtime、网络、存储、跨域集群联邦、复杂应用管理是需求最多、挑战最大的领域。

图 8. 新功能需求个数按照 SIG 领域的分布图【5】除此以外，如何让全球数千名开发者高效协作也是巨大的挑战。虽然 Kubernetes 项目在组织架构和管理上分成了独立的数十个 SIG，但是主代码仓库并没有很好的实现解耦合，不同 SIG 所负责的代码还是同处一个 GitHub 代码仓库中。我们需要一个更加模块化的 Kubernetes 项目组织架构，让不同的 SIG、领域、子模块更加独立，减少或者明确相互的依赖关系。为了改变这一现状，新的 Kubernetes 架构也被提出，如图 9 所示。最后，尽管 Kubernetes 已然从 2016 年开始变成了技术领域 - 尤其是云计算领域 - 最潮流的技术，它的真正统治性落地还需要时间和不懈的努力。如图 10 所示，根据 Datadog 统计，还有超过 50% 的容器用户并没有采用容器管理工具（包括 Kubernetes），而又根据另外 RightScale 的报道，若整合公有云和私有云市场来看，目前使用最多的管理平台是 AWS 公有云 ECS。因此，Kubernetes 要实现其容器管理霸主地位仍然任重道远。

图 9：新的模块化的 Kubernetes 架构【6】

图 10. 容器用户同时使用容器管理工具的比例

Kubernetes 四岁时

回顾了历史，审视了今日，我们再抛开繁琐的技术和项目细节，大胆畅想下 Kubernetes 四岁时的模样。想象空间很大，细化的功能很多，而笔者只想对比 Google 内部的集群管理系统，为 Kubernetes 畅想两个大的方向：

从容器管理到集群管理

如今我们都在谈论 Data Center Operating System (DCOS) 或集群管理，并往往容易将“集群管理”与 Kubernetes（或者 Mesos、Swarm）划等号。然而以 Google 为例，其内部的集群管理是一个完整的生态，而 Borg（常说的 Kubernetes 的 Google 内部版）则是这个生态中的成员之一。具体来说，Borg 也好，Kubernetes 也好，更多的是容器管理／应用管理／服务管理；而一个完整的集群管理系统，或是 DCOS，则还涉及到节点管理、硬件管理、SLA 管理、网络管理、安全管理、运维管理等众多功能组件。

作为两岁的 Kubernetes，从问世之初专注于容器服务管理成绩斐然，而我们真正要实现如 Google 一样纯粹的容器化数据中心（没有且不需要 IaaS、PaaS 的分层），则需要围绕 Kubernetes 建立一个完整的集群管理体系。笔者认为依据现在 CNCF 和 Kubernetes 的定位，并随着企业对于 Kubernetes 使用深度的增加，在 Kubernetes 四岁之际，会布局成一个完善的容器化集群管理生态体系。

从自动化到智能化

Kubernetes 通过其 Declarative（声明式）设计模式和 Control loop 控制闭环实现了众多功能的自动化操作，例如 Pod 的生死控制、Replica 数量的伸缩控制等。然而，在人工智能盛行的今日，“自动化”与“智能化”之间还存在着鸿沟，Kubernetes 当前的自动化程度也并没有完全消除用户学习和使用 Kubernetes 的门槛。例如 Kubernetes 最经典的 Declarative 设计模式虽然相比 Imperative（祈使式）的设计模式有了很大进步，但是用户仍然需要按照规则和语法预先将应用的配置表示出来，而选择什么样的配置仍需要大量的人工经验和试错。Kubernetes 还提供了很多配置选项，仍需要用户去凭借经验或试错进行合理的配置。
此外，Google 内部使用的 Borg 真正做到了“调度一切任务”，不论是无状态微服务应用，还是大数据、深度学习业务，都通过 Borg 平台统一的管理；而大数据和深度学习业务也正是利用了 Borg 提供的敏捷分布式计算，极大地提升了其自身的性能。我们期待在 Kubernetes 四岁时，它能成长得更智能，并用自身的算力做更智能的事情。

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/4HykNCGsypx7Y9zK2Qniuw

创作场景

从风口浪尖到十字路口，写在 Kubernetes 两周年之际