Kubernetes v1.34: Of Wind & Will (O' WaW)

作者：Kubernetes v1.34 发布团队 |

编辑：Agustina Barbetta、Alejandro Josue Leon Bellido、Graziano Casto、Melony Qin、Dipesh Rawat

与之前的版本类似，Kubernetes v1.34 的发布引入了新的稳定、Beta 和 Alpha 功能。高质量版本的持续交付凸显了我们开发周期的实力以及社区的鼎力支持。

此版本包含 58 项增强功能。在这些增强功能中，23 项已进入稳定阶段，22 项进入 Beta 阶段，13 项进入 Alpha 阶段。

此版本中还有一些弃用和移除；请务必阅读相关内容。

这是一个由我们周围的风和我们内心的意志驱动的版本。

每个发布周期，我们都会继承一些我们无法真正控制的风——我们的工具、文档的状态以及项目的历史特性。有时这些风会使我们的帆鼓满，有时会把我们吹向一边，或者平息下来。

让 Kubernetes 不断前进的不是完美的风，而是我们的水手的意志，他们调整船帆，掌舵，规划航线并保持船只稳定。发布的成功不是因为条件总是理想的，而是因为构建它的人、发布它的人，以及让 Kubernetes 航行强劲的熊^、猫、狗、巫师和好奇心——无论风向如何。

本次发布的主题是 风之语，心之向 (O' WaW)，旨在致敬那些塑造我们的风，以及推动我们前进的意志。

^ 哦，你想知道为什么是熊吗？继续想吧！

重点更新

Kubernetes v1.34 包含许多新功能和改进。以下是发布团队希望重点介绍的一些更新！

稳定版：DRA 的核心功能达到 GA

动态资源分配 (DRA) 为选择、分配、共享和配置 GPU、TPU、NIC 和其他设备提供了更强大的方式。

自 v1.30 版本以来，DRA 一直基于使用对 Kubernetes 核心不透明的**结构化参数**来声明设备。此增强功能的灵感来自存储卷的动态供应。带有结构化参数的 DRA 依赖于一组支持的 API 类型：ResourceClaim、DeviceClass、ResourceClaimTemplate 和 ResourceSlice API 类型，这些类型位于 `resource.k8s.io` 下，同时通过新的 `resourceClaims` 字段扩展了 Pod 的 `.spec`。
`resource.k8s.io/v1` API 已进入稳定阶段，默认可用。

这项工作是作为由 WG Device Management 领导的 KEP #4381 的一部分完成的。

Beta 版：用于 `kubelet` 镜像凭证提供程序的投射 ServiceAccount 令牌

用于拉取私有容器镜像的 `kubelet` 凭证提供程序传统上依赖于存储在节点上或集群中的长期 Secret。这种方法增加了安全风险和管理开销，因为这些凭证不与特定工作负载绑定，也不会自动轮换。
为了解决这个问题，`kubelet` 现在可以请求短期、受众绑定的 ServiceAccount 令牌以向容器镜像库进行身份验证。这允许根据 Pod 自身的身份而不是节点级别的凭证来授权镜像拉取。
主要好处是显著提高了安全性。它消除了为镜像拉取使用长期 Secret 的需要，减少了攻击面，并为管理员和开发人员简化了凭证管理。

这项工作是作为由 SIG Auth 和 SIG Node 领导的 KEP #4412 的一部分完成的。

Alpha 版：支持 KYAML，一种 Kubernetes 的 YAML 方言

KYAML 旨在成为一个更安全、更少歧义的 YAML 子集，并且是专为 Kubernetes 设计的。无论你使用哪个版本的 Kubernetes，从 Kubernetes v1.34 开始，你都可以使用 KYAML 作为 kubectl 的新输出格式。

KYAML 解决了 YAML 和 JSON 的特定挑战。YAML 的重要空白需要仔细注意缩进和嵌套，而其可选的字符串引用可能导致意外的类型强制转换（例如：“挪威 Bug”）。同时，JSON 缺乏注释支持，并且对尾随逗号和带引号的键有严格要求。

你可以编写 KYAML 并将其作为输入传递给任何版本的 `kubectl`，因为所有 KYAML 文件也都是有效的 YAML。使用 `kubectl` v1.34，你还可以通过设置环境变量 `KUBECTL_KYAML=true` 请求 KYAML 输出（例如 kubectl get -o kyaml …）。如果你愿意，你仍然可以请求 JSON 或 YAML 格式的输出。

这项工作是作为由 SIG CLI 领导的 KEP #5295 的一部分完成的。

进入稳定阶段的功能

以下是 v1.34 发布后进入稳定阶段的一些改进。

延迟创建 Job 的替换 Pod

默认情况下，Job 控制器在 Pod 开始终止时立即创建替换 Pod，导致两个 Pod 同时运行。这可能导致在资源受限的集群中出现资源争用，替换 Pod 可能难以找到可用节点，直到原始 Pod 完全终止。这种情况还可能触发不必要的集群自动缩放器扩展。此外，一些机器学习框架，如 TensorFlow 和 JAX，要求每个索引只有一个 Pod 在运行，这使得同时执行 Pod 成为问题。此功能在 Job 中引入了 `.spec.podReplacementPolicy`。你可以选择仅在 Pod 完全终止时（具有 `.status.phase: Failed`）创建替换 Pod。要做到这一点，请设置 `.spec.podReplacementPolicy: Failed`。
该功能在 v1.28 中作为 Alpha 引入，在 v1.34 中进入稳定阶段。

这项工作是作为由 SIG Apps 领导的 KEP #3939 的一部分完成的。

从卷扩展失败中恢复

此功能允许用户取消底层存储提供程序不支持的卷扩展，并使用可能成功的较小值重试卷扩展。
该功能在 v1.23 中作为 Alpha 引入，在 v1.34 中进入稳定阶段。

这项工作是作为由 SIG Storage 领导的 KEP #1790 的一部分完成的。

用于卷修改的 VolumeAttributesClass

VolumeAttributesClass 在 v1.34 中进入稳定阶段。VolumeAttributesClass 是一个通用的、Kubernetes 原生的 API，用于修改卷参数，如已配置的 IO。它允许工作负载在线垂直扩展其卷，以平衡成本和性能，如果其提供程序支持的话。
与 Kubernetes 中所有新的卷功能一样，此 API 是通过容器存储接口 (CSI) 实现的。你的特定于提供程序的 CSI 驱动程序必须支持新的 ModifyVolume API，这是此功能的 CSI 端。

这项工作是作为由 SIG Storage 领导的 KEP #3751 的一部分完成的。

结构化身份验证配置

Kubernetes v1.29 引入了一种配置文件格式来管理 API 服务器客户端身份验证，从而摆脱了之前对大量命令行选项的依赖。AuthenticationConfiguration 类型允许管理员支持多个 JWT 身份验证器、CEL 表达式验证和动态重新加载。这一变化显著提高了集群身份验证设置的可管理性和可审计性，并在 v1.34 中进入稳定阶段。

这项工作是作为由 SIG Auth 领导的 KEP #3331 的一部分完成的。

基于选择器的更精细授权

Kubernetes 授权器，包括 webhook 授权器和内置节点授权器，现在可以根据传入请求中的字段和标签选择器做出授权决策。当你发送带有选择器的 **list**、**watch** 或 **deletecollection** 请求时，授权层现在可以根据这些额外的上下文评估访问权限。

例如，你可以编写一个授权策略，只允许列出绑定到特定 `.spec.nodeName` 的 Pod。客户端（可能是某个特定节点上的 kubelet）必须指定策略要求的字段选择器，否则请求将被禁止。这一变化使得设置最小权限规则成为可能，前提是客户端知道如何遵守你设置的限制。Kubernetes v1.34 现在在诸如每节点隔离或自定义多租户设置等环境中支持更精细的控制。

这项工作是作为由 SIG Auth 领导的 KEP #4601 的一部分完成的。

通过精细控制限制匿名请求

现在，你可以配置一个严格的端点列表，允许未经身份验证的请求，而不是完全启用或禁用匿名访问。这为依赖匿名访问健康或引导端点（如 `/healthz`、`/readyz` 或 `/livez`）的集群提供了一个更安全的替代方案。

通过此功能，可以避免因 RBAC 配置错误而授予匿名用户广泛访问权限的意外情况，而无需更改外部探针或引导工具。

这项工作是作为由 SIG Auth 领导的 KEP #4633 的一部分完成的。

通过插件特定的回调实现更高效的重新排队

现在，`kube-scheduler` 可以更准确地决定何时重试调度先前无法调度的 Pod。每个调度插件现在可以注册回调函数，告诉调度器传入的集群事件是否可能使被拒绝的 Pod 再次变得可调度。

这减少了不必要的重试并提高了整体调度吞吐量——尤其是在使用动态资源分配的集群中。该功能还允许某些插件在安全的情况下跳过通常的退避延迟，从而在特定情况下加快调度速度。

这项工作是作为由 SIG Scheduling 领导的 KEP #4247 的一部分完成的。

有序的命名空间删除

半随机的资源删除顺序可能会产生安全漏洞或意外行为，例如在关联的 NetworkPolicy 被删除后 Pod 仍然存在。
此改进为 Kubernetes 命名空间引入了更结构化的删除过程，以确保安全和确定性的资源移除。通过强制执行尊重逻辑和安全依赖关系的结构化删除序列，此方法确保在其他资源之前移除 Pod。
该功能在 Kubernetes v1.33 中引入，并在 v1.34 中进入稳定阶段。此次升级通过减轻非确定性删除带来的风险（包括 CVE-2024-7598 中描述的漏洞）提高了安全性和可靠性。

这项工作是作为由 SIG API Machinery 领导的 KEP #5080 的一部分完成的。

流式 **list** 响应

在 Kubernetes 中处理大型 **list** 响应以前是一个重大的可扩展性挑战。当客户端请求大量资源列表时，例如数千个 Pod 或自定义资源，API 服务器需要在发送前将整个对象集合序列化到一个大的内存缓冲区中。这个过程产生了巨大的内存压力，可能导致性能下降，影响集群的整体稳定性。
为了解决这个限制，引入了一种用于集合（列表响应）的流式编码机制。对于 JSON 和 Kubernetes Protobuf 响应格式，该流式机制会自动激活，并且相关的功能门已达到稳定。这种方法的主要好处是避免了 API 服务器上的大内存分配，从而实现了更小、更可预测的内存占用。因此，集群变得更具弹性和性能，尤其是在需要频繁请求大量资源列表的大规模环境中。

这项工作是作为由 SIG API Machinery 领导的 KEP #5116 的一部分完成的。

弹性的 watch 缓存初始化

Watch 缓存是 `kube-apiserver` 内部的一个缓存层，它维护着存储在 etcd 中集群状态的最终一致性缓存。过去，在 `kube-apiserver` 启动期间 watch 缓存尚未初始化或需要重新初始化时，可能会出现问题。

为了解决这些问题，watch 缓存初始化过程已变得对故障更具弹性，从而提高了控制平面的鲁棒性，并确保控制器和客户端能够可靠地建立 watch。此改进在 v1.31 中作为 Beta 引入，现已达到稳定。

这项工作是作为由 SIG API Machinery 和 SIG Scalability 领导的 KEP #4568 的一部分完成的。

放宽 DNS 搜索路径验证

以前，在 Kubernetes 中对 Pod 的 DNS `search` 路径进行严格验证，常常在复杂或传统的网络环境中造成集成挑战。这种限制性可能会阻止组织基础设施所必需的配置，迫使管理员实施困难的变通方法。
为了解决这个问题，放宽的 DNS 验证在 v1.32 中作为 Alpha 引入，现已在 v1.34 中进入稳定阶段。一个常见的用例是 Pod 需要与内部 Kubernetes 服务和外部域通信。通过在 Pod 的 `.spec.dnsConfig` 的 `searches` 列表的第一个条目中设置一个单点（`.`），管理员可以防止系统的解析器将集群的内部搜索域附加到外部查询。这避免了向内部 DNS 服务器为外部主机名生成不必要的 DNS 请求，提高了效率并防止了潜在的解析错误。

这项工作是作为由 SIG Network 领导的 KEP #4427 的一部分完成的。

在 Windows `kube-proxy` 中支持直接服务返回 (DSR)

DSR 通过允许通过负载均衡器路由的返回流量绕过负载均衡器直接响应客户端，从而提供性能优化，减少负载均衡器的负载并改善整体延迟。有关 Windows 上 DSR 的信息，请阅读直接服务返回 (DSR) 简介。
该功能最初在 v1.14 中引入，在 v1.34 中进入稳定阶段。

这项工作是作为由 SIG Windows 领导的 KEP #5100 的一部分完成的。

容器生命周期钩子的休眠操作

为容器的 PreStop 和 PostStart 生命周期钩子引入了休眠操作，以提供一种直接的方式来管理优雅关闭并改善整体容器生命周期管理。
休眠操作允许容器在启动后或终止前暂停指定的时间。使用负数或零的休眠持续时间会立即返回，相当于无操作。
休眠操作在 Kubernetes v1.29 中引入，零值支持在 v1.32 中添加。这两个功能都在 v1.34 中进入稳定阶段。

这项工作是作为由 SIG Node 领导的 KEP #3960 和 KEP #4818 的一部分完成的。

Linux 节点交换支持

历史上，Kubernetes 缺乏交换支持可能导致工作负载不稳定，因为在内存压力下的节点通常必须突然终止进程。这尤其影响了具有大而不常访问的内存占用量的应用程序，并妨碍了更优雅的资源管理。

为了解决这个问题，在 v1.22 中引入了可配置的每节点交换支持。它已经历了 Alpha 和 Beta 阶段，并在 v1.34 中进入稳定阶段。主要模式 `LimitedSwap` 允许 Pod 在其现有内存限制内使用交换，为问题提供了直接的解决方案。默认情况下，`kubelet` 配置为 `NoSwap` 模式，这意味着 Kubernetes 工作负载不能使用交换。

此功能提高了工作负载的稳定性，并允许更有效地利用资源。它使集群能够支持更广泛的应用程序，尤其是在资源受限的环境中，尽管管理员必须考虑交换的潜在性能影响。

这项工作是作为由 SIG Node 领导的 KEP #2400 的一部分完成的。

允许在环境变量中使用特殊字符

Kubernetes 中的环境变量验证规则已经放宽，允许在变量名中使用几乎所有可打印的 ASCII 字符，但不包括 `=`。这一变化支持了工作负载需要在变量名中使用非标准字符的场景——例如，像 .NET Core 这样的框架使用 `:` 来表示嵌套的配置键。

放宽的验证适用于直接在 Pod spec 中定义的环境变量，以及使用 `envFrom` 引用 ConfigMap 和 Secret 注入的环境变量。

这项工作是作为由 SIG Node 领导的 KEP #4369 的一部分完成的。

污点管理与节点生命周期分离

历史上，`TaintManager` 根据节点状况（NotReady、Unreachable 等）应用 NoSchedule 和 NoExecute 污点的逻辑与节点生命周期控制器紧密耦合。这种紧密耦合使得代码更难维护和测试，也限制了基于污点的驱逐机制的灵活性。此 KEP 将 `TaintManager` 重构为 Kubernetes 控制器管理器内的一个独立控制器。这是一个旨在提高代码模块化和可维护性的内部架构改进。这一变化使得基于污点的驱逐逻辑可以独立地进行测试和演进，但对用户如何使用污点没有直接的影响。

这项工作是作为由 SIG Scheduling 和 SIG Node 领导的 KEP #3902 的一部分完成的。

进入 Beta 阶段的新功能

以下是 v1.34 发布后进入 Beta 阶段的一些改进。

Pod 级别的资源请求和限制

为具有多个容器的 Pod 定义资源需求一直具有挑战性，因为请求和限制只能在每个容器的基础上设置。这迫使开发人员要么为每个容器过度配置资源，要么 meticulously 划分总的所需资源，使得配置复杂且常常导致资源分配效率低下。为了简化这一点，引入了在 Pod 级别指定资源请求和限制的能力。这允许开发人员为 Pod 定义一个整体的资源预算，然后由其组成的容器共享。此功能在 v1.32 中作为 Alpha 引入，并在 v1.34 中进入 Beta 阶段，HPA 现在支持 Pod 级别的资源规范。

主要的好处是为多容器 Pod 管理资源提供了一种更直观、更直接的方法。它确保所有容器使用的总资源不超过 Pod 定义的限制，从而实现更好的资源规划、更准确的调度和更高效的集群资源利用。

这项工作是作为由 SIG Scheduling 和 SIG Autoscaling 领导的 KEP #2837 的一部分完成的。

用于 `kubectl` 用户偏好的 `.kuberc` 文件

`.kuberc` 配置文件允许你为 `kubectl` 定义偏好，例如默认选项和命令别名。与 kubeconfig 文件不同，`.kuberc` 配置文件不包含集群详细信息、用户名或密码。
此功能在 v1.33 中作为 Alpha 引入，受环境变量 `KUBECTL_KUBERC` 限制。它在 v1.34 中进入 Beta 阶段并默认启用。

这项工作是作为由 SIG CLI 领导的 KEP #3104 的一部分完成的。

外部 ServiceAccount 令牌签名

传统上，Kubernetes 使用在 `kube-apiserver` 启动时从磁盘加载的静态签名密钥来管理 ServiceAccount 令牌。此功能引入了一个用于进程外签名的 `ExternalJWTSigner` gRPC 服务，使 Kubernetes 发行版能够与外部密钥管理解决方案（例如，HSM、云 KMS）集成，用于 ServiceAccount 令牌签名，而不是基于磁盘的静态密钥。

此外部 JWT 签名功能在 v1.32 中作为 Alpha 引入，在 v1.34 中进入 Beta 阶段并默认启用。

这项工作是作为由 SIG Auth 领导的 KEP #740 的一部分完成的。

DRA 功能进入 Beta 阶段

用于安全资源监控的管理员访问

DRA 通过 ResourceClaims 或 ResourceClaimTemplates 中的 `adminAccess` 字段支持受控的管理员访问，允许集群操作员访问其他人已在使用的设备以进行监控或诊断。此特权模式仅限于有权在标记为 `resource.k8s.io/admin-access: "true"` 的命名空间中创建此类对象的用户，确保常规工作负载不受影响。此功能在 v1.34 中进入 Beta 阶段，通过基于命名空间的授权检查提供安全的内省能力，同时保持工作负载隔离。

这项工作是作为由 WG Device Management 和 SIG Auth 领导的 KEP #5018 的一部分完成的。

ResourceClaims 和 ResourceClaimTemplates 中的优先备选方案

虽然工作负载可能在单个高性能 GPU 上运行得最好，但它也可能能够在两个中级 GPU 上运行。
随着 `DRAPrioritizedList` 功能门（现已默认启用）的引入，ResourceClaims 和 ResourceClaimTemplates 获得了一个名为 `firstAvailable` 的新字段。此字段是一个有序列表，允许用户指定一个请求可以通过不同方式满足，包括在特定硬件不可用时完全不分配。调度器将按顺序尝试满足列表中的备选方案，因此工作负载将被分配到集群中可用的最佳设备集。

这项工作是作为由 WG Device Management 领导的 KEP #4816 的一部分完成的。

`kubelet` 报告已分配的 DRA 资源

`kubelet` 的 API 已更新，以报告通过 DRA 分配的 Pod 资源。这允许节点监控代理发现节点上 Pod 的已分配 DRA 资源。此外，它使节点组件能够使用 PodResourcesAPI 并在开发新功能和集成时利用此 DRA 信息。
从 Kubernetes v1.34 开始，此功能默认启用。

这项工作是作为由 WG Device Management 领导的 KEP #3695 的一部分完成的。

`kube-scheduler` 非阻塞 API 调用

`kube-scheduler` 在调度周期中进行阻塞性 API 调用，造成性能瓶颈。此功能通过带有请求去重功能的优先队列系统引入了异步 API 处理，允许调度器在 API 操作在后台完成时继续处理 Pod。主要好处包括减少调度延迟、防止 API 延迟期间调度器线程饿死，以及为不可调度的 Pod 提供即时重试能力。该实现保持了向后兼容性，并添加了用于监控待处理 API 操作的指标。

这项工作是作为由 SIG Scheduling 领导的 KEP #5229 的一部分完成的。

变更性准入策略

MutatingAdmissionPolicies 为变更性准入 Webhook 提供了一种声明式的、进程内的替代方案。此功能利用 CEL 的对象实例化和 JSON Patch 策略，结合服务器端应用（Server Side Apply）的合并算法。
这通过允许管理员直接在 API 服务器中定义变更规则，显著简化了准入控制。
变更性准入策略在 v1.32 中作为 Alpha 引入，在 v1.34 中进入 Beta 阶段。

这项工作是作为由 SIG API Machinery 领导的 KEP #3962 的一部分完成的。

可快照的 API 服务器缓存

`kube-apiserver` 的缓存机制（watch cache）高效地服务于对最新观察状态的请求。然而，对先前状态的 **list** 请求（例如，通过分页或指定 `resourceVersion`）通常会绕过此缓存，直接从 etcd 服务。这种直接访问 etcd 的方式显著增加了性能成本，并可能导致稳定性问题，特别是在处理大型资源时，由于传输大数据块造成的内存压力。
随着 `ListFromCacheSnapshot` 功能门默认启用，`kube-apiserver` 将在 `resourceVersion` 比请求的旧的快照可用时尝试从快照服务响应。`kube-apiserver` 启动时没有快照，在每个 watch 事件上创建一个新快照，并保留它们直到检测到 etcd 被压缩或缓存中充满了比 75 秒更旧的事件。如果提供的 `resourceVersion` 不可用，服务器将回退到 etcd。

这项工作是作为由 SIG API Machinery 领导的 KEP #4988 的一部分完成的。

用于 Kubernetes 原生类型声明式验证的工具

在此版本之前，Kubernetes 内置 API 的验证规则完全是手动编写的，这使得维护者难以发现、理解、改进或测试。没有一种单一的方法可以找到可能适用于 API 的所有验证规则。**声明式验证**通过使 API 开发、维护和审查更容易，并实现编程检查以获得更好的工具和文档，从而使 Kubernetes 维护者受益。对于使用 Kubernetes 库编写自己代码的人（例如：控制器），新方法通过 IDL 标签简化了新字段的添加，而不是复杂的验证函数。这一变化有助于通过自动化验证样板代码来加速 API 创建，并通过对版本化类型进行验证来提供更相关的错误消息。​​​​​​​​​​​​​​​​
此增强功能（在 v1.33 中进入 Beta 阶段，并在 v1.34 中继续作为 Beta）将基于 CEL 的验证规则引入到 Kubernetes 原生类型中。它允许直接在类型定义中定义更精细和声明式的验证，从而提高了 API 的一致性和开发人员体验。

这项工作是作为由 SIG API Machinery 领导的 KEP #5073 的一部分完成的。

用于 **list** 请求的流式 Informer

自 v1.32 以来一直处于 Beta 阶段的流式 Informer 功能，在 v1.34 中获得了进一步的 Beta 改进。此功能允许 **list** 请求将数据作为来自 API 服务器 watch 缓存的连续对象流返回，而不是直接从 etcd 组装分页结果。通过重用用于 **watch** 操作的相同机制，API 服务器可以服务于大型数据集，同时保持内存使用稳定，并避免可能影响稳定性的分配峰值。

在此版本中，`kube-apiserver` 和 `kube-controller-manager` 默认都利用了新的 `WatchList` 机制。对于 `kube-apiserver`，这意味着 list 请求被更有效地流式传输，而 `kube-controller-manager` 则受益于一种更内存高效和可预测的方式来处理 Informer。这些改进共同减少了大型 list 操作期间的内存压力，并提高了持续负载下的可靠性，使得 list 流式传输更可预测和高效。

这项工作是作为由 SIG API Machinery 和 SIG Scalability 领导的 KEP #3157 的一部分完成的。

Windows 节点的优雅节点关闭处理

Windows 节点上的 `kubelet` 现在可以检测系统关闭事件，并开始优雅地终止正在运行的 Pod。这与 Linux 上的现有行为类似，有助于确保工作负载在计划的关闭或重启期间干净地退出。
当系统开始关闭时，`kubelet` 会使用标准的终止逻辑做出反应。它尊重配置的生命周期钩子和宽限期，在节点关闭前给 Pod 时间停止。该功能依赖于 Windows 的预关闭通知来协调此过程。此增强功能提高了维护、重启或系统更新期间的工作负载可靠性。它现在处于 Beta 阶段并默认启用。

这项工作是作为由 SIG Windows 领导的 KEP #4802 的一部分完成的。

就地 Pod 调整大小改进

在 v1.33 中进入 Beta 阶段并默认启用的就地 Pod 调整大小，在 v1.34 中获得了进一步的改进。这些改进包括支持减少内存使用以及与 Pod 级别资源的集成。

此功能在 v1.34 中仍处于 Beta 阶段。有关详细的使用说明和示例，请参阅文档：调整分配给容器的 CPU 和内存资源。

这项工作是作为由 SIG Node 和 SIG Autoscaling 领导的 KEP #1287 的一部分完成的。

进入 Alpha 阶段的新功能

以下是 v1.34 发布后进入 Alpha 阶段的一些改进。

用于 mTLS 身份验证的 Pod 证书

在集群内对工作负载进行身份验证，特别是与 API 服务器的通信，主要依赖于 ServiceAccount 令牌。虽然有效，但这些令牌并不总是建立强大、可验证的相互 TLS (mTLS) 身份的理想选择，并且在与期望基于证书的身份验证的外部系统集成时可能会带来挑战。
Kubernetes v1.34 引入了一种内置机制，供 Pod 通过 PodCertificateRequests 获取 X.509 证书。`kubelet` 可以为 Pod 请求和管理证书，然后这些证书可用于使用 mTLS 对 Kubernetes API 服务器和其他服务进行身份验证。主要的好处是为 Pod 提供了一个更强大、更灵活的身份机制。它提供了一种实现强 mTLS 身份验证的本地方式，而不仅仅是依赖于持有者令牌，从而使 Kubernetes 与标准安全实践保持一致，并简化了与支持证书的可观察性和安全工具的集成。

这项工作是作为由 SIG Auth 领导的 KEP #4317 的一部分完成的。

“受限”Pod 安全标准现在禁止远程探针

探针和生命周期处理程序中的 `host` 字段允许用户指定除 `podIP` 之外的实体供 `kubelet` 进行探测。然而，这为滥用和绕过安全控制的攻击开辟了一条途径，因为 `host` 字段可以设置为**任何**值，包括安全敏感的外部主机或节点上的 localhost。在 Kubernetes v1.34 中，只有当 Pod 要么不设置 `host` 字段，要么甚至不使用这种类型的探针时，才满足受限 Pod 安全标准。你可以使用**Pod 安全准入**或第三方解决方案来强制 Pod 满足此标准。因为这些是安全控制，请检查文档以了解你选择的强制执行机制的限制和行为。

这项工作是作为由 SIG Auth 领导的 KEP #4940 的一部分完成的。

使用 `.status.nominatedNodeName` 表示 Pod 放置

当 `kube-scheduler` 需要时间将 Pod 绑定到节点时，集群自动缩放器可能无法理解 Pod 将被绑定到特定节点。因此，它们可能会错误地认为该节点未被充分利用并将其删除。
为了解决这个问题，`kube-scheduler` 不仅可以使用 `.status.nominatedNodeName` 来表示正在进行的抢占，还可以用来表达 Pod 放置的意图。通过启用 `NominatedNodeNameForExpectation` 功能门，调度器使用此字段来指示 Pod 将被绑定到哪里。这暴露了内部预留，以帮助外部组件做出明智的决策。

这项工作是作为由 SIG Scheduling 领导的 KEP #5278 的一部分完成的。

DRA 功能进入 Alpha 阶段

DRA 的资源健康状况

很难知道一个 Pod 何时正在使用一个已发生故障或暂时不健康的设备，这使得对 Pod 崩溃进行故障排除变得困难或不可能。
DRA 的资源健康状况通过在 Pod 的状态中暴露分配给 Pod 的设备的健康状况，提高了可观察性。这使得更容易识别与不健康设备相关的 Pod 问题的原因并做出适当的响应。
要启用此功能，必须启用 `ResourceHealthStatus` 功能门，并且 DRA 驱动程序必须实现 `DRAResourceHealth` gRPC 服务。

这项工作是作为由 WG Device Management 领导的 KEP #4680 的一部分完成的。

扩展资源映射

扩展资源映射为 DRA 的表达性和灵活性方法提供了一个更简单的替代方案，通过提供一种直接的方式来描述资源容量和消耗。此功能使集群管理员能够将 DRA 管理的资源作为**扩展资源**进行宣传，允许应用程序开发人员和操作员继续使用熟悉的容器的 `.spec.resources` 语法来消费它们。
这使得现有工作负载无需修改即可采用 DRA，简化了应用程序开发人员和集群管理员向 DRA 的过渡。

这项工作是作为由 WG Device Management 领导的 KEP #5004 的一部分完成的。

DRA 可消耗容量

Kubernetes v1.33 增加了对资源驱动程序宣传可用设备切片的支持，而不是将整个设备作为全有或全无的资源暴露。然而，这种方法无法处理设备驱动程序根据用户需求管理设备资源的细粒度、动态部分，或独立于受其规范和命名空间限制的 ResourceClaims 共享这些资源的场景。
启用 `DRAConsumableCapacity` 功能门（在 v1.34 中作为 Alpha 引入）允许资源驱动程序在多个 ResourceClaims 或多个 DeviceRequests 之间共享同一个设备，甚至是设备的切片。该功能还扩展了调度器，以支持分配设备资源的部分，如 `capacity` 字段中定义。此 DRA 功能改进了跨命名空间和声明的设备共享，使其适应 Pod 的需求。它使驱动程序能够强制执行容量限制，增强了调度，并支持新的用例，如带宽感知网络和多租户共享。

这项工作是作为由 WG Device Management 领导的 KEP #5075 的一部分完成的。

设备绑定条件

Kubernetes 调度器通过延迟将 Pod 绑定到节点，直到其所需的外部资源（如可附加设备或 FPGA）被确认准备就绪，从而变得更加可靠。
此延迟机制在调度框架的PreBind 阶段实现。在此阶段，调度器在继续绑定之前检查是否所有必需的设备条件都已满足。这使得能够与外部设备控制器协调，确保更健壮、可预测的调度。

这项工作是作为由 WG Device Management 领导的 KEP #5007 的一部分完成的。

容器重启规则

目前，一个 Pod 内的所有容器在退出或崩溃时都会遵循相同的 `.spec.restartPolicy`。然而，运行多个容器的 Pod 可能对每个容器有不同的重启要求。例如，对于用于执行初始化的 init 容器，如果它们失败，你可能不希望重试初始化。同样，在具有长时间运行的训练工作负载的 ML 研究环境中，因可重试的退出代码而失败的容器应该快速就地重启，而不是触发 Pod 重建并丢失进度。
Kubernetes v1.34 引入了 `ContainerRestartRules` 功能门。启用后，可以为 Pod 内的每个容器指定一个 `restartPolicy`。还可以定义一个 `restartPolicyRules` 列表，以根据最后一个退出代码覆盖 `restartPolicy`。这提供了处理复杂场景和更好地利用计算资源所需的精细控制。

这项工作是作为由 SIG Node 领导的 KEP #5307 的一部分完成的。

从运行时创建的文件中加载环境变量

应用程序开发人员长期以来一直要求在声明环境变量方面有更大的灵活性。传统上，环境变量是通过静态值、ConfigMap 或 Secret 在 API 服务器端声明的。

在 `EnvFiles` 功能门后面，Kubernetes v1.34 引入了在运行时声明环境变量的能力。一个容器（通常是 init 容器）可以生成变量并将其存储在文件中，后续的容器可以从该文件中加载环境变量启动。这种方法消除了“包装”目标容器入口点的需要，实现了更灵活的 Pod 内容器编排。

此功能特别有利于 AI/ML 训练工作负载，其中训练作业中的每个 Pod 都需要使用运行时定义的值进行初始化。

这项工作是作为由 SIG Node 领导的 KEP #5307 的一部分完成的。

v1.34 中的升级、弃用和移除

升级到稳定版

这里列出了所有升级到稳定版（也称为**正式发布**）的功能。有关包括新功能和从 Alpha 升级到 Beta 的完整更新列表，请参阅发布说明。

此版本总共包含 23 项升级到稳定版的增强功能

弃用和移除

随着 Kubernetes 的发展和成熟，功能可能会被弃用、移除或被更好的功能替代，以改善项目的整体健康状况。有关此过程的更多详细信息，请参阅 Kubernetes 弃用和移除策略。Kubernetes v1.34 包括一些弃用。

手动配置 cgroup 驱动程序已弃用

历史上，为运行 Kubernetes 集群的用户配置正确的 cgroup 驱动程序一直是一个痛点。Kubernetes v1.28 添加了一种方式，让 `kubelet` 查询 CRI 实现并找出要使用的 cgroup 驱动程序。这种自动检测现在**强烈推荐**，并且其支持在 v1.34 中已进入稳定阶段。如果你的 CRI 容器运行时不支持报告其需要的 cgroup 驱动程序，你应该升级或更改你的容器运行时。`kubelet` 配置文件中的 `cgroupDriver` 配置设置现已弃用。相应的命令行选项 `--cgroup-driver` 先前已弃用，因为 Kubernetes 推荐使用配置文件。配置设置和命令行选项都将在未来的版本中移除，该移除不会早于 v1.36 次要版本。

这项工作是作为由 SIG Node 领导的 KEP #4033 的一部分完成的。

Kubernetes 将在 v1.36 中结束对 containerd 1.x 的支持

虽然 Kubernetes v1.34 仍然支持 containerd 1.7 和 containerd 的其他 LTS 版本，但由于自动 cgroup 驱动程序检测的结果，Kubernetes SIG Node 社区已正式商定了对 containerd v1.X 的最终支持时间表。提供此支持的最后一个 Kubernetes 版本将是 v1.35（与 containerd 1.7 EOL 对齐）。这是一个早期警告，如果你正在使用 containerd 1.X，请考虑尽快切换到 2.0+。你可以监控 `kubelet_cri_losing_support` 指标，以确定你的集群中是否有任何节点正在使用即将过时的 containerd 版本。

这项工作是作为由 SIG Node 领导的 KEP #4033 的一部分完成的。

`PreferClose` 流量分发已弃用

Kubernetes Service 中的 `spec.trafficDistribution` 字段允许用户表达关于如何将流量路由到服务端点的偏好。

KEP-3015 弃用了 `PreferClose` 并引入了两个额外的值：`PreferSameZone` 和 `PreferSameNode`。`PreferSameZone` 是现有 `PreferClose` 的别名，以澄清其语义。`PreferSameNode` 允许在可能的情况下将连接传递到本地端点，在不可能的情况下回退到远程端点。

此功能在 v1.33 中在 `PreferSameTrafficDistribution` 功能门后引入。它在 v1.34 中进入 Beta 阶段并默认启用。

这项工作是作为由 SIG Network 领导的 KEP #3015 的一部分完成的。

发布说明

请在我们的发布说明中查看 Kubernetes v1.34 发布的完整详细信息。

可用性

Kubernetes v1.34 可在 GitHub 或 Kubernetes 下载页面上下载。

要开始使用 Kubernetes，请查看这些交互式教程或使用 minikube 运行本地 Kubernetes 集群。你还可以使用 kubeadm 轻松安装 v1.34。

发布团队

Kubernetes 的成功离不开其社区的支持、承诺和辛勤工作。每个发布团队都由敬业的社区志愿者组成，他们共同努力，构建了你所依赖的 Kubernetes 版本的许多部分。这需要来自我们社区各个角落的人们的专业技能，从代码本身到其文档和项目管理。

我们纪念 Rodolfo "Rodo" Martínez Vega，他是一位敬业的贡献者，他对技术和社区建设的热情在 Kubernetes 社区留下了印记。Rodo 在多个版本中担任 Kubernetes 发布团队的成员，包括 v1.22-v1.23 和 v1.25-v1.30，表现出对项目成功和稳定性的坚定承诺。
除了他在发布团队的贡献之外，Rodo 还深入参与了促进 Cloud Native LATAM 社区的发展，帮助弥合了该领域的语言和文化障碍。他在 Kubernetes 文档的西班牙语版本和 CNCF 术语表方面的工作，体现了他致力于让全球讲西班牙语的开发人员能够获取知识的奉献精神。Rodo 的遗产通过他指导的无数社区成员、他帮助交付的版本以及他帮助培育的充满活力的 LATAM Kubernetes 社区得以延续。

我们想感谢整个发布团队，感谢他们为向我们的社区交付 Kubernetes v1.34 版本而付出的辛勤工作。发布团队的成员范围从首次参与的影子成员到拥有多个发布周期经验的回归团队负责人。特别感谢我们的发布负责人 Vyom Yadav，感谢他在一个成功的发布周期中指导我们，感谢他解决挑战的亲力亲为的方法，以及他为推动我们社区前进所带来的活力和关怀。

项目速度

CNCF K8s DevStats 项目汇总了许多与 Kubernetes 和各种子项目速度相关的有趣数据点。这包括从个人贡献到贡献公司数量的所有内容，是这个生态系统发展所付出的努力深度和广度的体现。

在 v1.34 发布周期中，从 2025 年 5 月 19 日到 2025 年 8 月 27 日，为期 15 周，Kubernetes 收到了来自多达 106 家不同公司和 491 名个人的贡献。在更广泛的云原生生态系统中，这一数字上升到 370 家公司，总共有 2235 名贡献者。

请注意，“贡献”指的是某人进行提交、代码审查、评论、创建 issue 或 PR、审查 PR（包括博客和文档）或评论 issue 和 PR 的次数。
如果你有兴趣贡献，请访问我们贡献者网站上的入门指南。

此数据来源

活动更新

探索即将举行的 Kubernetes 和云原生活动，包括 KubeCon + CloudNativeCon、KCD 和全球其他值得关注的会议。随时了解并参与 Kubernetes 社区！

2025 年 8 月

2025 年 9 月

2025 年 10 月

2025 年 11 月

2025 年 12 月

你可以在这里找到最新的活动详情。

即将举行的发布网络研讨会

请于 2025 年 9 月 24 日星期三下午 4:00 (UTC) 加入 Kubernetes v1.34 发布团队的成员，了解此版本的发布亮点。更多信息和注册，请访问 CNCF 在线计划网站上的活动页面。

参与其中

参与 Kubernetes 的最简单方法是加入众多与你的兴趣相符的特别兴趣小组 (SIG) 之一。有什么想向 Kubernetes 社区广播的吗？在我们的每周社区会议以及通过以下渠道分享你的声音。感谢你持续的反馈和支持。