kubernetes 1.15 有哪些让人眼前一亮的新特性？

原文连接： kubernetes 1.15 有哪些让人眼前一亮的新特性？

2019 年 6 月 20 日，Kubernetes 重磅发布了 1.15 版本，不过笔者忙到如今才有空认真来看一下到底更新了哪些东西。这一版本更新主要是针对稳定性的持续改善和可扩展性，仔细把 25 个新增或改动的功能看完后，发现许多之前的小痛点都在这个版本中解决了，本文对每一个特性的介绍格式以下：

#492 : 前面是 GitHub issue 编号，后面是具体的特性

进度 : 表示该特性目前处于什么阶段，如 Alpha，Beta，Stable

特性分类 : 表示该特性属于哪一个分类，如 API，CLI，Network 等。

这里是具体的特性介绍，例如改进了什么，为何要这么作，有的特性还会有简单的使用范例。

1. 核心功能

#1024 NodeLocal DNSCache

进度：迈向 Beta

特性分类：Network

NodeLocal DNSCache 经过在集群节点上以 Deamonset 的方式运行 DNS 缓存代理来提升集群的 DNS 性能，从而能够避免使用 iptables DNAT 规则和链接跟踪。若是本地 DNS 缓存代理在内存中找不到相应的 DNS 记录，就会向 kube-dns 服务发起查询请求（默认状况下以 cluster.local 为后缀）。

想了解该特性的更多细节能够阅读 Kubernetes Enhancement Proposal (KEP) 文档中的设计说明。

#383 Redesign event API

进度：Alpha

特性分类：Scalability

这项工做主要有两个目标：

1. 减小 Events 对集群其他部分的性能影响；
2. 向 Event 对象添加更多的数据结构，这是使 Event 分析自动化的必要步骤，也是第一步。

目前 Event API 的主要问题是包含太多垃圾信息，致使其难以摄取和分析有效信息。除此以外还有数个性能问题，例如当集群出现问题时，Events 可能会使 API server 过载（例如常见的 crashloop）

关于该 issue 的讨论以及建议的解决方案和改进工做能够参考这里的设计提案。

#492 Admission webhook

进度：Beta

特性分类：API

Mutating 和 Validating Admission Webhook 已经成为扩展 API 的主流选择。在 1.15 之前，全部的 webhook 只会按照字母表顺序调用一次，这样就会致使一个问题：一个更早的 webhook 不能应对后面的 webhook 的更新，这可能会致使未知的问题，例如前面的 webhook 设置某个 pod 的启动参数，而随后的 webhook 将其更改或者移除了。

在 Kubernetes 1.15 中，容许 webhook 被重复调用，即便是对同一对象的修改。若是想启用该特性，必需要确保你引入的任何 admission webhook 都是幂等操做，也就是说，同一个对象被执行任意屡次操做与执行一次操做产生的效果相同。

#624 Scheduling framework

进度：Alpha

特性分类：Scheduling

该特性为 Kubernetes 1.15 的调度器设计了一个新的可插拔结构，主要是为了解决日益增长的定制化调度需求。Scheduler Framework 在原有的 Priority/Predicates 接口的基础上增长了 reserve, pre-bind 等十几个接口。

下图显示了 Pod 在新的 Scheduling framework 中的调度过程：

关于该特性的更多信息请查阅官方设计文档。

#606 Support 3rd party device monitoring plugins

进度：迈向 Beta

特性分类：Node

该特性容许 Kubelet 将容器 binding 信息暴露给第三方监控插件，这样系统管理员就可使用第三方的设备监控代理来监控自定义资源分配给 Pod 的使用率（例如，每一个 Pod 的 GPU 使用率）。

未解耦前，Kubelet 会检测全部支持的设备是否存在，即便节点并无安装该设备。

使用新的框架以后，Kubelet 会经过 /var/lib/kubelet/pod-resources/kubelet.sock 提供一个新的 GRPC 服务，该服务会把容器和设备所分配到资源相关的信息都暴露出来。

#757 Pid limiting

进度：迈向 Beta

特性分类：Node

Pid 是 Linux 系统中很重要的资源，系统很容易在 CPU 或内存的使用量还没达到上限以前，进程数量就达到了上限。所以管理员必须得想办法确保 Pod 不会把系统的 Pid 用完，进而形成其余重要的服务没法运行（例如，container runtime，kubelet 等）。

