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

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

今天，阿里云高级技术专家张磊将从 Kubernetes 1.14 这个承前启后的版本聊起，一窥技术社区的演进方向。

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

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

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 项目对应用以及应用管理的定义也开始清晰了起来，我们可以用如下一幅示意图来简单描述：