从Kubernetes 1.14 发布，看技术社区演进方向

Kubernetes 1.14 正式发布已通过去了一段时间，相信你已经从不一样渠道看过了各类版本的解读。

不过，相比于代码 Release，立刻就要迎来5周岁生日的Kubernetes 项目接下来如何演进，其实也是一个让人着迷的话题。而做为一个日趋成熟的开源生态，Kubernetes 项目每三个月一次的正式发布，其实正是这个高速发展的技术社区不断向前演进的过程当中留下的扎实脚印。

而若是说以“不断提高插件能力和可扩展能力”的 “基础设施开源项目民主化”进程是Kubernetes在2017-2018年的核心主题的话，那么在2019年，这个技术社区的发展脉络又是怎样的呢？

本篇文章，咱们将从Kubernetes 1.14 这个承前启后的发布出发，一块儿来探索一下这个问题背后的技术本质。

Windows 生态成为 Kubernetes 项目的一等公民

Kubernetes 对 Windows 生态的支持，自从这个项目发布起就被提上了日程。不过，做为一个纯粹的 Linux 技术栈支撑的基础设施开源项目，Windows 节点以及 Windows 容器支持真正取得实质性进展，仍是要从Kubernetes 项目的插件和可扩展能力在1.6版本后逐渐成熟以后才慢慢步入了正轨。这也很容易理解，Windows 体系与目前主流容器技术栈有着本质性的差别，这就要求Kubernetes项目必须可以提供更高层次的抽象和可扩展能力以支持两种迥然不一样的技术栈，而且同现有的Kubernetes生态好比 CNI 和 CSI 完成对接。这部分工做的复杂度和工做量，也是 Windows Node的生产可用从1.13延期到1.14的主要缘由。

而在此次1.14的发布中，Kubernetes 的Pod，Service，应用编排，CNI 网络等绝大多数核心能力都已经在 Windows 节点上获得了支持。此外，包括自定义监控指标、水平扩展、抢占和优先级调度等不少进阶功能也都在 Windows 上得以实现。目前，尚不能被支持的功能基本上都是在 Windows 上暂时没法实现的语义好比 Host Network以及其它Linux 内核专属的资源和权限定义方式等。能够看到，Kubernetes 此次发布对 Windows节点和 Windows 容器的支持，较以前相比有了巨大提高，完成度很是高，确实对得起 “GA”这个具有承诺意味的发布用语。而国内外公有云提供商好比阿里云容器服务（ACK）也已经于近期已经推出了 Windows Container 的支持，提供了Linux/Windows应用混合部署的统一管理能力，再一次印证了此次发布的可用度。

不难看到，公有云提供商（好比本次Windows 支持GA背后的微软云团队）做为 CNCF社区的主要推进方之一，实际上一直在整个云原生技术生态中发挥着巨大的做用，逐步促成了将像 Windows 支持这样的实际企业用户诉求带给了一个高速发展的、彻底以 Linux 技术栈为核心的基础设施项目。而在将来的发展中，诸如此类的来自于公有云提供商的输入，将会继续在 Kubernetes 项目发展的过程当中扮演相当重要的角色，这也会成为更多的企业用户可以从云原生技术生态中获益的一个重要途径。这一点，将会继续成为 Kubernetes 项目与其余基础设施开源项目的最大不一样。

Kubernetes 原生的应用管理能力崭露头角

在长期一段时间里，Kubernetes 的应用管理都是由 Helm 这样的第三方项目或者上层 PaaS 来完成的。不过，在1.14以后，Kubernetes 项目自己开始具有了原生的应用管理能力，这其中最重要的一个功能，就是 Kustomize。

Kustomize 容许用户以一个应用描述文件 （YAML 文件）为基础（Base YAML），而后经过 Overlay 的方式生成最终部署应用所需的描述文件，而不是像 Helm 那样只提供应用描述文件模板，而后经过字符替换（Templating）的方式来进行定制化。

而与此同时，其余用户能够彻底不受影响的使用任何一个Base YAML 或者任何一层生成出来的 YAML 。这使得每个用户均可以经过相似fork/modify/rebase 这样 Git 风格的流程来管理海量的应用描述文件。这种 PATCH 的思想跟 Docker 镜像是很是类似的，它能够规避“字符替换”对应用描述文件的入侵，也不须要用户学习额外的 DSL 语法（好比 Lua）。

更为重要的是，上述PATCH 的思想，跟 Kubernetes 项目强调的声明式 API是彻底匹配的，整个使用体验跟 Kubernetes API 自己彻底一致，没有割裂感（你们能够思考一下为何 PATCH 才是声明式API 的精髓）。

在1.14发布中，Kustomize 功能已经成为了 kubectl 的一个内置命令，这使得用户使用 Kubernetes 的声明式 API来直接在云端管理、修改和部署海量的应用成为了可能。而且，kubectl 自己的插件机制也在1.14中获得了大量完善，使得 kubectl 结合各类客户端插件已经具有成为应用管理工具的潜在能力。而在这样的演进路线下，Kubernetes 项目对应用以及应用管理的定义也开始清晰了起来，咱们能够用以下一幅示意图来简单描述：

在这个 Kubernetes 原生的应用管理体系中，应用描述文件（YAML 文件）居于核心位置。一份应用描述文件，其实是多个 Kubernetes API 对象的组合，共同定义了这个部署这个应用所需的资源编排和服务编排内容。一旦这样一个描述文件提交给 Kubernetes ，那么接下来它就会经过控制器模式来保证整个集群里的状态与该描述文件的定义彻底一致。

这些描述文件的来源，则来自于上层框架或者用户的产出。更为重要的是，全部对应用的操做，都应该经过声明式 API 对该文件进行 Create、Patch 和 Delete 操做来完成，进而触发 Kubernetes 的控制器模型执行预约义的编排动做。

