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/roadmap/cloudnative