新的特性容许修改 Kubelet 配置来限制每一个 Pod 的 Pid 数量。在 Node 层面限制 Pid 的功能如今能够直接使用，再也不须要经过 feature gate 的参数 SupportNodePidsLimit=true 显示设置。

Kubernetes 官方博客有对此特性的详细介绍。

#902 Add non-preempting option to PriorityClasses

进度：Alpha

特性分类：Scheduling

Kubernetes 1.15 在 PriorityClass 中添加 PreemptionPolicy 字段做为 Alpha 特性。

PreemptionPolicy 字段的默认值为 PreemptLowerPriority，表示容许该优先级的 Pod 抢占低优先级的 Pod（这是默认的抢占行为）。若是 PreemptionPolicy 字段的值为 Never，则该 Pod 会被放置到调度队列中，而且放置的位置排在低优先级 Pod 的前面，可是不能抢占其余的 Pod。

以数据科学领域为例：用户提交了一个 job，他但愿此 job 的优先级比其余 job 高，可是不但愿由于抢占 Pod 而致使目前的任务被搁置。

#917 Add go module support to k8s.io/kubernetes

进度：Stable

特性分类：Architecture

自从 Kubernetes 开源以来，一直使用 godep 来 vendoring 全部依赖库。随着 Go 生态系统愈来愈成熟，vendoring 已经变成主流，而 godep 已经再也不维护了，因而 Kubernetes 一开始使用 godep 的定制版，这期间还有一些其余的 vendoring 工具（例如 glide 和 dep）也跟着出现，而如今 Go 的依赖库管理终于能够以 go module 的形式直接添加到 Go 中。

Go 从 1.13 已经默认开启 go module，而且移除了 $GOPATH 模式。为了支持这个改动，Kubernetes 1.15 版本调整了好几个组件的代码以使用 go module。

#956 Add Watch bookmarks support

进度：Alpha

特性分类：API

一个 Kubernetes 集群只会保留一段时间内的变动历史记录，好比使用 etcd3 的集群默认会保留 5 分钟的变动历史记录。而为 Kubernetes Watch 事件添加一个书签（bookmark）能够想象成多了一个检测点，全部 Client 请求的对象若是符合预先想查找的资源版本（resourceVersion）就会被这个书签给筛选出来。

例如：新增一个 Watch 的请求去查找全部资源版本为 X 的事件，这时 API server 知道该 Watch 请求对其余资源版本的事件没有兴趣，就会使用书签来略过全部其余事件，只将特定的事件发送给客户端，从而避免增长 API server 的负载。

#962 Execution hooks

进度：Alpha

特性分类：storage

ExecutionHook 提供了一种通用机制，让用户能够在容器中触发想要执行的 hook 命令，例如：

• 应用程序备份
• 升级
• 数据库迁移
• 从新加载配置文件
• 重启容器

hook 的定义中包含两条重要信息：

1. 须要执行什么命令
2. 在哪执行命令（经过 Pod Selector）

下面提供一个简单示例：

想了解该特性的更多细节能够阅读 Kubernetes Enhancement Proposal (KEP) 文档中的设计说明。

#981 PDB support for custom resources with scale subresource

进度：迈向 Beta

特性分类：Apps

Pod Disruption Budget (PDB) 是一种 Kubernetes API，用于限制在同一时间自愿中断的应用程序（如 Deployment 或 ReplicaSet）中宕机的 Pod 的数量。PDB 能够经过指定最小可用数量或最大不可用数量的 Pod 来自定义中断预算。

例如，对于一个无状态的前端应用：

• 要求：服务能力不能减小超过 10%
• 解决方案：使用一个包含 minAvailable 90% 值的 PDB

使用 PDB 后，就能够容许管理员在不下降服务的可用性和性能的前提下操做 Kubernetes 的工做负载。

2. 自定义资源

#95 CustomResourceDefinitions

进度：Beta

特性分类：API

该特性没有什么实质性的功能，只是把在 Kubernetes 1.15 版本中跟 CRD 相关的修复和改进进行了分组：

• Structural schema using OpenAPI
• CRD pruning
• CRD defaulting
• Webhook conversion moved to beta
• Publishing the CRD OpenAPI schema

#692 Publish CRD OpenAPI schema

进度：迈向 Beta

特性分类：API

