从Kubernetes1.14的发布，我们可以看到技术社区??的演进方向2019年这个技术社区的发展情况如何？今天，阿里云资深技术专家张磊将从Kubernetes1.14这个连接过去和未来的版本入手，一窥技术社区的演进历程。Kubernetes1.14正式发布已经有一段时间了，相信大家已经从不同的渠道看到了各种版本的解读。不过，比起代码发布，即将迎来5岁生日的Kubernetes项目接下来将如何进化，其实是一个引人入胜的话题。作为一个日趋成熟的开源生态系统，Kubernetes项目每三个月一次的正式发布，其实是这个快速成长的技术社区在不断演进过程中留下的坚实足迹。Windows生态成为Kubernetes项目的一等公民自该项目发布以来，Kubernetes对Windows生态的支持就被提上日程。不过，作为一个纯Linux技术栈支持的基础设施开源项目，Windows节点和Windows容器支持确实有了长足的进步，也是Kubernetes项目在1.6版本之后的插件化和扩展性逐渐成熟之后才逐渐成熟的.走上正轨。同样容易理解的是，Windows系统与目前主流的容器技术栈有着本质的区别，这就要求Kubernetes项目必须能够提供更高层次的抽象和可扩展性来支持两种完全不同的技术栈，同时需要一些KubernetesCNI、CSI等生态完成对接。这部分工作的复杂性和工作量也是导致WindowsNode的生产可用性从1.13推迟到1.14的主要原因。在本次1.14版本中，Windows节点上已经支持了Kubernetes的大部分核心能力，如Pod、Service、应用编排、CNI网络等。此外，自定义监控指标、水平扩展、抢占、优先级调度等诸多高级功能也在Windows上实现。目前不能支持的功能基本都是暂时无法在Windows上实现的语义，比如HostNetwork等Linux内核特有的资源和权限定义方式。可以看出，Kubernetes这次发布的对Windows节点和Windows容器的支持，相比之前都有了很大的提升，完成度非常高。它确实配得上承诺的“GA”发布术语。阿里云容器服务（ACK）等国内外公有云提供商也在近期推出了对WindowsContainers的支持，为Linux/Windows应用混合部署提供统一管理能力，再次印证了此次发布的可用性。不难看出，公有云提供商（比如此次WindowsGA背后的微软云团队）作为CNCF社区的主要推动者之一，其实一直在整个云原生技术生态中发挥着巨大的作用，逐渐有助于将Windows支持等实际企业用户需求带入完全以Linux技术堆栈为中心的快速增长的基础设施项目。在未来的发展中，像这样来自公有云提供商的投入，将继续对Kubernetes项目的发展起到至关重要的作用，也将成为更多企业用户学习云原生技术生态的平台。从中受益的重要途径。这将继续成为Kubernetes项目与其他基础设施开源项目之间的根本区别。Kubernetes原生应用管理能力初现长期以来，Kubernetes应用管理都是由Helm或上层PaaS等第三方项目完成。不过在1.14之后，Kubernetes项目本身开始具备了原生的应用管理能力，其中最重要的功能之一就是Kustomize。Kustomize允许用户以一个应用描述文件（YAML文件）为基础（BaseYAML），然后通过Overlay生成应用最终部署所需要的描述文件，而不是像Helm那样只提供应用描述文件模板，然后用替换字符（Templating）的方式来定制。同时，其他用户可以不受影响地使用任何BaseYAML或任何层生成的YAML。这允许每个用户通过fork/modify/rebase等Git风格的过程来管理海量的应用程序描述文件。这个PATCH的思路和Docker镜像很像。可以避免“字符替换”对应用描述文件的侵扰，不需要用户学习额外的DSL语法（如Lua）。更重要的是，上面PATCH的思路完全符合Kubernetes项目强调的声明式API，整个用户体验和KubernetesAPI本身完全一致，没有割裂感（大家可以想想为什么PATCH是声明式的API.本质）。在1.14版本中，Kustomize功能成为了kubectl的内置命令，这使得用户可以使用Kubernetes的声明式API直接在云端管理、修改和部署海量应用。而且kubectl本身的插件机制在1.14也有了很大的改进，使得kubectl结合各种客户端插件有潜力成为一个应用管理工具。在这样的演进路线下，Kubernetes项目的应用和应用管理的定义变得更加清晰。我们可以用下面的示意图来简单描述一下：在Kubernetes这个原生的应用管理系统中，应用描述文件（YAML文件）处于核心位置。一个应用描述文件实际上是多个KubernetesAPI对象的组合，它们共同定义了部署这个应用所需的资源编排和服务编排内容。一旦这样的描述文件提交给Kubernetes，它就会使用controller模式来保证整个集群的状态与描述文件的定义完全一致。这些描述文件的来源来自于上层框架或用户的输出。更重要的是，对应用程序的所有操作都应该通过声明式API对文件的Create、Patch和Delete操作完成，然后触发Kubernetes控制器模型执行预定义的编排动作。不难看出，在这个模型中，Helm和Kustomize实际上定义了两种不同的应用描述文件输出路径和用户体验，也代表了与KubernetesAPI的两种不同程度的耦合和抽象：一个自包含系统，一个融入了Kubernetes的设计理念。1.14发布后，Kubernetes社区目前正在探索的应用管理系统效果如何，我们不妨拭目以待。大规模场景下的性能优化逐渐提上日程很多熟悉Kubernetes项目的参与者可能都知道，在过去的一段时间里，Kubernetes社区并没有高度重视大规模场景下的性能优化。这里的道理也比较好理解。在一个基础设施开源项目发展的早期阶段，往往比支持更大的集群更重要的是扩大生态和完善功能。但是在Kubernetes的骨干功能越来越稳定之后，社区肯定会开始更加关注Kubernetes项目在大规模场景下会暴露出的各种问题。生态成功的基础，而是通过Kubernetes的路径，让更多的沃尔玛、星巴克、国内外的科技独角兽成为云原生技术的受益者，进而成为公有云上的大规模用户。聚焦发展方向。当然，作为一个天然“集成”的基础设施项目，Kubernetes性能提升的主要方向必须优先考虑与上层用户关系最密切的API层和客户端使用场景。当然，这也与Kubernetes项目的架构息息相关：声明式API的设计围绕着以etcd为核心的配置管理机制，使得Kubernetes项目天生就是一个强调API层、轻视调度的分布式系统.这也意味着当需要管理的配置信息（即：API对象）数量巨大时，这一层也是最容易暴露性能问题的区域。因此，在Kubernetesv1.14中，社区首先从终端用户的角度做了很多优化，比如：kubectl对API对象的遍历行为进行了大量的并行化工作。这个看似很小的修改，为kubectl用户在大规模场景下带来了显着的性能提升体验，但却意义非凡。当然，最重要的工作还是发生在APIServer本身的性能优化上。例如，Kubernetes的聚合API允许开发人员编写自定义服务并在k8sAPI中注册该服务，以便像本地API一样使用。但在这种情况下，APIServer会将用户自定义的APISpec与原来的APISpec合并，这是一个非常耗CPU的性能痛点。在v1.14中，社区对这个操作的效率进行了精心优化，最终将APIServer合并到Spec的性能提升了十多倍。此外，Kubernetes项目性能提升的另一个重要方向是优化和完善etcd与APIServer的连接路径。作为Kubernetes项目的配置中心，也依赖于外部数据。etcd每次提交操作的数据量和间隔大小，以及每次连接的请求和响应周期，在大规模场景下可能会对最终Kubernetes项目的性能产生影响。.阿里巴巴技术团队一直在etcd项目中不断进行性能调优和改进，并在etcd的新版本中陆续发布。这些不是Kubernetes1.14版本的一部分，但值得我们关注。可扩展性和项目稳定性持续提升除了上述在本次发布后逐渐成为核心领域外，Kubernetes项目以往一直比较关注几个核心方向，比如可扩展性和项目稳定性的提升.等待仍然是Kubernetes项目持续演进的重要主题。所以在Kubernetes1.14中，会有很多像“PodReady++”这样的重要变化，将已经成熟的系统特性进一步重构为可扩展的接口。PodReady++正式发布后，Kubernetes用户只需要编写一个外部控制器（Controller）就可以轻松定制一个应用从创建到最终可用（Ready）的标准是什么，而不用被迫遵守Kubernetes项目已经定义方法。这种能力也是基础设施开源项目“民主化”的重要体现。综上所述，Kubernetes1.14的发布在这个日趋成熟和稳定的开源基础设施项目的发展过程中起到了承前启后的重要作用。所以我们会看到Kubernetes社区在几个过去不太受关注的领域继续发力，甚至可能在某些领域进一步改变整个云原生社区的发展方向。这种在日趋稳定的发展过程中不时流露出来的技术革新，也是这个社区持续火爆的关键。纵观目前的云计算生态，国外越来越多的大型企业用户，如Snapchat、Twitter，已经开始将自己的整个技术栈直接迁移到基于Kubernetes的公有云服务上，这恰恰印证了其本质意义。关键词“云原生”理解为：未来的云时代，软件开发、测试、发布、运维的完整生命周期都将基于云。所谓“云原生”，其实就是通过一系列的技术手段，为开发者编制一个框架，让软件在云端自然生长和交付，从而实现云端价值的最大化。技术蓝图。更多云原生技术的原理与实践，请点击文末“阅读原文”关注阿里云与CNCF官方联合开发的免费公开课《CNCF x Alibaba 云原生技术公开课》：业界的领先的技术专家为您解析云原生技术的核心原理和实现，期待您的学习和反馈。参考：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看看作者更多好文章
