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

摘要： K8s 1.14 发布了，Release Note那么长，咱们该从何读起？

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

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

文中相关连接一览

Release Note ：
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#kubernetes-v114-release-notes
Support for Windows Nodes is Graduating to Stable (#116 )：
https://github.com/kubernetes/enhancements/issues/116

Durable Local Storage Management is Now GA (#121)：
https://github.com/kubernetes/enhancements/issues/121#issuecomment-457396290

Pod Priority and Preemption in Kubernetes (#564) ：
https://github.com/kubernetes/enhancements/issues/564

Pod Ready++ (#580) ：
https://github.com/kubernetes/enhancements/issues/580
Added Kustomize as a subcommand in kubectl (#73033, @Liujingfang1)：
https://github.com/kubernetes/kubernetes/pull/73033
https://github.com/Liujingfang1

用户友好度：
72641：https://github.com/kubernetes/kubernetes/pull/72641
64820：https://github.com/kubernetes/kubernetes/pull/64820
73716：https://github.com/kubernetes/kubernetes/pull/73716

稳定性：
72730：https://github.com/kubernetes/kubernetes/pull/72730
73802：https://github.com/kubernetes/kubernetes/pull/73802
74389：https://github.com/kubernetes/kubernetes/pull/74389
72709：https://github.com/kubernetes/kubernetes/pull/72709

大规模场景下的性能提高与优化：
73345：https://github.com/kubernetes/kubernetes/pull/73345
74000：https://github.com/kubernetes/kubernetes/pull/74000
71223：https://github.com/kubernetes/kubernetes/pull/71223

阿里云和CNCF联合开发推出的免费公开课，讲解以Kubernetes主体的云原生技术知识。一线技术专家精心打造，期待各位的学习反馈。 更多课程信息能够一步：官宣|《CNCF x Alibaba 云原生技术公开课》即将重磅上线

---

本文做者：木环

阅读原文

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