Kubernetes 已足够成熟？详细解读 1.15 新版本的多项关键特性
1.15 版本主要围绕可扩展性展开，北向 API 接口方面 API Machinery SIG 致力于催熟 CRD 以提升 API 可扩展性，南向插件集成方面，Storage SIG 和 Node SIG 则分别对 CSI 和设备监控插件可扩展性进行了优化。另外 Kubeadm 对 HA 集群配置也达到 Beta 可用，并发优化了证书管理相关功能。
本文我们先从宏观上了解一下近期版本的变化趋势，然后再开始 1.15 版本的重点特性解读。
在展开解读 1.15 的关键新特性之前，让我们先来回顾下社区过去几个版本的特性发布情况。值得一提的是：无论从新特性数量，还是特性的成熟度分布来看，Kubernetes 依旧保持着相当的活力，社区开发者用实际行动回应了业界盛传“Kubernetes 已经足够成熟，项目正在变得无聊 (Boring)”的说法。
对比分析过去几个版本的特性成熟度，不难发现 Alpha 新特性的占比稳定在 20%~40% 之间。按照社区惯例，当一项全新的功能被添加时，会在特性说明中打上 Alpha 标记。持续稳定甚至小幅上涨的 Alpha 特性占比说明社区仍然在大量开发全新的特性，而不是满足于既有功能的加固。
经过分析 Kubernetes 近几个版本的变化，我们发现特性主要集中在 Storage、Node、API-Machinery、Network、Scheduling 等 SIG，而这些 SIG 大都致力于可护展性增强，以便于下游用户在享受稳定核心的同时，轻松扩展定制自己的插件。
从最新发布的 1.15 版本来看，以下几个变化需要重点关注。
Kubernetes API 的扩展能力主要由 CRD（Custom Resource Definition）以及 Admission Webhook 提供。1.15 版本在这两方面都有重要的更新。
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 应用程序都应该在可预见的将来迁移到结构模式。
1) CRD 多版本之间通过 Webhook 转换特性 [Beta]
从 1.15 版本开始，支持运行时不同版本之间的转换，长期目标是让用户像原生 API 资源一样使用 CRD 的多版本。这一特性是 CRD 在 GA 道路上一步重大的飞跃。
2) CRD OpenAPI 发布特性 [Beta]
CRD 的 OpenAPI 发布特性将会在 Kubernetes 1.15 中 Beta，当然只是针对结构模式的 CRD。次特性对于用户自定义 API，提供了与 Kubernetes 原生 API 一样的文档说明。
3) CRD 未知字段裁剪（Prune）[Beta]
CRD 未知字段裁剪特性是针对发送到 Kube APIServer 的对象中未知的字段进行移除，并且不会持久化存储。用户可以通过在 CRD 对象设置 spec.preserveUnknownFields: false 使用此未知字段裁剪特性。此特性对于数据一致性及安全都有一定的帮助。
4) CRD 默认值设置 [Alpha]
Kubernetes 1.15 结构模式的 CRD 默认值设置特性作为 Alpha 特性可用。用户可以通过 OpenAPI 校验模式的 default 关键词指定默认值。避免了用户原来只能通过 Admission Webhook 方式设置 CRD 对象的默认值带来的额外开发消耗。
1) Mutating 和 Validating Admission Webhook 已经成为扩展 API 的主流选择。在 1.15 以前，所有的 webhook 只会按照字母表顺序调用一次，这样就会导致一个问题一个更早的 webhook 不能应对后面的 webhook 的更新，这可能会导致未知的问题，例如前面的 webhook 设置某个 pod 的启动参数，而随后的 webhook 将其更改或者移除了。
1.15 版本引入 Reinvocation 特性允许用户通过 MutatingWebhook 配置 reinvocationPolicy: IfNeeded 指定 Mutating Webhook 重新调用。
2) Admission Webhook 引入了 objectSelector 来控制通过标签选择特定的对象进行准入控制。
3)允许 Admission Webhook Server 使用任意的端口（不限制只能是 443）。
新版本很好的解决了异构硬件设备监控难题，现在不需要修改 Kubelet 代码就可以实现各种指标（如 GPU、显存利用率等）监控。
新版本通过新的监控插件框架将 Kubelet 与设备监控处理逻辑解耦，很好的解决了以往 Kubelet 代码管理和 K8s 集群运维之间的痛点。
由图可见本框架主要包含 Kubelet 和 Device Monitoring Agent 两大部分：
Kubelet 增加了一个 GRPC 服务，监听在 /var/lib/kubelet/pod-resources/kubelet.sock，提供 pod resources 的 list 查询接口。
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 集群的管理员只需要安装需要的设备监控代理即可。
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)。
在 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 集群一直是个热门话题。在本次发布的 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 社区未来会继续着重围绕可扩展性、易用性以及稳定性规划发展路标，丰富平台面向各种应用场景的功能接口，以稳定、健壮、高可扩展的平台推动云原生应用生态百花齐放。
活动推荐
当今是云原生与物联网的时代，产业进入高速发展阶段，对技术架构、操作系统以及交付模式都提出更高的要求。ArchSummit 全球架构师峰会深圳站特别开设免费技术专场，探讨在云原生时代下，从架构、软件技术、支撑平台、组织运作等方面如何进行系统性建设，以及云化 DevOps 工具链架构及设计细节和建设过程中的心得体会，阅读原文或识别下图二维码报名参会。
相关内容
微信扫码咨询专知VIP会员