该特性容许开发者使用 OpenAPI v3 schema 来定义 Custom Resource Definition (CRD) ，以便开启 Server 端对 CustomResources (CR) 的验证。

发布使用 OpenAPI 规范的 CRD 即可以开启客户端验证（例如 kubectl create 和 kubectl apply 时），也能够对规范进行描述（例如 kubectl explain），Client 也会由于 CRs 而自动生成，因此开发者能够轻易使用任何支持的编程语言来和 API 进行交互。

使用 OpenAPI 规范有助于使 CRD 开发者和 Kubernetes API 的发展方向更加清晰，文档格式更加简洁精炼。

#575 Defaulting and pruning for custom resources

进度：Alpha

特性分类：API

下面的这两个特性主要是为了使与 CRD 相关的 JSON 处理更加方便。

Pruning : CRD 传统的存储方式是以 JSON 格式存储在 ETCD 中。如今若是它是以 OpenAPI v3 的规范来定义的，而且 preserveUnknownFields 的值为 false，未被定义的字段在建立或更新时便会被删除。

Defaulting : 此特性在 Kubernetes 1.15 版本处于 Alpha 阶段，默认处于关闭状态，能够经过 feature gate 的参数 CustomResourceDefaulting 来开启。Defaulting 和 Pruning 同样，在一开始就要将规范定好，不符合规范的就会被去掉。

#598 Webhook conversion for custom resources

进度：迈向 Beta

特性分类：API

不一样的 CRD 版本能够有不一样的规范，如今你能够在操做中处理不一样版本之间的转换，而且实现了版本转换的 webhook。这个 webhook 会在下面几种状况下被调用：

• 请求的自定义资源版本与原来储存的版本不一致
• 自定义资源在 Watch 时建立了某一版本，但在下次修改时发现跟存储的版本不一致
• 使用 PUT 请求自定义资源时，发现请求的版本与存储的版本不一致

这里有一个实现自定义资源之间相互转换的 webhook server 的示例，你们能够做为参考。

3. 配置管理

#515 Kubectl get and describe should work well with extensions

进度：迈向 Stable

特性分类：Cli

目前已经可使用 kubectl get 和 describe 来让第三方 API 扩展和 CRD 提供自定义格式化输出。该特性使输出能够打印到服务器端，从而实现了更好的扩展性，而且让 Kubectl 和扩展的实现细节进行解耦。

想了解关于该特性的更多详细信息，能够查阅相关设计文档。

#970 Kubeadm: New v1beta2 config format

进度：迈向 Beta

特性分类：Cluster lifecycle

随着时间的推移，在 kubeadm 的配置文件中配置 Kubernetes 集群建立时的选项数量已经大大增长，而后 CLI 参数的数量仍是没有变化，因此致使使用配置文件来建立集群是目前惟一一个比较符合使用者需求方法。

该特性的目标是从新设计配置的存储方式来改善当前版本遇到的问题，并放弃了使用包含全部选项的单个配置文件，使用子结构来为高可用集群提供更好的支持。

#357 Ability to create dynamic HA clusters with kubeadm

进度：迈向 Beta

特性分类：Cluster lifecycle

Kubernetes 能够经过多个控制平面来提供高可用性。kubeadm 工具如今能够用来建立高可用集群，有两种方式：

• etcd 与 Control Plane 节点 (Master) 共存
• etcd 与 Control Plane 节点 (Master) 是分开的

这个版本的 kubeadm 将会自动复制其中须要的证书，减小人为干预的需求，目前的作法是使用一个暂时加密的秘钥来确保证书在传输过程当中的安全性，更多细节能够参考 KEP 文档。

4. 云供应商

#423 Support AWS network load balancer

进度：迈向 Beta

特性分类：AWS

在 Kubernetes 1.15 中能够经过 annotations 的方式，在 Service 的种类是 LoadBalancer 时，直接请求创建 AWS NLB：

与经典的弹性负载均衡器不一样，Network Load Balancers (NLBs) 会把客户端的 IP 直接传递给节点。AWS NLB 其实从 1.9 的时候就已经处于 Alpha 阶段，如今代码和 API 都已经相对稳定，因此准备迁移到 Beta 阶段。

#980 Finalizer protection for service LoadBalancers

进度：Alpha

特性分类：Network

