2019年6月20日，Kubernetes重磅发布了1.15版本，不管你是Kubernetes用户，还是IT从业者都不能错过这个版本。
1.15版本主要围绕可扩展性展开，北向API接口方面API Machinery SIG致力于催熟CRD以提升API可扩展性，南向插件集成方面，Storage SIG 和Node SIG则分别对CSI和设备监控插件可扩展性进行了优化。另外Kubeadm对HA集群配置也达到Beta可用，并发优化了证书管理相关功能。
本文我们先从宏观上了解一下近期版本的变化趋势，然后再开始1.15版本的重点特性解读。
Kubernetes持续热情高涨
在展开解读1.15的关键新特性之前，让我们先来回顾下社区过去几个版本的特性发布情况。值得一提的是：无论从新特性数量，还是特性的成熟度分布来看，Kubernetes依旧保持着相当的活力，社区开发者用实际行动回应了业界盛传“Kubernetes已经足够成熟，项目正在变得无聊(Boring)”的说法。
各版本新特性数量基本持平
从新特性数量上看，Kubernetes过去一个版本发布的特性数量并无明显趋势性变化。由于特性颗粒度的差异，每个版本发布的新特性数量存在小幅波动，属于正常现象。
看特性成熟度分布，Alpha特性比例依旧可观
对比分析过去几个版本的特性成熟度，不难发现Alpha新特性的占比稳定在20%~40%之间。按照社区惯例，当一项全新的功能被添加时，会在特性说明中打上Alpha标记。持续稳定甚至小幅上涨的Alpha特性占比说明社区仍然在大量开发全新的特性，而不是满足于既有功能的加固。
Kubernetes重点特性解读
经过分析Kubernetes近几个版本的变化，我们发现特性主要集中在Storage、Node、API-Machinery、Network、Scheduling等SIG，而这些SIG大都致力于可护展性增强，以便于下游用户在享受稳定核心的同时，轻松扩展定制自己的插件。
从最新发布的1.15版本来看，以下几个变化需要重点关注。
API聚焦可扩展性增强
Kubernetes API的扩展能力主要由CRD（Custom Resource Definition）以及Admission Webhook提供。1.15 版本在这两方面都有重要的更新。
CRD，大步迈向GA
CRD的新开发主题一直都围绕着数据一致性以及提供更加接近Kubernetes原生API的能力。用户不应该感知到到底是以CR（Custom Resource）还是以原生的资源对象形式与Kube APIServer进行交互。社区目前正迈着大步，计划将在接下来的某个版本中将CRD以及Admission Webhook GA（升级为稳定版本）。
朝着这个方向，社区重新思考了基于OpenAPI的CRD验证模式，从1.15开始，根据结构模式（Structural Schema）的限制检查每个字段。这基本保证了能够像原生的API对象一样提供完整的CR校验能力。在v1beta1 API中，非结构模式（non-Structural Schema）仍然保持工作状态。但是任何严格的CRD应用程序都应该在可预见的将来迁移到结构模式。
- CRD多版本之间通过Webhook转换特性[Beta]
从1.15版本开始，支持运行时不同版本之间的转换，长期目标是让用户像原生API资源一样使用CRD的多版本。这一特性是CRD在GA道路上一步重大的飞跃。
- CRD OpenAPI发布特性[Beta]
CRD的OpenAPI发布特性将会在Kubernetes 1.15中Beta，当然只是针对结构模式的CRD。次特性对于用户自定义API，提供了与Kubernetes原生API一样的文档说明。
- CRD 未知字段裁剪（Prune）[Beta]
CRD未知字段裁剪特性是针对发送到Kube APIServer的对象中未知的字段进行移除，并且不会持久化存储。用户可以通过在CRD对象设置spec.preserveUnknownFields: false 使用此未知字段裁剪特性。此特性对于数据一致性及安全都有一定的帮助。
- CRD 默认值设置 [Alpha]
Kubernetes 1.15 结构模式的CRD默认值设置特性作为Alpha特性可用。用户可以通过OpenAPI校验模式的default关键词指定默认值。避免了用户原来只能通过Admission Webhook方式设置CRD对象的默认值带来的额外开发消耗。
Admission Webhook重新调用（Reinvocation）与增强
- Mutating 和 Validating Admission Webhook已经成为扩展API的主流选择。在1.15以前，所有的webhook只会按照字母表顺序调用一次，这样就会导致一个问题一个更早的webhook不能应对后面的webhook的更新，这可能会导致未知的问题，例如前面的webhook设置某个pod的启动参数，而随后的webhook将其更改或者移除了。
1.15 版本引入Reinvocation特性允许用户通过MutatingWebhook 配置reinvocationPolicy: IfNeeded 指定Mutating Webhook重新调用。
-
Admission Webhook引入了objectSelector来控制通过标签选择特定的对象进行准入控制。
-
允许Admission Webhook Server使用任意的端口（不限制只能是443）。
Node SIG提供监控插件框架用于异构硬件监控
新版本很好的解决了异构硬件设备监控难题，现在不需要修改Kubelet代码就可以实现各种指标（如GPU、显存利用率等）监控。
新版本通过新的监控插件框架将Kubelet与设备监控处理逻辑解耦，很好的解决了以往Kubelet代码管理和K8s集群运维之间的痛点。
由图可见本框架主要包含Kubelet和Device Monitoring Agent两大部分：
1、 Kubelet
Kubelet增加了一个GRPC服务，监听在/var/lib/kubelet/pod-resources/kubelet.sock，提供pod resources的list查询接口。
2、 Device Monitoring Agent
a. Device Monitoring Agent提供metric接口对外提供设备监控指标查询功能。
b. Device Monitoring Agent向Kubelet的上述GRPC服务发送List请求，取得所有pod resources(包含节点上所有pod的所有container分配的device类型和device id)。
c. Device Monitoring Agent根据设备类型过滤获取容器的设备ID，通过设备驱动接口获取容器使用的设备的监控指标，并把二者关联到container 、pod上。
新的框架将会带来诸多便利：
1、 设备监控功能与Kubelet接口解耦
a. Kubelet不需要提供设备的监控指标；
b. 设备的新增监控指标不需要升级Kubelet，而是更新设备监控代理版本即可；
c. 新增设备不需要升级Kubelet，而是增加部署设备监控代理的DaemonSet即可；
d. 未解耦前，Kubelet会检测所有支持的设备是否存在，即使节点并没有安装该设备。
2、 设备供应商负责发布和维护设备监控代理，设备供应商在如何运行和监控它们方面拥有深厚的专业知识，可以提供权威的设备监控代理。
3、 K8s集群的管理员只需要安装需要的设备监控代理即可。
Scheduling SIG发布Scheduler Framework加强调度器扩展定制能力
Scheduler Framework 终于在1.15迎来了Alpha版本。Scheduler Framework 最早在2018 年初提出，主要是为了解决日益增加的定制化调度需求。Scheduler Framework在原有的 Priority/Predicates 接口的基础上增加了 reserve, pre-bind 等十几个接口用于相应前处理及后处理。在 1.15 中，Scheduler Framework实现 QueueSort, Prebind, Postbind, Reserve, Unreserve和Permit接口，这些接口为后继更多的调度策略提供了基础，比如 gang-scheduling。
然而，出于设计上的延续性考虑，目前 Scheduler Framework 仍以Pod为单位进行调度，而计算类（离线）任务调度往往需要考虑工作负载中相关的Pod按组进行调度，例如 faire-share。现在的Scheduler Framework还不能有效的解决。所幸针对这一原因，社区已经有相应的项目在Kubernetes上支持计算类（离线）任务，例如 Volcano (http://github.com/volcano-sh/volcano)。
Storage SIG持续改善CSI
在Kubernetes v1.15中，SIG Storage继续工作，以支持将in-tree插件迁移到CSI（Container Storage Interface，容器存储接口）。SIG Storage致力于使CSI具有与in-tree功能相同的特性，包括调整大小、内联卷等功能。SIG Storage在CSI中引入了一些新的Alpha功能，这些功能在Kubernetes存储子系统中还不存在，如卷克隆（volume cloning）等。
卷克隆允许用户在提供新卷时将另一个PVC指定为“数据源（Data Source）”。如果底层存储系统支持此功能并在其CSI驱动程序中实现“CLONE_VOLUME”功能，则新卷将成为源卷的克隆。
Kubeadm的HA集群配置达到Beta可用
作为社区内置安装工具的Kubeadm，何时支持部署HA集群一直是个热门话题。在本次发布的1.15版本中，Kubeadm对HA集群配置的支持终于达到beta——用户可以直接使用init和join两个Kubeadm命令来部署HA集群。乐于折腾的用户可以参考社区文档在小范围生产环境中使用。
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
Kubeadm的证书管理功能在1.15中也得到了改进，用户可以在证书失效前通过kubeadm alpha certs renew平滑地刷新它们。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-certs-renew
Kubeadm的configuration(API)在1.15版本中引入了v1beta2版本，主要是增加了一组证书加解密密钥的配置字段CertificateKey，便于用户在使用Kubeadm部署HA控制面时，直接使用被加密保存在集群Secret中的证书。此外，用户可以通过 kubeadm alpha certs certificate-key 命令来直接生成这对密钥。
关于跟多Kubeadm当前相关的Alpha特性，可以查看相关官方文档：https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha
随着Kubernetes越来越多地被用在多云、混合云部署场景，集群生命周期管理的标准化一直是众人期待的一大方向。自v1.13版本GA之后，Kubeadm的改动主要聚焦在优化使用体验上。而集群生命周期整体流程的打通，特别是实现跨平台的集群管理，配合日渐活跃的ComponentConfig以及Cluster API两个新项目，相信很快会有实质性的进展。
小结
经过5年的发展，Kubernetes核心的基本功能已相对稳定，具备大规模生产可用水平。但是客户需求往往是多种多样的，社区从很早就意识到这个问题，因而提供了各种接口（CRD、CRI、CSI、CNI等），希望在保持Kubernetes独立的条件下，尽量满足用户差异化的需求，这从1.15发布的主要特性也可以看出来。
华为云原生团队坚定的认为，Kubernetes社区未来会继续着重围绕可扩展性、易用性以及稳定性规划发展路标，丰富平台面向各种应用场景的功能接口，以稳定、健壮、高可扩展的平台推动云原生应用生态百花齐放。