你正在查看的文档所针对的是 Kubernetes 版本: v1.29
Kubernetes v1.29 版本的文档已不再维护。你现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。
Kubernetes v1.30 初探
作者: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko
译者: Paco Xu (DaoCloud)
快速预览:Kubernetes v1.30 中令人兴奋的变化
新年新版本,v1.30 发布周期已过半,我们将迎来一系列有趣且令人兴奋的增强功能。 从全新的 alpha 特性,到已有的特性升级为稳定版,再到期待已久的改进,这个版本对每个人都有值得关注的内容!
为了让你在正式发布之前对其有所了解,下面给出我们在这个周期中最为期待的增强功能的预览!
Kubernetes v1.30 的主要变化
动态资源分配(DRA)的结构化参数 (KEP-4381)
动态资源分配(DRA) 在 Kubernetes v1.26 中作为 alpha 特性添加。 它定义了一种替代传统设备插件 device plugin API 的方式,用于请求访问第三方资源。 在设计上,动态资源分配(DRA)使用的资源参数对于核心 Kubernetes 完全不透明。 这种方法对于集群自动缩放器(CA)或任何需要为一组 Pod 做决策的高级控制器(例如作业调度器)都会带来问题。 这一设计无法模拟在不同时间分配或释放请求的效果。 只有第三方 DRA 驱动程序才拥有信息来做到这一点。
动态资源分配(DRA)的结构化参数是对原始实现的扩展,它通过构建一个框架来支持增加请求参数的透明度来解决这个问题。 驱动程序不再需要自己处理所有请求参数的语义,而是可以使用 Kubernetes 预定义的特定“结构化模型”来管理和描述资源。 这一设计允许了解这个“结构化规范”的组件做出关于这些资源的决策,而不再将它们外包给某些第三方控制器。 例如,调度器可以在不与动态资源分配(DRA)驱动程序反复通信的前提下快速完成分配请求。 这个版本的工作重点是定义一个框架来支持不同的“结构化模型”,并实现“命名资源”模型。 此模型允许列出各个资源实例,同时,与传统的设备插件 API 相比,模型增加了通过属性逐一选择实例的能力。
节点交换内存 SWAP 支持 (KEP-2400)
在 Kubernetes v1.30 中,Linux 节点上的交换内存支持机制有了重大改进,其重点是提高系统的稳定性。
以前的 Kubernetes 版本默认情况下禁用了 NodeSwap
特性门控。当门控被启用时,UnlimitedSwap
行为被作为默认行为。
为了提高稳定性,UnlimitedSwap
行为(可能会影响节点的稳定性)将在 v1.30 中被移除。
更新后的 Linux 节点上的交换内存支持仍然是 beta 级别,并且默认情况下开启。
然而,节点默认行为是使用 NoSwap
(而不是 UnlimitedSwap
)模式。
在 NoSwap
模式下,kubelet 支持在启用了磁盘交换空间的节点上运行,但 Pod 不会使用页面文件(pagefile)。
你仍然需要为 kubelet 设置 --fail-swap-on=false
才能让 kubelet 在该节点上运行。
特性的另一个重大变化是针对另一种模式:LimitedSwap
。
在 LimitedSwap
模式下,kubelet 会实际使用节点上的页面文件,并允许 Pod 的一些虚拟内存被换页出去。
容器(及其父 Pod)访问交换内存空间不可超出其内存限制,但系统的确可以使用可用的交换空间。
Kubernetes 的 SIG Node 小组还将根据最终用户、贡献者和更广泛的 Kubernetes 社区的反馈更新文档, 以帮助你了解如何使用经过修订的实现。
阅读之前的博客文章或交换内存管理文档以获取有关 Kubernetes 中 Linux 节点交换支持的更多详细信息。
支持 Pod 运行在用户命名空间 (KEP-127)
用户命名空间 是一个仅在 Linux 上可用的特性,它更好地隔离 Pod, 以防止或减轻几个高/严重级别的 CVE,包括 2024 年 1 月发布的 CVE-2024-21626。 在 Kubernetes 1.30 中,对用户命名空间的支持正在迁移到 beta,并且现在支持带有和不带有卷的 Pod,自定义 UID/GID 范围等等!
结构化鉴权配置(KEP-3221)
对结构化鉴权配置的支持正在晋级到 Beta 版本,并将默认启用。 这个特性支持创建具有明确参数定义的多个 Webhook 所构成的鉴权链;这些 Webhook 按特定顺序验证请求, 并允许进行细粒度的控制,例如在失败时明确拒绝。 配置文件方法甚至允许你指定 CEL 规则,以在将请求分派到 Webhook 之前对其进行预过滤,帮助你防止不必要的调用。 当配置文件被修改时,API 服务器还会自动重新加载鉴权链。
你必须使用 --authorization-config
命令行参数指定鉴权配置的路径。
如果你想继续使用命令行标志而不是配置文件,命令行方式没有变化。
要访问新的 Webhook 功能,例如多 Webhook 支持、失败策略和预过滤规则,需要切换到将选项放在 --authorization-config
文件中。
从 Kubernetes 1.30 开始,配置文件格式约定是 beta 级别的,只需要指定 --authorization-config
,因为特性门控默认启用。
鉴权文档
中提供了一个包含所有可能值的示例配置。
有关更多详细信息,请阅读鉴权文档。
基于容器资源指标的 Pod 自动扩缩容 (KEP-1610)
基于 ContainerResource
指标的 Pod 水平自动扩缩容将在 v1.30 中升级为稳定版。
HorizontalPodAutoscaler 的这一新行为允许你根据各个容器的资源使用情况而不是 Pod 的聚合资源使用情况来配置自动伸缩。
有关更多详细信息,请参阅我们的先前文章,
或阅读容器资源指标。
在准入控制中使用 CEL (KEP-3488)
Kubernetes 为准入控制集成了 Common Expression Language (CEL) 。 这一集成引入了一种更动态、表达能力更强的方式来判定准入请求。 这个特性允许通过 Kubernetes API 直接定义和执行复杂的、细粒度的策略,同时增强了安全性和治理能力,而不会影响性能或灵活性。
将 CEL 引入到 Kubernetes 的准入控制后,集群管理员就具有了制定复杂规则的能力, 这些规则可以根据集群的期望状态和策略来评估 API 请求的内容,而无需使用基于 Webhook 的访问控制器。 这种控制水平对于维护集群操作的完整性、安全性和效率至关重要,使 Kubernetes 环境更加健壮,更适应各种用例和需求。 有关使用 CEL 进行准入控制的更多信息,请参阅 API 文档中的 ValidatingAdmissionPolicy。
我们希望你和我们一样对这个版本的发布感到兴奋。请在未来几周内密切关注官方发布博客,以了解其他亮点!