默认状况下，云服务商提供的 Load Balancer 资源，应该要在 Kubernetes Service 被删除的时候也跟着一块儿被删除才对，然而在各类极端的案例中，能够发如今删除关联的 Kubernetes Service 后，Load Balancer 资源却被孤立在一旁没有被清除掉，而引入 Finalizer 就是为了预防这种状况的发生。

若是你的集群已经开启了和云服务商的整合，Finalizer 将会附加到任何包含 type=LoadBalancer 字段的 Kubernetes Service，当这类 Service 即将被删除时，Finalizer 会先将 Serivce 的删除动做给冻结住，直接确保 Load Balancer 资源被清除后，才会将 Service 真正删除。

5. 存储

#625 In-tree storage plugin to CSI Driver Migration

进度：Alpha

特性分类：Storage

存储插件最初都在 Kubernetes 的基础代码库中，增长了代码维护的复杂性，也阻碍了其扩展性。所以该特性的目标是将全部存储相关的代码移出来变成可加装的插件形式，并经过 Container Storage Interface（CSI）来和 Kubernetes 进行交互。如此一来即可下降开发的成本，并使其更加模块化，可扩展性更强，让不一样版本的存储插件与 Kubernetes 之间有更好的兼容性。想了解该特性的最新进展能够参考这里。

#989 Extend allowed PVC DataSources

进度：Alpha

特性分类：Storage

该特性可让使用者复制现有的 PV。复制和备份其实仍是不太同样的，复制会产生一个新的且内容和原来彻底同样的存储卷。复制既有的 PV 会消耗用户的存储卷配额，而且会遵循和其余存储卷建立时同样的建立和检查流程，复制出来的 PV 也和普通的 PV 同样具备相同的生命周期和工做流程。使用该特性时，须要注意如下事项：

• 复制功能的 VolumePVCDataSource 参数仅适用于 CSI Driver。
• 复制功能仅适用于动态存储卷配置。
• 到底能不能使用复制功能还要取决于 CSI Driver 有没有实现存储卷的复制功能。

#1029 Quotas for ephemeral storage

进度：Alpha

特性分类：Node

目前限制临时存储卷使用量的机制是按期遍历查看每一个临时存储卷的大小，这种作法很慢，具备很高的延迟。该特性中提出的机制利用文件系统的 Project Quota 来监控资源消耗程度，而后再决定要不要限制其使用量。但愿可以实现如下目标：

• 经过以非强制方式使用 Project Quota 来收集有关临时卷的使用状况，进而改善监控的性能。
• 检测出在 Pod 中已经被删除掉，可是由于文件还处于打开的状态下而被隐藏起来的存储卷。

如此一来即可以经过 Project Quota 来限制每个存储卷的使用量。

#531 Add support for online resizing of PVs

进度：迈向 Beta

特性分类：Storage

该特性让使用者能够经过修改 PVC 来在线扩展存储卷使用到的文件系统，而不须要重启使用到该存储卷的 PVC。在线扩展 PVC 的功能目前还处于 Beta 阶段，且默认是开启的，你也能够经过 feature gate 参数 ExpandInUsePersistentVolumes 显示开启。

文件系统的扩展行为会在如下状况下被触发：

• 当 Pod 启动时
• 当 Pod 正在运行且底层的文件系统支持在线扩展（例如，XFS，ext3 或 ext4）

关于该特性的更多消息信息请参考 Kubernetes 官方文档。

#559 Provide environment variables expansion in sub path mount

进度：迈向 Beta

特性分类：Storage

目前 Kubernetes 对于挂载节点本地存储卷的支持有一个限制：若是有大于等于两个 Pod 运行在同一个节点上，同时把相同的 log 文件名称写入相同的存储卷会致使这些 Pod 发生冲突。

使用 subPath 是个不错的选择，但 subPath 目前只能写死，没法提供灵活性。以前的解决办法是建立一个带有挂载路径的软连接的 Sidecar 容器。

为了更方便地解决这个问题，如今提出了向 subPath 中添加环境变量来缓和这个限制，参考如下示例：

也能够写成这种格式：

6. 总结

本文除了告知读者 Kubernetes 1.15 有什么新特性以外，更重要的在于提供了一个机会去了解 Kubernetes 这么庞大的系统在跟第三方整合或是某个组件的性能遇到瓶颈时该怎么解决，为咱们之后设计架构时提供了参考依据。

7. 参考资料

• https://sysdig.com/blog/whats-new-kubernetes-1-15/

---