不难看到，在这个模型中，Helm和 Kustomize 其实定义了两种不一样的应用描述文件的产出路径和用户体验，也表明了两种同 Kubernetes API 不一样的耦合度和抽象程度：一个自成体系，一个则融入到了 Kubernetes的设计理念当中。在1.14发布以后，Kubernetes 社区当前正在探索的这种应用管理体系效果如何，咱们不妨拭目以待。

大规模场景下的性能优化工做逐渐提上日程

熟悉 Kubernetes 项目的不少参与者可能都知道，在过去一段时间，Kubernetes 社区对于大规模场景下的性能优化工做的优先级大多不会很是高。这里的缘由也比较容易理解，在一个基础设施开源项目发展的早期，扩大生态和完善功能相比于支持更大的集群来讲每每要更重要一些。

但在 Kubernetes 的主干功能日趋稳定以后，社区必定会开始更多的关注大规模场景下 Kubernetes 项目会暴露出来的各类各样的问题，这其实依然容易理解：中小规模的用户当然是整个项目取得生态成功的根本，可是经过 Kubernetes 这条路径让更多的沃尔玛、星巴克、国内外的技术独角兽们成为云原生技术的受益者，进而成为公有云上的规模性用户，必定是 Kubernetes 社区要重点考虑的发展方向。

固然，做为一个自然处于“被集成”位置的基础设施项目，Kubernetes 进行性能提高的主要方向，必定优先关注于与上层使用者关系最为紧密的 API 层以及客户端使用场景。固然，这也与 Kubernetes 项目的架构关系紧密：声明式API 的设计围绕着以 etcd 为核心的配置管理机制，使得 Kubernetes 项目天生就是一个重 API 层而轻调度的分布式系统。这也意味着当须要管理的配置信息（即：API 对象）数量巨大时，这一层也是最有可能的暴露出性能问题的领域。

因此，在Kubernetes v1.14中，社区首先从面向最终用户的角度作出了不少优化，好比：kubectl对 API 对象的遍历行为进行了大量的并行化工做。这种看似微小的修改在大规模场景下对kubectl使用者带来的性能提高体验，倒是很是显著的。

固然，最重要的工做，仍是发生在 APIServer 自己的性能优化上。好比，Kubernetes 的 Aggregated API容许开发人员编写一个自定义服务，并把这个服务注册到k8s的 API 里面像原生 API 同样使用。可是在这个状况下，APIServer 会将用户自定义 API Spec 与原生的 API Spec 归并起来，这是一个很是消耗CPU 的性能痛点。而在v1.14中，社区专门对这个操做的效率进行了细致的优化，最终极将APIServer 归并 Spec 的性能提高了十倍以上。

除此以外，Kubernetes 项目性能提高的另外一个重要方向，就是对 etcd 到 APIServer 之间的链接路径的优化和提高上。做为 Kubernetes 项目的配置中心，也是惟一的外部数据依赖，etcd每一次提交操做的数据量和间隔大小，每个链接的请求和响应周期，都有可能对最终Kubernetes 项目在大规模场景下的性能表现产生影响。阿里巴巴的技术团队在etcd 项目的中一直在持续进行性能调优与提高工做并已陆续发布在了 etcd 的最新版本当中。这些内容虽然不属于 Kubernetes 1.14 发布的一部分，但一样值得咱们关注。

可扩展能力和项目稳定性持续提高

除了上述几个领域在本次发布后逐步成为核心领域以外，Kubernetes 项目在过往一直比较重视的几个核心方向，好比，可扩展能力的提高，项目稳定性等，依然是 Kubernetes 项目继续演进的重要旋律。因此在Kubernetes 1.14中，才会出现不少像 “Pod Ready ++” 这样将本来已经成熟的系统特性进一步重构成为可扩展接口的重要变动。在Pod Ready ++ 正式发布后，Kubernetes 用户只须要本身编写一个外部控制器（Controller）就能够很是方便的自定义一个应用从建立到最终可用（Ready） 的标准究竟是什么，而不是被强迫遵照 Kubernetes 项目已有的定义方法。这种能力，一样是基础设施开源项目“民主化”的重要体现。

对于这些可扩展能力和项目稳定性提高技术细节的解读，推荐你关注 Kubernetes 1.14 发布技术解读文章来作进一步了解，并最终按照这些特性对本身所在组设置的重要程度来定制的升级计划。

总结

Kubernetes 1.14的发布，在这个日趋成熟稳定的项目开源基础设施项目的发展过程当中有着重要的承前启后的做用。因此咱们会看到，Kubernetes 社区正在几个以往并不太受关注的领域里开始持续发力，甚至有可能会进一步改变整个云原生社区在某些领域的发展方向。这种在日趋稳定的发展历程中不时透露出来的技术革新，也正是这个社区可以持续使人兴奋的关键所在

而放眼当前的云计算生态，国外愈来愈多的大规模企业级用户好比 Snapchat、Twitter等都已经开始了将本身的整套技术栈直接迁往以Kubernetes为基础的公有云服务上，这正好印证了“云原生”这个关键词的本质含义：在将来云的时代，软件的开发、测试、发布、运维等完整的生命周期，都会基于云来进行。而所谓的“云原生”，其实正在经过一系列技术手段，为广大开发者编制出了一幅可以让软件自然的生长在云上、交付在云上，从而最大程度地发挥出云的价值的技术蓝图。

更多关于云原生技术原理和实践的内容，欢迎关注阿里云和CNCF 官方联合开发的免费公开课《CNCF x Alibaba 云原生技术公开课》。业内一线技术大咖为你剖析云原生技术核心原理与落地实践，期待各位的学习与反馈： https://edu.aliyun.com/roadma...