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 做了大量增强；
 

• Pod：Pod内支持readiness和liveness探针；支持进程隔离和volume共享的多容器Pod；Pod支持原生configmap和sercret；Pod支持emptyDir；支持对Pod进行资源配额等；但是像优雅删除、Termination message、Privileged Containers、HugePages、Pod驱逐策略等部分特性还未在1.14版本提供；
• Service：支持服务环境变量提供DNS解析；支持NodePort、ClusterIP、LoadBalancer、Headless service；暂不支持Pod的hostnetwork模式；
• 常规 Workload controller：RS、deployment、statefulset、daemonset、job、cronjob均支持windows容器；
• 除此之外，支持Pod和container维度的metrics、HPA、“kubectl exec”、调度抢占、resource quotas、CNI 网络支持等多种特性让windows workload更加云原生；由于windows的特殊兼容性，目前 host OS的版本必须和容器镜像OS版本一致，1.14版本支持win server 2019；未来版本中会考虑使用Hyper-V隔离机制来解决版本兼容性问题。

而伴随着  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，也意味着用户必须自己承担一些潜在的风险，这包括：

• 目前社区的开源方案无法动态创建卷
• 调度器需要由额外的调度逻辑工作，以确保调度的节点可以分配出足够的磁盘容量
• 容错性差，如果pod正在运行的宿主机宕机或者磁盘发生异常，那么它的持久化卷里的信息可能丢失

第一个问题，可以通过比如阿里云的 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 着重在以下几个方面，提升用户体验，加强对日常运维能力的支持。

• 之前 kubectl cp 操作每次只能 copy 一个文件，没办法使用通配符拷贝一批文件，非常不方便。在1.14中，蚂蚁金服的工程师提交了一个拷贝操作的通配符功能，方便对容器中的文件进行操作。

  • 参见：#72641

• 以往，用户通常无法方便的知道自己被管理员通过 RBAC 配置的权限到底有哪些。而从v1.14开始，用户可以通过 kubectl auth can-i --list --namespace=ns1  来查看自己在 ns1 这个namespace下可以访问哪些资源 （比如Pod，Service等），并有哪些操作的权限（比如Get，List，Patch，Delete等）了。

  • 参见：#64820

• Kubernetes 用户需要删除的API 资源，往往分散在多个namespace中，删除非常不方便。在v1.14新版本中，用户终于可以借助于 kubectl delete xxx --all-namespaces  来进行统一的删除操作了（这里 XXX 可以是Pod，Services，Deployment，自定义的CRD等等），并且还可以配合 -l 和 --field-selector 可以更精确地删除满足特定条件的资源。

  • 参见：#73716

稳定性进一步提升

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

• 在做Pod驱逐时，会优先尝试使用优雅删除模式，而不是暴力删除etcd内的Pod数据。这个修复能够使被驱逐的 Pod更加优雅的退出。

  • 参见：#72730

• Kubelet要重建Pod的容器时，如果旧容器是unknown状态，现在Kubelet会首先尝试Stop容器。这避免了一个 Pod的同一个容器申明会有多个实例同时运行的风险。

  • 参见：#73802

• 在大规模集群中，节点因为个别Pod使用了大量磁盘 IO，可能会导致节点频繁的在Ready/NotReady状态之间变化。这种状态会引起大规模的、不可预期的 Pod Eviction，导致线上故障。蚂蚁金服的工程师针对 Docker 环境下的这个问题提交了修复，建议大家也排查一下其它运行时的集群里是否有同样的问题。

  • 参见：#74389

• 当 Kubelet在压力较大情况下，可能会发生 Kubelet 的Pod 生命周期事件消费频次弱于事件产生频次，导致负责这个事件的 Channel 被占满，这种情况持续一段时间后会直接导致Kubelet 死锁。阿里巴巴的工程师针对修这个问题提交了修复。

  • 参见：#72709

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

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

• kubectl 在实现中会顺序遍历 APIServer暴露出的全部资源的Group/Version/Kind，直到查找到需要处理的资源。这种遍历方式导致了用户在大规模集群下使用 kubectl 的性能体验受到很大影响。在v1.14版本中，kubectl的顺序遍历行为终于改为了并行，极大地提升了kubectl的使用体验（经过测试，性能指标提升了10倍以上）。

  • 参见： #73345

• 在 1.14 中，APIServer 里的一个重要变更，是对单次 PATCH 请求内容里的操作个数做出了限制，不能超过10000个，否则就不处理此请求。这样做的目的，是防止 APIServer 因为处理海量的甚至是恶意PATCH 请求导致整个集群瘫痪。这也其实也是社区的 CVE-2019-1002100 主要的修复方法。

  • 参见：#74000

• Kubernetes 的 Aggregated API允许 k8s 的开发人员编写一个自定义服务，并把这个服务注册到k8s的 API 里面像原生 API 一样使用。在这个情况下，APIServer 需要将用户自定义 API Spec 与原生的 API Spec 归并起来，这是一个非常消耗CPU 的性能痛点。而在v1.14中，社区大大优化了这个操作的速率，极大地提升了APIServer 归并 Spec 的性能（提升了不止十倍）。

  • 参见：#71223

原文链接
本文为云栖社区原创内容，未经允许不得转载。