Kubernetes 已足够成熟?详细解读 1.15 新版本的多项关键特性

2019-09-10 15:58:31 采集侠

作者 | 华为云原生团队 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 已足够成熟?详细解读 1.15 新版本的多项关键特性

从新特性数量上看,Kubernetes 过去一个版本发布的特性数量并无明显趋势性变化。由于特性颗粒度的差异,每个版本发布的新特性数量存在小幅波动,属于正常现象。

看特性成熟度分布,Alpha 特性比例依旧可观  

Kubernetes 已足够成熟?详细解读 1.15 新版本的多项关键特性

对比分析过去几个版本的特性成熟度,不难发现 Alpha 新特性的占比稳定在 20%~40% 之间。按照社区惯例,当一项全新的功能被添加时,会在特性说明中打上 Alpha 标记。持续稳定甚至小幅上涨的 Alpha 特性占比说明社区仍然在大量开发全新的特性,而不是满足于既有功能的加固。

Kubernetes 重点特性解读

经过分析 Kubernetes 近几个版本的变化,我们发现特性主要集中在 Storage、Node、API-Machinery、Network、Scheduling 等 SIG,而这些 SIG 大都致力于可护展性增强,以便于下游用户在享受稳定核心的同时,轻松扩展定制自己的插件。

Kubernetes 已足够成熟?详细解读 1.15 新版本的多项关键特性

从最新发布的 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 应用程序都应该在可预见的将来迁移到结构模式。

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 对象的默认值带来的额外开发消耗。

Admission Webhook 重新调用(Reinvocation)与增强

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)。

Node SIG 提供监控插件框架用于异构硬件监控  

新版本很好的解决了异构硬件设备监控难题,现在不需要修改 Kubelet 代码就可以实现各种指标(如 GPU、显存利用率等)监控。

新版本通过新的监控插件框架将 Kubelet 与设备监控处理逻辑解耦,很好的解决了以往 Kubelet 代码管理和 K8s 集群运维之间的痛点。

Kubernetes 已足够成熟?详细解读 1.15 新版本的多项关键特性

由图可见本框架主要包含 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 加强调度器扩展定制能力