雪花新闻

寻找 K8s 1.14 Release 里的“蚌中之珠”

本文由张磊、心贵、临石、徙远、衷源、浔鸣等同学联合撰写。

Kubernetes 1.14.0 Release 已经于3月25日正式发布。相信你也已经注意到，相比于1.13 和 1.12 版本，这次发布包含的重要变更非常多，其对应的 Release Note 的篇幅长度也创下了“新高”。

面对这样一份“海量信息”的 Release Note，我们该如何从这份文档里进行高效的信息过滤和挖掘，帮助团队更精准、快速的梳理出这次发布最主要的技术脉络呢？

在本篇文章中，我们将 1.14 的Release Note 按照主题进行了重新归纳和梳理，按照类别对重要变更进行了技术剖析和讨论。希望这种“分类解读”的方式，能够帮助大家更好的理解 1.14 这个发布的核心内容。

Windows Node 正式生产可用

随着1.14的发布，Kubernetes 对windows节点的生产级支持无疑是一个重要的里程碑。具体来说，1.14 版本针对 Windows 做了大量增强；

而伴随着 Windows 容器的生态正在慢慢壮大，能够在生产级别支持 Windows 节点的容器服务开始见诸各大云厂商。阿里云容器服务（ACK）近期已经推出了 Windows Container 的支持，提供了linux/windows应用混合部署的统一管理能力。

参见：Support for Windows Nodes is Graduating to Stable (#116 )

本地持久化数据卷（Local PV） 正式可用

长期以来，能够让 Kubernetes 直接用宿主机的本地存储设备（比如：本地 SSD 硬盘）来提供持久化数据卷（即：Local PV 功能），一直是社区里非常强烈的一个诉求。这个原因很容易理解：相对于远程存储（网络存储），Local PV 在时延性、易用性、稳定性和费用上具有独特的优势，尤其是对于相关特性比较敏感的应用，如数据库应用和搜索引擎应用来说，有着重要的意义。

而在 1.14 中，Local PV 终于正式宣布 GA，为云上的持久化存储选择增加了一种重要的的可能。

不过，必须要明确的是， 选择使用 Local PV，也意味着用户必须自己承担一些潜在的风险，这包括：

第一个问题，可以通过比如阿里云的 local-volume-provisioner 实现本地 SSD Nvme实例自动创建数据卷来解决，但对于容错性和健壮性的问题，就是比较棘手的了。

参见：Durable Local Storage Management is Now GA (#121)

Pod 优先级与抢占机制稳定可用

Kubernetes 里的任务优先级（priority）和抢占机制（preemption）的目的十分明确：保证高优先级的任务可以在需要的时候通过抢占低优先级任务的方式得到运行。

这其中，优先级定义了一个Pod在集群中的重要程度，这个重要程度体现且仅体现在两个地方：（1）高优先级的Pod在调度阶段更容易被优先调度（K8s采用队列调度模型），注意这里并不保证高优先级Pod永远被优先调度，实际影响调度顺序的因素有很多；（2）在集群整体负载较高时，如果出现高优先级Pod无法被调度的情况（集群中没有满足条件的Node供Pod运行），K8s会启动抢占机制，通过抢占已经运行的低优先级的Pod的方式，让高优先级的Pod可以运行起来。抢占机制便是在这里引入的。

抢占机制指当调度器发现某个Pod（如Pod-A）无法在集群中找到合适的节点部署时（所有节点Predicates全部失败），会试图通过删除一些优先级低于Pod-A的Pod来“腾出空间”部署Pod-A，这样Pod-A就可以被调度了。这样一个“看似简单”的需求在分布式环境中实施起来有很多细节，例如：如何决定删除哪个节点的哪些Pod、如何保证为Pod-A腾出的空间不被其它Pod占用、如何保证Pod-A不被饿死（Starvation）、如何处理有亲和性需求的Pod调度约束、是否需要支持跨节点Preemption以支持某些特定的约束（例如某Failure Domain的反亲和约束）等等。这些内容，可以参见：Pod Priority and Preemption in Kubernetes (#564)

你一定要知道什么是 Pod Ready++

在 1.14 版本之前，Kubernetes 判断一个Pod是否Ready，就是检查这个Pod的容器是否全部正常运行。但是这里有个问题，那就是容器或者说里面的主进程Ready，并不一定意味着这个应用副本就一定是就绪的。为了确认Pod确实可以正常可用，我们希望给它增加一些外部指标（比如，该 Pod 需要的 Service，DNS，存储等服务全部就绪），来反应这个Pod是否“真正”Ready。

这个特性，就是1.14 里一个叫做“Pod Readiness Gates”、也叫做 Pod Ready ++ 的特性。它为pod的“Ready 状态” 提供了一个非常强大的扩展点。需要注意的是，用户需要编写一个外部控制器（Controller）来为这个Pod Readiness Gates 字段对应的指标设置值。

参见：Pod Ready++ (#580)

Kubernetes 原生应用管理能力

1.14之后，Kubernetes 项目本身开始具备了原生的应用管理能力，这其中最重要的一个功能，就是 Kustomize。

Kustomize 允许用户从一个基础 YAML 文件，通过 overlay 的方式生成最终部署应用所需的 YAML 文件，而不是像 Helm 那样通过字符串替换的方式来直接修改基础 YAML 文件（模板）。这样，在一个用户通过 overlay 生成新的 YAML 文件的同时，其他用户可以完全不受影响的使用任何一个基础 YAML 或者某一层生成出来的 YAML 。这使得每一个用户，都可以通过 fork/modify/rebase 这样 Git 风格的流程来管理海量的 YAML 文件。这种 PATCH 的思想跟 Docker 镜像是非常类似的，它既规避了“字符串替换”对 YAML 文件的入侵，也不需要用户学习蹩脚的 DSL 语法（比如 Lua）。

在1.14之后，Kustomize 已经成为了 kubectl 的一个内置命令。不难看到，Kubernetes 社区正在探索一种 Helm 之外的、更加 Kubernetes 原生的应用管理方法。具体效果如何，我们不妨拭目以待。

参见：Added Kustomize as a subcommand in kubectl (#73033, @Liujingfang1)

用户友好度进一步提升

随着大家对Kubernetes越来越熟悉，对kubectl依赖也越来越强烈，需求也越来越多样化。而在 1.14 中，kubectl 着重在以下几个方面，提升用户体验，加强对日常运维能力的支持。

稳定性进一步提升

和之前每个版本一样，Kubernetes 的新版本发布对稳定性和可靠性增强的关注一直是重中之重，下面我们列举出一些值得注意的修复和升级。

大规模场景下的性能提升与优化

在 Kubernetes 的主干功能日趋稳定之后，社区已经开始更多的关注大规模场景下 Kubernetes 项目会暴露出来的各种各样的问题。在v1.14中，Kubernetes 社区从面向最终用户的角度做出了很多优化，比如：

文中相关链接一览

用户友好度：

稳定性：

大规模场景下的性能提升与优化：

阿里云和CNCF联合开发推出的免费公开课，讲解以Kubernetes主体的云原生技术知识。一线技术专家精心打造，期待各位的学习反馈。 《CNCF x Alibaba 云原生技术公开课》即将重磅上线，敬请期待。

相关文章