Kubernetes Blog

从 Kubernetes Dashboard 到 Headlamp：理解过渡

Mon, 01 Jun 2026 10:00:00 -0800

对许多人来说，Kubernetes Dashboard 是他们了解 Kubernetes 的第一个窗口。它提供了一种简单的可视化方式来查看集群中运行的内容、检查资源，并在不依赖命令行的情况下建立信心。多年来，它帮助开发者、学生和运维人员理解 Kubernetes，并作为进入生态系统的重要入口。

Kubernetes Dashboard 项目现已归档。我们深深尊重该团队所做的工作，以及 Dashboard 在让如此多用户更容易接触 Kubernetes 方面所发挥的作用。

Headlamp 在此基础上构建并向前发展。它保持了可视化界面的清晰性，同时添加了与当今 Kubernetes 使用方式相匹配的功能。这包括多集群可见性、以应用为中心的视图、通过插件实现的可扩展性，以及在集群内和桌面上都能工作的灵活部署选项。

本指南旨在帮助你自信地完成这一过渡。在深入探讨迁移机制之前，我们从熟悉的内容开始，看看常见的 Kubernetes Dashboard 工作流程如何映射到 Headlamp。我们还将介绍切换后保持不变的内容和改进的内容。我们的目标不仅是替换工具，更是为了尊重以用户为中心的传统，并帮助你找到一个能够随着 Kubernetes 使用方式演变而成长的 UI。

Kubernetes Dashboard 工作负载映射到 Headlamp

如果你以前使用过 Kubernetes Dashboard，Headlamp 中的许多工作流程会让你感到熟悉。 Headlamp 并没有引入新的思维方式。相反，它建立在用户已经熟悉的工作负载之上，并以实用的方式扩展它们。重点是连续性。以前有效的方法仍然有效，同时有更多的发展空间。

查看工作负载和资源

在 Kubernetes Dashboard 中，大多数用户从浏览工作负载（如 Pod、Deployment、Service 和 Namespace）开始。 Headlamp 保持这个相同的起点。工作负载易于查找和检查，在命名空间和集群之间切换更加简单。资源仍然以熟悉的方式组织，导航感觉更流畅，尤其是在跨多个环境工作时。

编辑和与资源交互

与 Kubernetes Dashboard 一样，Headlamp 允许你根据权限直接在 UI 中查看和编辑清单。你可以从界面删除资源、缩放工作负载或更新配置。所有操作都遵循标准的 Kubernetes RBAC。如果你能在 Dashboard 中执行某个操作，你将在 Headlamp 中找到相同的功能，并且同样尊重访问控制。

理解关系

Headlamp 开始扩展体验的地方在于它呈现资源之间关系的方式。除了列表视图，Headlamp 还提供了可视化方式来查看工作负载、服务和配置之间的连接。这有助于在不改变用户已经依赖的底层工作负载的情况下提供上下文。

从高层次来看，你在 Kubernetes Dashboard 中执行的任务仍然存在。 Headlamp 保留了熟悉的工作流程，同时随着集群、团队和应用的增长，使其更容易扩展。

Headlamp 超越 Kubernetes Dashboard 的地方

从单集群扩展到多集群工作流程

Kubernetes Dashboard 设计为一次只处理一个集群。这种模式在简单设置中效果很好，但随着团队采用多个环境，它变得有限制。 Headlamp 通过允许你从单个界面处理多个集群而无需切换工具或丢失上下文，扩展了这个视图。这使得并排管理开发、暂存和生产环境变得更容易。

对于在多个地方运行 Kubernetes 的团队来说，这种转变减少了摩擦。你可以保持方向感，并自信地在集群之间移动。

通过 Projects 从资源列表到应用上下文

Projects 为你提供了一种以应用为中心的方式来查看 Kubernetes。你可以将相关的工作负载、服务和支持资源分组到一个地方，而不是在列表之间跳转。这使应用更容易理解。你可以看到哪些资源属于一起，在上下文中跟踪更改，并在不逐个扫描集群的情况下进行故障排除。

Projects 建立在原生 Kubernetes 概念之上。 Namespaces、labels 和 RBAC 继续以它们一贯的方式工作。 Headlamp 添加了一个视觉层，将相关资源聚集在一起。

Projects 是可选的。当适合你的任务时，你仍然可以在单个资源级别工作。当你需要更多上下文时，Projects 帮助你退一步看到更大的图景。

使用插件扩展 Headlamp UI

Headlamp 可以通过插件扩展，这些插件将常见工作流程直接带入 UI。你可以在一个地方使用相同的上下文工作，而无需切换工具。

例如，Flux 插件将 GitOps 工作流程带入 Headlamp。它允许团队在 Flux 管理的 Kubernetes 资源旁边查看应用状态，使理解 Git 中的更改如何与集群中运行的内容相关变得更容易。

AI Assistant 遵循类似的模式。它在 UI 中添加了一个对话层，帮助用户理解他们所看到的内容、排除问题或采取行动。所有这些都发生在问题出现的同一个屏幕上。

构建自己的插件

插件是可选的，不限于社区构建的扩展。平台和项目团队也可以创建自己的插件。这允许组织添加符合其特定工作流程和内部工具的自定义集成，同时保持用户体验的一致性。

选择 Headlamp 的运行方式和位置

Headlamp 为团队提供了使用 Kubernetes UI 的灵活性。你可以直接在集群中运行它，将其用作桌面应用，或根据需要结合两种方法。

在集群内运行 Headlamp 适用于共享环境。它提供了一个集中管理的 UI，具有受控访问权限，并自然地融入 Kubernetes 设置，遵循与其他集群内组件相同的认证和 RBAC 规则。

桌面应用通常更适合本地开发和入职培训。当你需要从一个地方管理多个集群时，它也很有效。用户可以使用现有的 kubeconfig 连接，而无需在集群中部署任何东西。

这些选项不是相互排斥的。许多团队使用桌面应用进行日常工作，同时依赖集群内部署用于共享或生产环境。

准备迁移

在从 Kubernetes Dashboard 迁移到 Headlamp 之前，停下来评估一下你今天如何使用 Dashboard 可能会有所帮助。提前进行一些思考可以大大有助于使过渡感觉顺畅和熟悉。

首先记录你访问的集群和命名空间以及认证如何工作。 Headlamp 依赖标准的 Kubernetes 认证和 RBAC。在大多数情况下，现有的访问模型无需更改即可延续。如果用户已经使用 kubeconfig 文件或服务账户连接，他们将能够在 Headlamp 中访问相同的资源。

思考对你的团队最重要的工作流程也很有用。一些用户依赖 Dashboard 进行快速检查或故障排除，而另一些用户则用它进行轻量级编辑或验证。 Headlamp 支持这些相同的工作流程，并在此基础上添加可选功能。了解你今天依赖什么有助于使过渡感觉可预测并建立信心。

如果你想在迁移前探索 Headlamp 或试用它，可以在 headlamp.dev 了解更多信息。

这篇博客重点介绍了理解过渡和预期内容。分步迁移指南即将推出，将详细介绍安装和迁移过程。

回顾既往：为未修复的 Kubernetes CVE 纠正记录

Thu, 21 May 2026 00:00:00 +0000

Kubernetes 项目依靠透明度来赋能集群管理员和安全研究人员。我们做到这一点的重要方式之一是将 CVE 记录发布到通用漏洞披露数据库中。作为我们持续完善官方 Kubernetes CVE 动态订阅源的一部分，我们发现了一些差异。某些较早的未修复问题的 CVE 记录错误地包含了 已修复版本（fixed version） 字段。

Kubernetes 安全响应委员会（SRC）将于 2026 年 6 月 1 日纠正受影响的 CVE 记录。这可能导致漏洞扫描器在这些漏洞之前未被检测到的地方识别出它们。

为帮助减少混淆，本文针对以下三个多年前披露但仍未修复的漏洞提供技术更新： CVE-2020-8561、CVE-2020-8562 和 CVE-2021-25740。

为什么我们现在更新这些记录

虽然这些漏洞已经公开多年，但最近生成官方开源漏洞（OSV）文件的工作发现，它们对应的 CVE 记录并未准确反映其状态。具体而言，某些记录表明存在已修复版本，而实际上这些问题属于架构设计上的权衡，无法在不破坏 Kubernetes 基础功能的情况下通过代码完全修复。

纠正这些记录对社区至关重要，原因如下：

自动化保真度：现代漏洞扫描器依赖于精确的版本范围。不准确的已修复标签会导致漏报，让用户产生虚假的安全感。

风险文档化：通过将这些正式确定为未修复，我们确保平台提供商和管理员了解持续需要采取管理缓解措施的必要性。

为完整性起见，我们还应提及 CVE-2020-8554 是一个未修复的 CVE，但其 CVE 记录正确地声明它影响所有版本。该记录也将更新为使用更标准化的版本号格式。

未修复架构风险的技术分析

以下漏洞将不会由 Kubernetes 项目修复。 GitHub 问题仍然是了解这些缺陷技术细节的最佳参考资料。

CVE-2020-8561：kube-apiserver 中的 Webhook 重定向

严重程度：中（4.1）。

问题描述：kube-apiserver 在与准入 webhook 通信时会遵循 HTTP 重定向。能够配置 AdmissionWebhookConfiguration 的参与者可以将 API 服务器请求重定向到内部私有网络。

未修复原因：限制此行为需要打破许多合法集成所依赖的标准 HTTP 客户端行为。

缓解措施：将 API 服务器日志级别设置为小于 10（以防止记录响应正文），并禁用动态性能分析（--profiling=false）以防止未经授权的日志级别更改。

CVE-2020-8562：通过 DNS TOCTOU 绕过代理

严重程度：低（3.1）。

问题描述：API 服务器代理中的检查时间到使用时间（TOCTOU）竞争条件允许用户绕过 IP 限制。系统执行 DNS 检查以验证 IP，但随后为实际连接执行第二次解析，攻击者可以操纵此过程。

未修复原因：修复此问题需要固定已解析的 IP，但这会破坏复杂的分割视图 DNS 或动态 IP 环境。

缓解措施：为 API 服务器使用本地 DNS 缓存服务器（如 dnsmasq），并配置 min-cache-ttl 以在检查和连接之间强制执行一致的响应。

CVE-2021-25740：通过 Endpoints 的跨名字空间转发

严重程度：低（3.1）。

问题描述：Endpoints 和 EndpointSlices API 对象中的设计缺陷允许用户手动指定 IP 地址，这些地址可用于将 LoadBalancer 或 Ingress 指向其他名字空间中的后端。

未修复原因：这是许多网络工具和 operator 使用的 Endpoints API 的基础功能。

缓解措施：限制对 Endpoints（遗留）和 EndpointSlices 的写访问权限。自 Kubernetes 1.22 起，Kubernetes RBAC 授权模式不再在默认 edit 和 admin ClusterRole 中包含这些权限。该移除适用于使用 Kubernetes v1.22 创建的集群；对于从旧版本升级的集群，管理员应手动审核并协调 system:aggregate-to-edit ClusterRole。

说明：

2026 年 6 月 1 日，这些 CVE 记录将被更新以正确反映所有版本均受影响的事实。你可能会看到它们开始出现在漏洞扫描器结果中。

管理员需要采取的操作

Kubernetes 项目推荐采用通过配置实现安全的方法来管理这些持续风险：

漏洞	操作项	严重程度评分（评级）	命令 / 配置
CVE-2020-8561	限制日志详细程度	4.1（中）	确保 `--v` 设置为 `< 10` 且 `--profiling=false`。
CVE-2020-8562	强制 DNS 一致性	3.1（低）	在控制平面节点上部署 dnsmasq 或类似的缓存解析器。
CVE-2021-25740	强化 RBAC	3.1（低）	使用 `kubectl auth reconcile` 从广泛角色中移除 Endpoints 写访问权限。

CVE-2021-25740 的 RBAC 操作适用于使用 RBAC 授权模式的集群，这是使用标准 Kubernetes 工具创建的集群的默认设置。管理员应在非生产环境中独立测试和验证这些配置，根据其特定的威胁模型和风险承受能力评估架构风险。

结语：通过透明度走向成熟

协调这些记录的努力是安全生态系统走向成熟的标志。通过摒弃仅打补丁的思维模式并准确记录架构债务， Kubernetes 项目为社区提供了保护现代云原生基础设施所需的高保真数据。

我们要感谢发现这些风险的安全研究人员 —— QiQi Xu、Javier Provecho 等，以及继续完善我们官方动态订阅源的 SIG Security Tooling 贡献者。特别感谢 Rory McCune 通过他的博客文章分享了有关这些 CVE 的信息。

Kubernetes v1.36：云控制器管理器中的路由同步新指标

Fri, 15 May 2026 10:35:00 -0800

本文最初发布时日期有误。后来重新发布，日期为 2026 年 5 月 15 日。

Kubernetes v1.36 在位于 k8s.io/cloud-provider 的云控制器管理器（CCM）路由控制器实现中引入了一个新的 Alpha 计数器指标 route_controller_route_sync_total。此指标在每次与云提供商同步路由时递增。

基于监视的路由调谐的 A/B 测试

添加此指标是为了帮助运维人员验证在 Kubernetes v1.35 中引入的 CloudControllerManagerWatchBasedRoutesReconciliation 特性门控。此特性门控将路由控制器从固定间隔循环切换为基于监视的方法，仅在节点实际发生变化时进行调谐。这减少了对基础设施提供商的不必要 API 调用，降低了速率限制 API 的压力，并允许运维人员更高效地使用其可用配额。

要对此进行 A/B 测试，请比较特性门控禁用（默认）与启用时的 route_controller_route_sync_total。在节点变化不频繁的集群中，开启特性门控后，你应该会看到同步速率显著下降。

示例：预期行为

特性门控禁用时（默认的固定间隔循环），无论是否发生任何节点变化，计数器都会稳定递增：

# After 10 minutes with no node changes
route_controller_route_sync_total 60
# After 20 minutes, still no node changes
route_controller_route_sync_total 120

特性门控启用时（基于监视的调和），仅在节点实际被添加、移除或更新时，计数器才会递增：

# After 10 minutes with no node changes
route_controller_route_sync_total 1
# After 20 minutes, still no node changes — counter unchanged
route_controller_route_sync_total 1
# A new node joins the cluster — counter increments
route_controller_route_sync_total 2

这种差异在节点很少变化的稳定集群中尤其明显。

我在哪里可以提供反馈？

如果你有反馈，欢迎通过以下任一渠道联系我们：

Kubernetes Slack 上的 #sig-cloud-provider 频道
GitHub 上的 KEP-5237 Issue
SIG Cloud Provider 社区页面了解其他沟通渠道

我如何了解更多？

有关更多详细信息，请参阅 KEP-5237。

Kubernetes v1.36：混合版本代理升级到 Beta

Fri, 15 May 2026 10:00:00 -0800

早在 Kubernetes 1.28 中，我们在之前的博客文章中引入了 Mixed Version Proxy (MVP) 作为 Alpha 特性（在特性门控 UnknownVersionInteroperabilityProxy 下）。目标简单但关键：通过确保对旧版 API 服务器尚不了解的资源请求被正确路由到较新的对等 API 服务器，而不是返回不正确的 404 Not Found，从而使集群升级更安全。

我们很高兴地宣布，Mixed Version Proxy 将在 Kubernetes 1.36 中升级到 Beta 版本，并将默认启用！该特性自首次发布以来有了显著发展，解决了关键差距并实现了架构现代化。

以下介绍该特性的发展历程以及在集群中使用它需要了解的内容。

我们正在解决什么问题？

在正在升级的高可用控制平面中，你通常会有运行不同版本的 API 服务器。这些服务器可能提供不同的 API 集（Groups、Versions、Resources）。没有 MVP，如果客户端请求落在不提供所请求资源的 API 服务器上（例如，升级中引入的新 API 版本），该服务器会返回 404 Not Found。这在技术上是不正确的，因为资源在集群中是可用的，只是不在该特定服务器上。这可能导致严重的副作用，例如错误的垃圾收集或命名空间删除被阻止。 MVP 通过将请求代理到能够提供该资源的对等 API 服务器来解决这个问题。

sequenceDiagram
    participant Client
    participant API_Server_A as API Server A (Older/Different)
    participant API_Server_B as API Server B (Newer/Capable)
    
    Client->>API_Server_A: 1. Request for Resource (e.g., v2)
    Note over API_Server_A: Determines it cannot serve locally
    API_Server_A->>API_Server_A: 2. Looks up capable peer in Discovery Cache
    API_Server_A->>API_Server_B: 3. Proxies request (adds x-kubernetes-peer-proxied header)
    API_Server_B->>API_Server_B: 4. Processes request locally
    API_Server_B-->>API_Server_A: 5. Returns Response
    API_Server_A-->>Client: 6. Forwards Response

自 1.28 以来的发展

最初的 Alpha 实现是一个很好的概念证明，但它有一些局限性并且依赖于旧机制。以下是我们为 Beta 版本进行现代化改进的方式：

从 StorageVersion API 到聚合发现在 Alpha 版本中，API 服务器依赖 StorageVersion API 来确定哪些对等服务器提供哪些资源。虽然功能正常，但这种方法有一个显著的局限性：StorageVersion API 尚不支持 CRD 和聚合 API。对于 Beta 版本，我们用 Aggregated Discovery 取代了对 StorageVersion API 调用的依赖。 API 服务器现在使用聚合发现数据来动态了解其对等服务器的能力。

缺失的部分：对等聚合发现 1.28 博客文章指出了一个显著的差距：虽然我们可以代理资源请求，但发现请求仍然只显示本地 API 服务器知道的内容。在 1.36 中，我们添加了 Peer-Aggregated Discovery 支持！现在，当客户端执行发现（例如，列出可用的 API）时，API 服务器会将其本地视图与所有活动对等服务器的发现数据合并。这为客户端提供了整个集群中所有可用 API 的完整、统一视图，无论它们连接到哪个 API 服务器。

sequenceDiagram
    participant Client
    participant API_Server_A as API Server A
    participant API_Server_B as API Server B
    
    Client->>API_Server_A: 1. Request Discovery Document
    API_Server_A->>API_Server_A: 2. Gets Local APIs
    API_Server_A->>API_Server_B: 3. Gets Peer APIs (Cached or Direct)
    API_Server_A->>API_Server_A: 4. Merges and sorts lists deterministically
    API_Server_A-->>Client: 5. Returns Unified Discovery Document

虽然对等聚合发现将是默认行为（请注意，如果设置了 --peer-ca-file 标志，则启用对等聚合发现，否则服务器将回退到仅显示其本地 API），但在某些情况下，你可能需要只检查你连接的特定 API 服务器提供的资源。你可以通过在请求的 Accept 头中包含 profile=nopeer 参数来请求此非聚合视图（例如，Accept: application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList;profile=nopeer）。

必需的配置

虽然特性门控将默认启用，但它需要设置某些标志以允许对等 API 服务器之间的安全通信。要正常工作，请确保你的 API 服务器配置了以下标志：

--feature-gates=UnknownVersionInteroperabilityProxy=true：这在 1.36 中将是默认值，但最好进行验证
--peer-ca-file=<path-to-ca>：[CRITICAL] 这是必需的标志。你必须提供源 API 服务器将用于验证目标对等 API 服务器服务证书的 CA 包。没有这个，代理将因 TLS 验证错误而失败。
--peer-advertise-ip 和 --peer-advertise-port：这些标志用于设置对等服务器应使用的网络地址来访问此 API 服务器。如果未设置，则使用 --advertise-address 或 --bind-address 的值。如果你的网络拓扑复杂，API 服务器通过特定内部接口通信，强烈建议显式设置这些标志。

使用 `kubeadm` 配置

如果你使用 kubeadm 管理集群，可以在 ClusterConfiguration 文件中配置这些标志：

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
apiServer:
  extraArgs:
    peer-ca-file: "/etc/kubernetes/pki/ca.crt"
    # `eer-advertise-ip 和端口（如果需要）

行动号召

如果你运行多主集群并定期升级它们，Mixed Version Proxy 是一项重大的安全改进。随着它在 1.36 中成为默认功能，我们鼓励你：

检查你的 API 服务器标志，确保 --peer-ca-file 已正确设置。
在准备 1.36 升级时，在你的暂存环境中测试此功能。
向 SIG API Machinery 提供反馈（Slack、邮件列表，或通过参加 SIG API Machinery 会议）分享你的体验。

Kubernetes v1.36：Service ExternalIPs 的弃用和移除

Thu, 14 May 2026 10:35:00 -0800

Service 的 .spec.externalIPs 字段是为非云集群提供类似云负载均衡器功能的早期尝试。不幸的是，该 API 假设集群中的每个用户都是完全可信的，而在任何不满足此条件的情况下，它会导致各种安全漏洞，如 CVE-2020-8554 中所述。

自 Kubernetes 1.21 起，Kubernetes 项目建议所有用户禁用 .spec.externalIPs。为了简化这一过程，Kubernetes 还添加了一个准入控制器（DenyServiceExternalIPs），可以启用它来实现此目的。当时，SIG Network 认为默认阻止该特性是一个太大的破坏性变更，不予考虑。

然而，安全问题仍然存在，作为一个项目，我们对该特性"默认不安全"的状态越来越不满意。此外，对于想要类似负载均衡器功能的非云集群，现在有几种更好的替代方案。

因此，Service 的 .spec.externalIPs 字段现在在 Kubernetes 1.36 中正式弃用。我们预计 Kubernetes 的未来次要版本将从 kube-proxy 中删除该行为的实现，并更新 Kubernetes 一致性标准，要求一致性实现不提供支持。

关于术语的说明，以及未被弃用的内容

短语 external IP 在 Kubernetes 中有些过度使用：

Service API 有一个字段 .spec.externalIPs，可用于添加 Service 将响应的额外 IP 地址。

Node API 的 .status.addresses 字段可以列出几种不同类型的地址，其中一种称为 ExternalIP。

kubectl 工具在以默认输出格式显示 LoadBalancer 类型的 Service 信息时，会在列标题 EXTERNAL-IP 下显示负载均衡器 IP 地址。

此弃用是关于第一项的。如果你没有在任何 Service 中设置 externalIPs 字段，则这不适用于你。

话虽如此，作为预防措施，你可能仍希望启用 DenyServiceExternalIPs 准入控制器来阻止将来对 externalIPs 字段的任何使用。

`externalIPs` 的替代方案

如果你正在使用 .spec.externalIPs，那么有几种替代方案。

考虑如下的 Service：

apiVersion: v1
kind: Service
metadata:
  name: my-example-service
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: my-example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  externalIPs:
    - "192.0.2.4"

使用手动管理的 LoadBalancer Service 代替 `externalIPs`

最简单（但也最糟糕）的选择是从使用 externalIPs 切换到使用 type: LoadBalancer 服务，并手动分配负载均衡器 IP。这本质上与 externalIPs 完全相同，但有一个重要区别：负载均衡器 IP 是 Service 的 .status 的一部分，而不是 .spec，在启用 RBAC 的集群中，默认情况下普通用户无法编辑它。因此，这种 externalIPs 的替代方案仅对管理员授予权限的用户可用（尽管这些用户随后将完全有能力复制 CVE-2020-8554；仍然不会有任何进一步的检查来确保一个用户没有窃取另一个用户的 IP 等）。

由于 .status 在 Kubernetes 中的工作方式，你必须创建不带负载均衡器 IP 的 Service，然后在第二步添加 IP：

$ cat loadbalancer-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-example-service
spec:
  # prevent any real load balancer controllers from managing this service
  # by using a non-existent loadBalancerClass
  loadBalancerClass: non-existent-class
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: my-example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
$ kubectl apply -f loadbalancer-service.yaml
service/my-example-service created
$ kubectl patch service my-example-service --subresource=status --type=merge -p '{"status":{"loadBalancer":{"ingress":[{"ip":"192.0.2.4"}]}}}'

使用非云负载均衡器控制器

虽然 LoadBalancer 服务最初设计为由云负载均衡器支持，但 Kubernetes 也可以通过使用第三方负载均衡器控制器（如 MetalLB）在非云平台上支持它们。这解决了与 externalIPs 相关的安全问题，因为管理员可以配置控制器将分配给服务的 IP 地址范围，并且控制器将确保两个服务不能同时使用同一个 IP。

因此，例如，在安装和配置 MetalLB 后，集群管理员可以配置集群中使用的 IP 地址池：

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production
  namespace: metallb-system
spec:
  addresses:
  - 192.0.2.0/24
  autoAssign: true
  avoidBuggyIPs: false

之后，用户可以创建 type: LoadBalancer Service，MetalLB 将处理 IP 地址的分配。 MetalLB 甚至支持 Service 中已弃用的 loadBalancerIP 字段，因此最终用户可以请求特定的 IP（假设可用）以实现与 externalIPs 方法的向后兼容性，而不是随机分配一个：

apiVersion: v1
kind: Service
metadata:
  name: my-example-service
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: my-example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  loadBalancerIP: "192.0.2.4"

类似的方法也适用于其他负载均衡器控制器。这种方法允许集群管理员控制分配哪些 IP 地址，而不是由用户控制。

使用 Gateway API

另一个可能的解决方案是使用 Gateway API 的实现。

Gateway API 允许集群管理员定义 Gateway 资源，该资源可以通过 .spec.addresses 字段附加 IP 地址。由于 Gateway 资源设计为由集群管理员管理，因此可以设置 RBAC 规则，仅允许特权用户管理它们。

示例如下：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  addresses:
  - type: IPAddress
    value: "192.0.2.4"
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - backendRefs:
    - name: example-svc
      port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: example-svc
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Gateway API 项目是 Kubernetes 中 Kubernetes Ingress、负载均衡和服务网格 API 的下一代。 Gateway API 旨在修复 Service 和 Ingress 资源的缺点，使其成为正在积极开发的非常可靠的稳健解决方案。

`externalIPs` 弃用时间表

此弃用的粗略时间表如下：

随着 Kubernetes 1.36 的发布，该字段被弃用；当用户使用此字段时，Kubernetes 现在会发出警告
大约一年后（最早为 v1.40），对 .spec.externalIPs 的支持将在 kube-proxy 中被禁用，但用户将有一种方法可以选择重新启用，以便他们需要更多时间进行迁移
大约再过一年后（最早为 v1.43），支持将被完全禁用；用户将无法选择重新启用

Kubernetes v1.36：工作负载感知调度再进一步

Wed, 13 May 2026 10:35:00 -0800

AI/ML 和批处理工作负载带来了独特的调度挑战，已经超出了简单逐个 Pod 调度的范畴。在 Kubernetes v1.35 中，我们引入了首批工作负载感知调度改进，其中包括基础性的 Workload API、基于 Pod 框架构建的基本编组调度支持，以及用于高效处理相同 Pod 的机会性批处理特性。

Kubernetes v1.36 通过清晰分离 API 关注点，引入了一项重要的架构演进： Workload API 充当静态模板，而新的 PodGroup API 负责处理运行时状态。为了支持这一点，kube-scheduler 提供了新的 PodGroup 调度周期，支持以原子方式处理工作负载，并为未来增强铺平道路。此版本还首次推出了拓扑感知调度和工作负载感知抢占的初始迭代，以推进调度能力。此外，工作负载的 ResourceClaim 支持为 PodGroup 解锁了动态资源分配（DRA）。最后，为了展示其面向真实场景的就绪程度，v1.36 交付了 Job 控制器与新 API 集成的第一阶段。

Workload 和 PodGroup API 更新

Workload API 现在用作静态模板，而新的 PodGroup API 描述运行时对象。 Kubernetes v1.36 将 Workload 和 PodGroup API 作为 scheduling.k8s.io/v1alpha2 API 组的一部分引入，完全替代此前的 v1alpha1 API 版本。

在 v1.35 中，Pod 组及其运行时状态嵌入在 Workload 资源中。新模型解耦了这些概念：Workload 现在充当静态模板对象，而 PodGroup 负责管理运行时状态。这种分离也提升了性能和可扩缩性，因为 PodGroup API 允许按副本对状态更新进行分片。

由于 Workload API 仅作为模板存在，kube-scheduler 的逻辑得以简化。调度器可以直接读取 PodGroup；PodGroup 包含调度器所需的全部信息，因此调度器无需监视或解析 Workload 对象本身。

更新后的配置如下所示。工作负载控制器（例如 Job 控制器）定义 Workload 对象，而这个对象现在充当 Pod 组的静态模板：

apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  # Pod 组现在定义为模板，
  # 其中包含 PodGroup 对象的 spec 字段。
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        # 仅当 4 个 Pod 可以同时运行时，此 gang 才可调度
        minCount: 4

随后，控制器基于这些模板生成运行时 PodGroup 实例。 PodGroup 运行时对象保存实际的调度策略，并引用创建它所用的模板。它还包含一个状态字段，其中的状况会映射各个 Pod 的状态，反映这个组的整体调度状态：

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-job-workers-pg
  namespace: some-ns
spec:
  # PodGroup 引用其来源 Workload 模板。
  # 相比之下，.metadata.ownerReferences 指向“真正的”工作负载对象，
  # 例如 Job。
  podGroupTemplateRef:
    workload:
      workloadName: training-job-workload
      podGroupTemplateName: workers
  # 实际的调度策略放在运行时 PodGroup 中
  schedulingPolicy:
    gang:
      minCount: 4
status:
  # status 包含映射各个 Pod 状况的状况信息。
  conditions:
  - type: PodGroupScheduled
    status: "True"
    lastTransitionTime: 2026-04-03T00:00:00Z

最后，为了将这一新架构与各个 Pod 衔接起来，Pod API 中的 workloadRef 字段已被 schedulingGroup 字段替代。创建 Pod 时，你可以将它们直接关联到运行时 PodGroup：

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  # workloadRef 字段已被 schedulingGroup 替代
  schedulingGroup:
    podGroupName: training-job-workers-pg
  ...

通过将 Workload 保持为静态模板，并将 PodGroup 提升为一等、独立的 API，我们为在未来 Kubernetes 版本中构建高级工作负载调度能力奠定了坚实基础。

PodGroup 调度周期和编组调度

为了高效管理这些工作负载，kube-scheduler 现在提供了专用的 PodGroup 调度周期。调度器不再逐个 Pod 顺序评估和预留资源，因为这种方式存在调度死锁风险；它会把整个组作为一个统一操作来评估。

当调度器从调度队列中弹出某个 PodGroup 成员时，无论该组使用哪种具体策略，它都会获取该组中其余已排队的 Pod，以确定性方式对它们排序，并按如下方式执行一个原子的调度周期：

调度器对集群状态获取一次快照，以避免竞态条件，并确保在评估整个组时保持一致性。
随后，调度器尝试使用 PodGroup 调度算法为组内所有 Pod 找到有效的 Node 放置方案；该算法会利用标准的基于 Pod 的过滤和评分阶段。
根据算法结果，调度决策会以原子方式应用到整个 PodGroup。
- 成功：如果找到了放置方案且满足组约束，可调度的成员 Pod 会一起直接进入绑定阶段。其余仍不可调度的 Pod 会返回调度队列，等待可用资源，以便之后加入已调度的 Pod。
  
  （注意：如果在某些 Pod 已经调度后，又有新的 Pod 添加到 PodGroup，这个周期会在考虑已有 Pod 的同时评估新 Pod。关键在于，已经分配到 Node 的 Pod 会继续运行。即使该组在后续周期中未能满足其要求，调度器也不会取消分配或驱逐这些 Pod。）
- 失败：如果该组未能满足其要求，整个组会被视为不可调度。不会绑定任何 Pod，这些 Pod 会返回调度队列，并在退避期之后稍后重试。

这个周期是编组调度的基础。当你的工作负载需要严格的全有或全无放置时， gang 策略会利用这个周期，防止部分部署造成资源浪费和潜在死锁。

虽然调度器仍会在满足 minCount 要求之前将 Pod 保留在 PreEnqueue 中，但实际调度阶段现在完全依赖新的 PodGroup 周期。具体而言，在算法执行期间，调度器会验证可调度 Pod 的数量是否满足 minCount。如果集群无法容纳所需的最小数量，则不会绑定任何 Pod。该组调度失败，并等待释放出足够资源。

局限性

PodGroup 调度周期的首个版本存在一些局限性：

对于基本的同构 Pod 组（即所有 Pod 具有相同调度要求，且不存在亲和性、反亲和性或拓扑分布约束等 Pod 间依赖的 Pod 组），如果存在可行的放置方案，算法预计能够找到它。
对于异构 Pod 组，即使存在有效的放置方案，也不保证一定能找到，哪怕这个方案看起来很简单。
对于存在 Pod 间依赖的 Pod 组，即使存在有效的放置方案，也不保证一定能找到。

除上述情况外，对于涉及组内依赖的场景（例如某个 Pod 的可调度性通过 Pod 间亲和性依赖于另一个组成员），由于该算法采用确定性的处理顺序，无论集群状态如何，都可能无法找到放置方案。

拓扑感知调度

对于 AI/ML 训练或批处理这类复杂分布式工作负载，将 Pod 随机放置到整个集群中可能引入显著的网络延迟，并成为整体性能瓶颈。

拓扑感知调度通过允许你直接在 PodGroup 上定义拓扑约束来解决这个问题，确保其 Pod 被共同放置在特定的物理或逻辑域内：

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: topology-aware-workers-pg
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  # 强制 Pod 根据机架拓扑共同放置
  schedulingConstraints:
    topology:
      - key: topology.kubernetes.io/rack

在这个示例中，kube-scheduler 会尝试将 Pod 调度到符合 rack 拓扑约束的多种 Node 组合上。随后，它会根据 PodGroup 利用资源的效率，以及在该域内可以成功调度多少 Pod，选择最优放置方案。

为实现这一点，调度器用一个专用的、基于放置方案的算法扩展了 PodGroup 调度周期；该算法包含三个阶段：

根据组的调度约束生成候选放置方案（理论上适合分配给 PodGroup 的 Node 子集）。拓扑感知调度插件使用新的 PlacementGenerate 扩展点创建这些放置方案。
评估每个候选放置方案，确认整个 PodGroup 是否实际能够放入其中。
对所有可行的放置方案打分，为 PodGroup 选择最合适的方案。拓扑感知调度插件使用新的 PlacementScore 扩展点对这些放置方案进行打分。

目前，拓扑感知调度不会触发 Pod 抢占来满足约束。不过，我们计划在即将到来的版本中，将工作负载感知抢占与拓扑约束集成起来。

虽然 Kubernetes v1.36 交付了这一基础性的拓扑感知调度能力， Kubernetes 项目计划很快扩展其能力。未来更新将引入对多级拓扑、软约束（偏好）的支持，与动态资源分配（DRA）的更深度集成，以及在与 basic 调度策略配合使用时更稳健的行为。

工作负载感知抢占

为了支持新的 PodGroup 调度周期，Kubernetes v1.36 引入了一种新的抢占机制，称为工作负载感知抢占。当某个 PodGroup 无法调度时，调度器会利用这一机制尝试让该 PodGroup 的调度成为可能。

与标准逐个 Pod 调度周期中使用的默认抢占相比，这种新机制会将整个 PodGroup 视为单个抢占者单元。它不会在每个 Node 上单独评估抢占牺牲者，而是在整个集群范围内搜索。这允许调度器同时从多个 Node 抢占 Pod，从而为随后调度整个 PodGroup 腾出足够空间。

工作负载感知抢占还直接向 PodGroup API 引入了两个额外概念：

PodGroup priority：覆盖构成 PodGroup 的各个 Pod 的优先级。
PodGroup disruptionMode：指定 PodGroup 中的 Pod 是否可以独立被抢占，或者是否必须以全有或全无的方式一起被抢占。

在 Kubernetes v1.36 中，只有工作负载感知抢占机制会遵从这些字段。负责这组特性的人员希望在未来版本中，将这些字段的支持扩展到其他中断来源，包括逐个 Pod 调度周期中使用的默认抢占。

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: victim-pg
spec:
  priorityClassName: high-priority
  priority: 1000
  disruptionMode: PodGroup

在这个示例中，当调度器在工作负载感知抢占周期中将 victim-pg 作为潜在抢占牺牲者进行评估时，它会使用 1000 作为其优先级，并以严格的全有或全无方式抢占该 PodGroup。

工作负载的 DRA ResourceClaim 支持

自 Kubernetes v1.34 正式可用以来，DRA 已经让 Pod 能够对 GPU、TPU 和 NIC 等设备提出详细请求。所请求的设备可以由多个按名称请求同一个 ResourceClaim 的 Pod 共享。其他请求可以通过 ResourceClaimTemplate 进行复制；在这种情况下，Kubernetes 会为每个引用该模板的 Pod 生成一个名称非确定性的 ResourceClaim。然而，对于需要让某些 Pod 共享某些设备的大规模工作负载，目前仍需要自行管理各个 ResourceClaim 的创建。

现在，除了 Pod 之外，PodGroup 也可以表示 ResourceClaimTemplate 的可复制单元。对于 PodGroup 的某个 spec.resourceClaims 所引用的 ResourceClaimTemplate，无论组内有多少 Pod，Kubernetes 都会为整个 PodGroup 生成一个 ResourceClaim。当 Pod 中用于 ResourceClaimTemplate 的某个 spec.resourceClaims 与其 PodGroup 中的某个 spec.resourceClaims 匹配时，该 Pod 的申领会解析为为 PodGroup 生成的 ResourceClaim，并且不会为这个单独的 Pod 生成 ResourceClaim。 Workload 对象中的单个 PodGroupTemplate 可以表达一种资源请求：这种请求既会为每个不同的 PodGroup 复制，又可由每个组内的 Pod 共享。

下面的示例展示了两个 Pod 请求同一个 ResourceClaim；这个 ResourceClaim 是从其 PodGroup 的 ResourceClaimTemplate 生成的：

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-job-workers-pg
spec:
  ...
  resourceClaims:
    - name: pg-claim
      resourceClaimTemplateName: my-claim-template
---
apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-workers-pg-pod-1
spec:
  ...
  schedulingGroup:
    podGroupName: training-job-workers-pg
  resourceClaims:
    - name: pg-claim
      resourceClaimTemplateName: my-claim-template
---
apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-workers-pg-pod-2
spec:
  ...
  schedulingGroup:
    podGroupName: training-job-workers-pg
  resourceClaims:
    - name: pg-claim
      resourceClaimTemplateName: my-claim-template

此外，PodGroup 通过 resourceClaimName 引用的 ResourceClaim，或通过 resourceClaimTemplateName 生成的申领，都会为整个 PodGroup 预留。此前，kube-scheduler 只能在 ResourceClaim 的 status.reservedFor 字段中列出各个 Pod，而该字段限制为 256 个条目。现在，status.reservedFor 中的单个 PodGroup 引用可以表示远多于 256 个 Pod，从而允许设备的高基数共享。

这些变更结合起来，使具有复杂拓扑的大规模工作负载能够利用 DRA 实现可扩缩的设备管理。

与 Job 控制器集成

在 Kubernetes v1.36 中，Job 控制器可以代表你创建和管理 Workload 与 PodGroup 对象，因此表示紧耦合并行应用（例如分布式 AI 训练）的 Job 无需任何额外工具即可进行编组调度。如果没有这种集成，你需要自行创建 Workload 和 PodGroup，并将它们的引用连接到 Pod 模板中。现在，Job 控制器以原生方式自动化了这一过程。

启用 EnableWorkloadWithJob 特性门控后，Job 控制器会自动：

为每个符合条件的 Job 创建一个 Workload 和对应的运行时 PodGroup；
在 Job 创建的每个 Pod 上设置 .spec.schedulingGroup，使调度器将它们视为一个 gang；
将 Job 设置为所生成对象的属主，因此这些对象会在 Job 被删除时被垃圾收集。

什么时候会触发集成？

为了让首个特性迭代保持可预测，只有当 Job 具有定义明确且固定的形态时， Job 控制器才会创建 Workload 和 PodGroup：

.spec.parallelism 大于 1
.spec.completionMode 设置为 Indexed
.spec.completions 等于 .spec.parallelism
Pod 模板上尚未设置 schedulingGroup

这些条件描述了编组调度可以推理的一类 Job：每个 Pod 都具有稳定身份（Indexed），gang 的规模在准入时已知且固定（parallelism == completions），并且没有其他控制器已经声明调度责任（schedulingGroup 字段未设置）。不满足这些条件的 Job 会像以前一样逐个 Pod 调度。

如果你自行在 Pod 模板上设置 schedulingGroup （例如因为有更高层的控制器正在管理该工作负载）， Job 控制器会保持 Pod 模板不变，并且不会创建自己的 Workload 或 PodGroup。这使得该特性可以安全地在已经使用外部批处理系统的集群中启用。

下面是一个符合编组调度条件的 Job 示例：

apiVersion: batch/v1
kind: Job
metadata:
  name: training-job
  namespace: job-ns
spec:
  completionMode: Indexed
  parallelism: 4
  completions: 4
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: registry.example/trainer:latest

Job 控制器会创建归此 Job 所有的 Workload 和 PodGroup，并且它创建的每个 Pod 都会携带指向所生成 PodGroup 的 .spec.schedulingGroup。随后，一旦可以使用本文前面描述的 PodGroup 调度周期同时放置全部四个 Pod，这些 Pod 就会一起调度。

尚未覆盖的内容

当前约束将这一集成限制在静态、索引化、完全并行的 Job 上。对其他工作负载形态的支持，包括弹性 Job 和其他内置控制器，由 KEP-5547 跟踪。

在未来 Kubernetes 版本中，这一集成将扩展为支持更多工作负载控制器，而当前针对 Job 的约束也可能放宽。

后续计划

工作负载感知调度的旅程并不会止步于此。面向 v1.37，社区正在积极推进：

将 Workload 和 PodGroup API 晋升到 Beta： 我们的主要目标是让 Workload 和 PodGroup API 成熟到 Beta 阶段，巩固它们在 Kubernetes 生态系统中的基础地位。作为晋升过程的一部分，我们还计划引入 minCount 可变性，以解锁弹性 Job，并允许动态工作负载高效扩缩。
多级 Workload 层次结构： 为了支持 JobSet 或通过 LeaderWorkerSet（LWS）实现的解聚推理等复杂现代 AI 工作负载，我们正在扩展架构以支持多级层次结构。我们计划引入一个新的 API，允许将多个 PodGroup 组织成层次结构，直接反映真实工作负载控制器的组织方式。
推进高级调度特性进阶： 我们专注于推动更广泛的工作负载感知调度生态系统走向成熟。这包括将拓扑感知调度和工作负载感知抢占等现有特性推进到 Beta 阶段。
统一的控制器集成 API： 为简化采用过程，我们正在开发控制器集成 API。这将为真实世界中的工作负载控制器提供一种统一、标准化的方法，用于消费工作负载感知调度能力。

这些重点领域的优先级和实现顺序可能会发生变化。敬请关注后续更新。

入门

以下所有工作负载感知调度改进在 v1.36 中均作为 Alpha 特性提供。要试用它们，你必须进行以下配置：

前提条件：Workload 和 PodGroup API 支持：在 kube-apiserver 和 kube-scheduler 上启用 GenericWorkload 特性门控，并确保启用 scheduling.k8s.io/v1alpha2 API 组。

满足前提条件后，你可以启用具体特性：

编组调度：在 kube-scheduler 上启用 GangScheduling 特性门控。
拓扑感知调度：在 kube-scheduler 上启用 TopologyAwareWorkloadScheduling 特性门控。
工作负载感知抢占：在 kube-scheduler 上启用 WorkloadAwarePreemption 特性门控（还需要启用 GangScheduling）。
工作负载的 DRA ResourceClaim 支持：在 kube-apiserver、kube-controller-manager、kube-scheduler 和 kubelet 上启用 DRAWorkloadResourceClaims 特性门控。
Job 控制器的 Workload API 集成：在 kube-apiserver 和 kube-controller-manager 上启用 WorkloadWithJob 特性门控。

我们鼓励你在测试集群中试用工作负载感知调度，并分享你的经验，以帮助塑造 Kubernetes 调度的未来。你可以通过以下方式发送反馈：

通过 Slack（#workload-aware-scheduling）联系我们。
参加 SIG Scheduling 会议。
在 Kubernetes 仓库中提交新的 issue。

了解更多

要深入了解这些特性的架构和设计，请阅读以下 KEP：

Kubernetes v1.36：Kubernetes PSI 指标升级到 GA

Tue, 12 May 2026 10:35:00 -0800

自 2018 年在 Linux 内核中首次实现以来， Pressure Stall Information（PSI）为用户提供了在资源饱和演变为停机之前识别它所需的高保真信号。与传统的利用率指标不同，PSI 以 CPU、内存和 I/O 的时间百分比形式，清晰地展示了任务停滞和时间损失的情况。

随着 Kubernetes v1.36 的发布，生态系统中的用户现在拥有一个稳定、可靠的接口，可在节点、Pod 和容器级别观察资源竞争情况。在本文中，我们将深入探讨证明其已准备好投入生产的改进和性能测试。

超越利用率：为什么选择 PSI？

仅监控 CPU 或内存使用情况可能会产生误导。一个节点可能报告 XX%（低于 100%）的 CPU 利用率，而某些任务却因调度延迟而经历严重延迟。PSI 通过提供以下信息填补了这一空白：

累计总计：处于停滞状态的绝对时间。
移动平均值：10 秒、60 秒和 300 秒的窗口，允许运维人员区分瞬时峰值和持续的资源紧张。

证明稳定性：大规模性能测试

遥测功能升级时的一个常见担忧是收集和提供指标所需的资源开销。为解决此问题，SIG Node 对各种机器类型上的高密度工作负载（80+ Pod）进行了广泛的性能验证。

我们的测试集中在两个主要场景，分别隔离 kubelet 和内核级别的收集影响：

Kernel PSI ON / kubelet Feature OFF 对比 Kernel PSI ON / kubelet Feature ON（kubelet 开销）
Kernel PSI OFF / kubelet Feature ON 对比 Kernel PSI ON / kubelet Feature ON（内核开销）

场景 1：kubelet 开销

首先，我们查看了 4 核机器上的 kubelet 使用情况（案例 1）。对于这些机器，Linux 内核默认已经在两个集群上跟踪压力（psi=1），但我们切换了 KubeletPSI 特性门控，以查看 kubelet 主动查询和暴露这些指标是否会影响资源使用。图表中看到的同步突发在幅度和频率上几乎完全相同，证实了 kubelet 的收集逻辑非常轻量级，可以无缝融入标准的内务处理周期。该特性不会影响现有的资源使用，保持在正常的 0.1 核或节点总容量的 2.5% 以内，因此对于生产规模的部署是安全的。

（案例 1）kubelet CPU 使用率对比

图 2：kubelet CPU 使用率对比。

接下来，我们在同一运行中评估了系统开销。如下列图表所示，启用 Kubelet PSI（红色）的 System CPU 使用率曲线与禁用 kubelet PSI（蓝色）的集群遵循相同模式，比基线略有预期的增加。这表明一旦操作系统跟踪 PSI（约 2.5 核）， Kubernetes 读取这些 CGroup 指标的行为对性能的影响可以忽略不计。

（案例 1）系统 CPU 使用率对比

图 1：节点系统 CPU 使用率对比。

场景 2：内核开销

换个角度，我们在 4 核机器上评估了在 Linux 内核上启用 PSI 的底层开销。通过比较使用 psi=1（COS 默认值）启动的集群与使用 psi=0 的集群，我们分离出了操作系统级簿记的确切成本。即使在 80 Pod 密度下的繁重 I/O 和 CPU 负载下，启用内核和禁用内核的集群之间的 System CPU 差异始终保持在 0.037 核 到 0.125 核 之间，即节点总容量的 0.925% - 3.125%。有一次峰值达到 0.225 核（即 5.6%），但在几秒钟内就被控制下来。这证实了内核内部跟踪在负载下非常高效。

（案例 2）节点系统 CPU 使用率对比

图 3：节点系统 CPU 使用率对比。

图 4 放大了 kubelet 进程本身，它是这些指标的主要收集器。结果表明，即使 kubelet 定期执行扫描以从 CGroup 层次结构聚合数据，其 CPU 使用率仍然非常低，峰值可互换，且没有任何峰值超过 0.25 核 或总容量的 6.25% 超过一秒。

（案例 2）kubelet CPU 使用率对比

图 4：kubelet CPU 使用率对比。

Beta（1.34）到 Stable（1.36）之间的改进

**GA 的智能指标发布：**我们改进了 kubelet 处理底层操作系统对 PSI 支持的方式。以前，如果在 Kubernetes 中启用了该特性，但底层 Linux 内核不支持 PSI（psi=0）， kubelet 会发布误导性的零值指标。当这些指标被当作真实指标而不是缺失值读取时，可能会触发误报。在 v1.36 中，kubelet 现在会在报告之前通过 CGroup 配置检测操作系统级别的 PSI 支持。这确保了压力指标仅在节点实际支持时才被收集和发布，为监控和告警系统提供更清晰的数据。

入门指南

要在你的 Kubernetes 集群中使用 PSI 指标，你的节点必须满足以下要求：

确保你的节点运行 Linux 内核版本 4.20 或更高版本，并使用 CGroup v2。
确保在操作系统级别启用 PSI（你的内核必须使用 CONFIG_PSI=y 编译，并且不得使用 psi=0 参数启动）。

从 v1.36 开始，Kubelet PSI 指标已普遍可用，你无需选择加入任何特性门控。

满足操作系统先决条件后，你可以开始使用兼容 Prometheus 的监控解决方案抓取 /metrics/cadvisor 端点，或查询 Summary API 来收集和可视化新的 PSI 指标。请注意，PSI 是 Linux 内核特性，因此这些指标在 Windows 节点上不可用。你的集群可以包含 Linux 和 Windows 节点的混合，在 Windows 节点上，kubelet 将简单地省略 PSI 指标。

如果你的集群运行的是足够新的 Kubernetes 版本，并且你是特权节点管理员，你还可以通过控制平面的 API 服务器代理到 kubelet 的 HTTP API，以从 Summary API 查看实时压力数据。

**注意：**代理到 kubelet 是一项特权操作。授予访问权限存在安全风险，因此在执行这些命令之前，请确保你拥有适当的管理权限。

CONTAINER_NAME="example-container"
kubectl get --raw "/api/v1/nodes/$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')/proxy/stats/summary" | jq '.pods[].containers[] | select(.name=="'"$CONTAINER_NAME"'") | {name, cpu: .cpu.psi, memory: .memory.psi, io: .io.psi}'

进一步阅读

如果你想深入了解这些指标是如何计算和暴露的，请查看以下资源：

致谢

PSI 指标的支持是通过 SIG Node 的协作努力开发的。特别感谢所有在该特性从 v1.33 的 Alpha、v1.34 的 Beta 到 v1.36 的 GA 整个过程中帮助设计、实现、测试、审查和文档化的贡献者。

要为此特性提供反馈，请加入 Kubernetes Node 特别兴趣小组，参与公共 Slack 频道（#sig-node）上的讨论，或在 GitHub 上提交 Issue。

反馈

如果你有反馈并想分享使用此特性的经验，请加入讨论：

SIG Node 很想了解你在生产中使用此特性的经验！

Kubernetes v1.36：卷组快照进入正式发布阶段

Fri, 08 May 2026 10:35:00 -0800

卷组快照（Volume Group Snapshots）作为 Alpha 功能在 Kubernetes v1.27 版本中引入，在 v1.32 版本中进入 Beta 阶段，并在 v1.34 版本中进入二次 Beta 阶段。我们很高兴地宣布，在 Kubernetes v1.36 版本中，卷组快照已 正式发布（GA）。

卷组快照的支持依赖于一组卷组快照的扩展 API。这些 API 允许用户为一组卷创建崩溃一致性（crash-consistent）快照。在后台，Kubernetes 使用标签选择器将多个 PersistentVolumeClaim 对象分组以进行快照。其主要目标是允许用户将该组快照恢复到新卷，并基于崩溃一致性恢复点恢复工作负载。

此功能仅支持 CSI 卷驱动程序。

卷组快照概述

某些存储系统能够创建多个卷的崩溃一致性快照。组快照是指在同一时间点从多个卷创建的副本。组快照可用于重建新卷（预填充快照数据），或将现有卷恢复到之前的状态（由快照表示）。

为什么要在 Kubernetes 中添加卷组快照？

Kubernetes 卷插件系统已经提供了一种强大的抽象机制，能够自动完成块存储和文件存储的配置、挂载、调整大小以及快照操作。所有这些特性都植根于 Kubernetes 追求的工作负载可移植性这一目标。

现有的 VolumeSnapshot API 提供了对持久卷进行快照的功能，以防止数据丢失或损坏。然而，一些存储系统支持一致性组快照，允许在同一时间点从多个卷创建快照，从而实现写入顺序的一致性。这对于包含多个卷的应用程序非常有用。例如，应用程序的数据可能存储在一个卷中，而日志存储在另一个卷中。如果这些卷的快照是在不同的时间创建的，则应用程序的数据将不一致，并且如果从这些快照恢复，则应用程序将无法正常运行。

虽然你可以先让应用程序进入静默状态，然后按顺序创建各个快照，但这个过程可能非常耗时，有时甚至根本无法实现。一致的组支持可在无需让应用程序进入静默状态的情况下，确保组内所有卷的崩溃一致性。

Kubernetes 卷组快照 API

Kubernetes 对卷组快照的支持依赖于三种用于管理快照的 API：

VolumeGroupSnapshot ：由 Kubernetes 用户（或自动化）创建，用于请求为多个持久卷声明创建卷组快照。

VolumeGroupSnapshotContent ：由快照控制器为动态创建的 VolumeGroupSnapshot 创建。它包含有关已配置集群资源（组快照）的信息。该对象与其创建的 VolumeGroupSnapshot 之间存在一对一映射关系。

VolumeGroupSnapshotClass ：由集群管理员创建，用于描述应如何创建卷组快照，包括驱动程序信息、删除策略等。

这三种 API 类型被定义为自定义资源定义 (CRD)。在正式版发布中，API 版本已提升至 v1。

正式发布中的新内容

VolumeGroupSnapshot、VolumeGroupSnapshotContent 和 VolumeGroupSnapshotClass 的 API 版本已升级为 groupsnapshot.storage.k8s.io/v1。
基于对 bete 测试版反馈的改进，增强了稳定性并修复了若干问题，其中包括 v1beta2 中引入的改进，以确保 restoreSize 报告的准确性。

如何使用 Kubernetes 卷组快照

使用 Kubernetes 创建新的组快照

定义好 VolumeGroupSnapshotClass 对象并选定要一起创建快照的卷后，你可以通过创建 VolumeGroupSnapshot 对象来请求生成新的组快照。

为你想要分组的 PVC 打标签：

% kubectl label pvc pvc-0 group=myGroup
persistentvolumeclaim/pvc-0 labeled

% kubectl label pvc pvc-1 group=myGroup
persistentvolumeclaim/pvc-1 labeled

对于动态配置，必须设置选择器，以便快照控制器可以找到具有匹配标签的 PVC，以便一起进行快照。

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
  name: snapshot-daily-20260422
  namespace: demo-namespace
spec:
  volumeGroupSnapshotClassName: csi-groupSnapclass
  source:
    selector:
      matchLabels:
        group: myGroup

动态配置需要 VolumeGroupSnapshotClass：

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshotClass
metadata:
  name: csi-groupSnapclass
driver: example.csi.k8s.io
deletionPolicy: Delete

如何使用组快照进行恢复

在恢复时，请求从属于 VolumeGroupSnapshot 的 VolumeSnapshot 对象创建新的 PersistentVolumeClaim。对属于该组快照的所有卷重复此操作。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: examplepvc-restored-2026-04-22
  namespace: demo-namespace
spec:
  storageClassName: example-sc
  dataSource:
    name: snapshot-0962a745b2bf930bb385b7b50c9b08af471f1a16780726de19429dd9c94eaca0
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOncePod
  resources:
    requests:
      storage: 100Mi

作为存储供应商，如何添加组快照支持？

要实现卷组快照功能，CSI 驱动程序必须：

实现新的组控制器服务。
实现组控制器远程过程调用 (RPC)：CreateVolumeGroupSnapshot、DeleteVolumeGroupSnapshot 和 GetVolumeGroupSnapshot。
添加组控制器能力 CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT。

更多细节请参阅 CSI 规范和 Kubernetes-CSI 驱动开发者指南。

如何了解更多信息？

卷组快照功能的设计规范。
卷组快照 API 和控制器的代码仓库。
CSI 文档中关于组快照功能的介绍。

如何参与？

与 Kubernetes 的所有项目一样，这个项目也是来自不同背景的众多贡献者共同努力的成果。向多年来积极参与、助力本项目达到正式发布（GA）阶段的所有贡献者致以诚挚的谢意：

Ben Swartzlander (bswartz)
Cici Huang (cici37)
Darshan Murthy (darshansreenivas)
Hemant Kumar (gnufied)
James Defelice (jdef)
Jan Šafránek (jsafrane)
Madhu Rajanna (Madhu-1)
Manish M Yathnalli (manishym)
Michelle Au (msau42)
Niels de Vos (nixpanic)
Leonardo Cecchi (leonardoce)
Rakshith R (Rakshith-R)
Raunak Shah (RaunakShah)
Saad Ali (saad-ali)
Wei Duan (duanwei33)
Xing Yang (xing-yang)
Yati Padia (yati1998)

如果你有兴趣参与 CSI 或 Kubernetes 存储系统任何部分的设计和开发，请加入 Kubernetes 存储特别兴趣小组（SIG）。我们始终欢迎新的贡献者。

我们还定期召开数据保护工作组会议。欢迎新成员加入我们的讨论。

Kubernetes v1.36：更多驱动程序、新特性以及下一代 DRA

Thu, 07 May 2026 10:35:00 -0800

动态资源分配（DRA）从根本上改变了平台管理员在 Kubernetes 中处理硬件加速器和专用资源的方式。在 Kubernetes v1.36 中，DRA 继续走向成熟，带来了多项特性进阶、重要的可用性改进，以及一些新的能力，包括将 DRA 的灵活性扩展到内存和 CPU 这类原生资源，并支持在 PodGroup 中使用 ResourceClaim。

驱动程序的可用性也在持续扩展。除了专用计算加速器之外，这一生态系统也已经支持网络设备及其他硬件类型，这反映出它正迈向更稳健、不过度绑定特定硬件的基础设施。

无论你是在管理大规模 GPU 资源池，需要更好地处理故障，还是只是希望找到更好的方式来定义资源候选/回退选项， DRA 在 v1.36 中的升级都会对你有所帮助。下面我们来看看这些新特性和进阶内容。

特性进阶

社区一直在努力稳定 DRA 的核心概念。在 Kubernetes 1.36 中，多项备受期待的特性已经进入 Beta 和稳定阶段。

按优先级排序的列表（Stable）

硬件异构是大多数集群中的现实情况。使用按优先级排序的列表特性，你可以在请求设备时明确指定回退偏好。你无需将对特定设备型号的请求硬编码，而是可以指定一个有序的偏好列表（例如，“给我一块 H100，如果没有可用的，就回退到 A100”）。调度器会按顺序评估这些请求，从而显著提升调度灵活性和集群利用率。

扩展资源支持（Beta）

随着 DRA 成为资源分配的标准，弥合与既有机制之间的差距就变得至关重要。 DRA 的扩展资源特性允许用户通过 Pod 上传统的扩展资源方式来请求资源。这使得向 DRA 的过渡可以循序渐进，也就是说，集群运维人员可以将集群迁移到 DRA，而让应用开发者按照自己的节奏采用 ResourceClaim API。

可切分设备（Beta）

硬件加速器能力强大，而有时单个工作负载并不需要整个设备。可切分设备特性为 DRA 原生提供了支持，能够根据工作负载需求，将物理硬件动态切分为更小的逻辑实例（例如多实例 GPU）。这使管理员能够在多个 Pod 之间安全且高效地共享昂贵的加速器。

设备污点（Beta）

正如你可以为 Kubernetes Node 添加污点一样，你也可以直接为特定 DRA 设备添加污点。设备污点和容忍度让集群管理员能够更高效地管理硬件。你可以为故障设备打上污点，使其不会被普通 ResourceClaim 申领占用；也可以把特定硬件预留给专属团队、专用工作负载或实验场景。这样，只有具有匹配容忍度的 Pod 才允许申领这些带污点的设备。

设备绑定状况（Beta）

为了提升调度可靠性，Kubernetes 调度器可以使用绑定状况特性，在 Pod 所需的外部资源（例如可挂接设备或 FPGA）完全就绪之前，推迟将 Pod 绑定到节点。通过显式地对资源就绪状态建模，这一特性能够防止过早分配导致 Pod 失败，从而确保部署过程更加稳健且可预测。

资源健康状态（Beta）

对于运行在专用硬件上的工作负载来说，知道设备何时故障或变得不健康至关重要。借助资源健康状态， Kubernetes 直接在 Pod 状态中暴露设备健康信息，为用户和控制器提供了关键的可见性，以便快速识别并响应硬件故障。该特性还支持易于阅读的健康状态消息，使问题诊断变得容易得多，而无需深入复杂的驱动日志。

新特性

除了稳定现有能力之外，v1.36 还引入了一些基础性的新特性，进一步扩展了 DRA 能支持的场景。这些特性目前均处于 Alpha 阶段，并由默认关闭的特性门控控制。

面向工作负载的 ResourceClaim 支持

为了优化依赖严格拓扑调度的大规模 AI/ML 工作负载，面向工作负载的 ResourceClaim 支持特性使 Kubernetes 能够在大规模 Pod 集合之间统一管理共享资源。通过将 ResourceClaim 或 ResourceClaimTemplate 与 PodGroup 关联起来，该特性消除了此前的扩展性瓶颈，例如可共享某个申领的 Pod 数量限制，同时也减轻了专用编排器手动管理申领的负担。

节点可分配资源

为什么 DRA 只能用于外部加速器呢？在 v1.36 中，我们引入了使用 DRA API 管理 节点可分配基础设施资源（如 CPU 和内存）的第一版实现。通过 DRA 的节点可分配资源特性，将 CPU 和内存分配纳入 DRA 体系之下，用户就可以将 DRA 的高级放置能力、NUMA 感知和优先级语义应用到标准计算资源上，从而为极细粒度的性能调优铺平道路。

DRA 资源可用性可见性

集群管理员最常提出的需求之一，就是希望更好地了解硬件容量。全新的资源池状态特性允许你查询 DRA 资源池中的设备可用性。通过创建 ResourcePoolStatusRequest 对象，你可以获得某个驱动所管理的每个资源池在某一时刻的设备数量快照，包括总数、已分配、可用和不可用。这有助于更好地集成仪表板和容量规划工具。

属性的列表类型

ResourceClaim 的约束求值机制已经调整，以便更好地处理标量值和列表值： matchAttribute 现在检查是否存在非空交集，而 distinctAttribute 则检查值是否两两不相交。

同时，CEL 中还引入了一个 includes() 函数，这使设备选择器在某个属性于标量表示和列表表示之间变化时，仍可更容易地保持可用。（includes() 函数仅可用于 DRA 表达式求值上下文。）

确定性设备选择

Kubernetes 调度器已更新：在评估设备时，会按资源池与 ResourceSlice 名称的字典序进行比较。这样一来，驱动可以更主动地影响调度过程，有助于提高吞吐量并做出更优的调度决策。 ResourceSlice 控制器工具包还会自动生成名称，使其与驱动作者在实现里声明的设备先后次序一致。

容器中可被发现的设备元数据

运行在带有 DRA 设备的节点上的工作负载，通常需要在不查询 Kubernetes API 的情况下，发现其已分配设备的详细信息，例如 PCI 总线地址或网络接口配置。借助设备元数据， Kubernetes 定义了一套标准协议，用于规定 DRA 驱动如何以带版本的 JSON 文件形式，在约定路径下向容器暴露设备属性。使用 DRA kubelet plugin library 构建的驱动可以无需额外处理即可获得这一能力；它们只需要提供元数据，其余如文件布局、 CDI bind-mount、版本控制和生命周期管理，都由该库负责处理。这为应用提供了一种一致、与驱动无关的方式来发现和使用设备元数据，从而无需再借助自定义控制器或查询 ResourceSlice 对象并从其属性中获取元数据。

后续计划

这一版本引入了大量新的动态资源分配（DRA）特性，而且相关工作仍在持续推进。展望未来，我们的路线图将聚焦于推动现有特性走向 Beta 和稳定发布阶段，同时进一步夯实 DRA 的性能、可扩展性和可靠性。在接下来的几个迭代周期中，一个关键优先事项将是与 工作负载感知调度 和 拓扑感知调度 的深度集成。

我们的一个重要目标，是推动用户从设备插件迁移到 DRA，而我们也希望你参与其中。无论你当前正在维护某个驱动，还是刚开始探索这些可能性，你的意见都至关重要。与我们一起塑造下一代资源管理能力。现在就联系我们，一起协作开发、分享反馈，或者开始构建你的第一个 DRA 驱动程序。

参与其中

一个不错的起点，是加入 WG Device Management 的 Slack 频道和会议，这些会议分别安排在适合 Americas/EMEA 和 EMEA/APAC 的时间段举行。

并非所有增强想法目前都已经作为 Issue 进行跟踪，因此，如果你想提供帮助，或者你自己也有一些想法，欢迎来和我们交流。我们在各个层面都有工作要做，从高难度核心变更，到 kubectl 的易用性增强，其中一些工作也很适合新贡献者上手。

Kubernetes v1.36：声明式验证正式发布

Tue, 05 May 2026 10:35:00 -0800

在 Kubernetes v1.36 中，Kubernetes 原生类型的声明式验证特性已正式发布（GA）。

对于用户而言，这意味着更可靠、更可预测且文档更完善的 API。通过迁移到声明式模型，该项目还为未来通过 OpenAPI 发布验证规则以及与 Kubebuilder 等生态系统工具集成奠定了基础。对于贡献者和生态系统开发者而言，这意味着可以用一个统一且易于维护的框架取代数千行手写的验证代码。

本文将介绍此次迁移的必要性、声明式验证框架的工作原理以及此正式版带来的新特性。

动机：摆脱“手写”技术债务

多年来，Kubernetes 原生 API 的验证几乎完全依赖于手写的 Go 代码。如果某个字段需要设置最小值限制，或者两个字段需要互斥，开发人员就必须编写显式的 Go 函数来强制执行这些约束。

随着 Kubernetes API 接口的扩展，这种方法导致了几个系统性问题：

技术债务：该项目积累了大约 18,000 行样板验证代码。这些代码难以维护、容易出错，并且在代码审查期间需要进行严格审查。
不一致性：由于缺乏集中式框架，验证规则有时会在不同的资源中以不一致的方式应用。
API 不透明：手写的验证逻辑难以通过编程方式发现或分析。这意味着客户端和工具无法在不查阅源代码或在运行时遇到错误的情况下，预先了解验证规则。

SIG API Machinery 提出的解决方案是声明式验证：直接在 types.go 文件中使用接口定义语言（IDL）标签（特别是 +k8s: 标记标签）来定义验证规则。

引入 `validation-gen`

声明式验证特性的核心是一个名为 validation-gen 的全新代码生成器。正如 Kubernetes 使用生成器进行深度复制、转换和默认值设置一样，validation-gen 会解析 +k8s: 标签并自动生成相应的 Go 验证函数。

这些生成的函数随后会无缝注册到 API 方案中。该生成器被设计为一个可扩展的框架，允许开发人员通过描述其要解析的标签以及应生成的 Go 逻辑来插入新的“验证器”。

一套全面的 `+k8s:` 标签

声明式验证框架引入了一套全面的标记标签，提供丰富的验证功能，并针对 Go 类型进行了高度优化。有关支持标签的完整列表，请参阅官方文档。以下列出了一些你现在将在 Kubernetes 代码库中看到的最常用标签：

存在性： +k8s:optional、+k8s:required
基本约束： +k8s:minimum=0、+k8s:maximum=100、+k8s:maxLength=16 和 +k8s:format=k8s-short-name
集合： +k8s:listType=map、+k8s:listMapKey=type
联合： +k8s:unionMember、+k8s:unionDiscriminator
不可变性： +k8s:immutable、+k8s:update=[NoSet, NoModify, NoClear]

用法示例：

type ReplicationControllerSpec struct {
    // +k8s:optional
    // +k8s:minimum=0
    Replicas *int32 `json:"replicas,omitempty"`
}

通过将这些标签直接放置在字段定义上方，约束条件就具有了自文档性，任何阅读类型定义的人都可以立即看到这些约束条件。

高级功能：“Ambient 棘轮机制”

这项工作最重要的成果之一是，验证棘轮机制现在已成为 API 的标准组成部分。过去，如果我们需要加强验证，必须先编写手动棘轮代码，等待版本发布，然后再加强验证，以避免破坏现有对象。

借助声明式验证，这种安全机制已内置。如果用户更新现有对象，验证框架会将传入的对象与 oldObject 进行比较。如果特定字段的值在语义上与其先前状态相同（即用户未对其进行更改），则新的验证规则将被忽略。这种“Ambient 棘轮机制”意味着我们可以立即以尽可能减少干扰的方式放松或加强验证。

使用 `kube-api-linter` 扩展 API 审查

达到正式发布（GA）要求我们对生成的代码绝对有信心，但我们的愿景远不止于代码验证。声明式验证是全面改进 API 审查的关键组成部分，它能使审查更轻松、更一致、更具可扩展性。

通过将验证规则从不透明的 Go 函数中移至结构化标记，我们增强了 kube-api-linter 等工具的功能。该代码检查器现在可以静态分析 API 类型并自动强制执行 API 约定，从而显著减轻 SIG API Machinery 审查人员的手动负担，并为贡献者提供即时反馈。

下一步是什么？

随着 Kubernetes v1.36 的发布，声明式验证正式上线（GA）。作为一项稳定特性，相关的 DeclarativeValidation 特性门控现在默认启用。它已成为向 Kubernetes 原生类型添加新验证规则的主要机制。

展望未来，该项目致力于更广泛地采用声明式验证。这包括迁移现有 API 中剩余的旧式手写验证代码，并要求所有新 API 和新字段都使用声明式验证。这一持续的过渡将不断降低代码库的复杂性，同时增强整个 Kubernetes API 接口的一致性和可靠性。

除了核心迁移之外，声明式验证也为更广泛的生态系统开启了令人兴奋的未来。由于验证规则现在被定义为结构化标记，而不是不透明的 Go 代码，因此它们可以被解析并反映在 Kubernetes API 服务器发布的 OpenAPI schema 中。这为 kubectl 等工具、客户端库和 IDE 等在向集群发送请求之前执行丰富的客户端验证铺平了道路。同样的声明式框架也可以被 Kubebuilder 等生态系统工具使用，从而为自定义资源定义（CRD）的作者带来更一致的开发体验。

参与其中

向声明式验证的迁移是一项持续进行的工作。虽然框架本身已经正式发布 (GA)，但仍需将旧版 API 迁移到新的声明式格式。

如果你有兴趣为 Kubernetes API Machinery 的核心做出贡献，这里是一个绝佳的起点。请查看 validation-gen 文档，查找带有 sig/api-machinery 标签的问题，并加入 Kubernetes Slack 上的 #sig-api-machinery 和 #sig-api-machinery-dev-tools 频道参与讨论（如需邀请，请访问 https://slack.k8s.io/）。你还可以参加 SIG API Machinery 会议直接参与其中。

致谢

衷心感谢所有帮助将此特性上线 GA 的朋友们：

以及 Kubernetes 社区中其他众多为此做出贡献的人。

欢迎来到 Kubernetes 验证的声明式未来！

Kubernetes v1.36：无法删除的准入策略

Mon, 04 May 2026 10:35:00 -0800

如果你曾尝试在一组 Kubernetes 集群上强制执行安全策略，你可能遇到过一个令人沮丧的先有鸡还是先有蛋的问题。你的准入策略是 API 对象，这意味着它们在有人创建之前不存在，并且任何具有适当权限的人都可以删除它们。在集群引导期间，总是存在一个窗口，此时你的策略尚未生效，并且无法阻止特权用户删除它们。

Kubernetes v1.36 引入了一个 Alpha 特性来解决这个问题： 基于清单的准入控制。它允许你将准入 Webhook 和基于 CEL 的策略定义为磁盘上的文件，由 API 服务器在启动时、处理任何请求之前加载。

我们正在填补的空白

如今，大多数 Kubernetes 策略强制执行都是通过 API 进行的。你创建 ValidatingAdmissionPolicy 或 Webhook 配置作为 API 对象，准入控制器会接收它。这在稳定状态下工作良好，但存在一些基本限制。

在集群引导期间，API 服务器开始处理请求与你的策略创建并生效之间存在一个间隙。如果你从备份恢复或从 etcd 故障中恢复，这个间隙可能会很大。

还有一个自我保护问题。准入 Webhook 和策略无法拦截对其自身配置资源的操作。 Kubernetes 跳过对 ValidatingWebhookConfiguration 等类型调用 Webhook，以避免循环依赖。这意味着具有足够权限的用户可以删除你的关键准入策略，而准入链中没有任何东西可以阻止他们。

我们 —— Kubernetes SIG API Machinery —— 希望有一种方式可以说"这些策略始终启用，到此为止。"

工作原理

你在已经通过 --admission-control-config-file 传递给 API 服务器的 AdmissionConfiguration 文件中添加一个 staticManifestsDir 字段。将其指向一个目录，将你的策略 YAML 文件放在那里，API 服务器会在开始服务之前加载它们。

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ValidatingAdmissionPolicyConfiguration
    staticManifestsDir: "/etc/kubernetes/admission/validating-policies/"

清单文件是标准的 Kubernetes 资源定义。唯一的要求是这些清单定义的所有对象必须以 .static.k8s.io 结尾。这个保留的后缀可以防止与基于 API 的配置冲突，并在查看指标或审计日志时轻松判断准入决策的来源。

以下是一个完整的示例，拒绝 kube-system 之外的特权容器：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "deny-privileged.static.k8s.io"
  annotations:
    kubernetes.io/description: "Deny launching privileged pods, anywhere this policy is applied"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]
  variables:
  - name: allContainers
    expression: >-
      object.spec.containers +
      (has(object.spec.initContainers) ? object.spec.initContainers : []) +
      (has(object.spec.ephemeralContainers) ? object.spec.ephemeralContainers : [])
  validations:
  - expression: >-
      !variables.allContainers.exists(c,
      has(c.securityContext) && has(c.securityContext.privileged) &&
      c.securityContext.privileged == true)
    message: "Privileged containers are not allowed"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "deny-privileged-binding.static.k8s.io"
  annotations:
    kubernetes.io/description: "Bind deny-privileged policy to all namespaces except kube-system"
spec:
  policyName: "deny-privileged.static.k8s.io"
  validationActions:
  - Deny
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: "kubernetes.io/metadata.name"
        operator: NotIn
        values: ["kube-system"]

保护以前无法保护的内容

我们最兴奋的部分是能够拦截对准入配置资源本身的操作。

使用基于 API 的准入，Webhook 和策略永远不会在 ValidatingAdmissionPolicy 或 ValidatingWebhookConfiguration 等类型上调用。这个限制存在是有充分理由的：如果 Webhook 可以拒绝对其自身配置的更改，你可能会被锁定，无法通过 API 修复它。

基于清单的策略没有这个问题。如果一个错误的策略阻止了它不应该阻止的东西，你可以修复磁盘上的文件，API 服务器会接收到更改。不存在循环依赖，因为恢复路径不通过 API。

这意味着你可以编写一个基于清单的策略来防止删除关键的基于 API 的准入策略。对于管理共享集群的平台团队来说，这是一个重大改进。你现在可以保证你的基线安全策略不会被集群管理员删除，无论是意外还是故意。

以下是实际应用中的示例。此策略防止修改或删除带有 platform.example.com/protected: "true" 标签的准入资源：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "protect-policies.static.k8s.io"
  annotations:
    kubernetes.io/description: "Prevent modification or deletion of protected admission resources"
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: ["admissionregistration.k8s.io"]
      apiVersions: ["*"]
      operations: ["DELETE", "UPDATE"]
      resources:
      - "validatingadmissionpolicies"
      - "validatingadmissionpolicybindings"
      - "validatingwebhookconfigurations"
      - "mutatingwebhookconfigurations"
  validations:
  - expression: >-
      !has(oldObject.metadata.labels) ||
      !('platform.example.com/protected' in oldObject.metadata.labels) ||
      oldObject.metadata.labels['platform.example.com/protected'] != 'true'
    message: "Protected admission resources cannot be modified or deleted"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: "protect-policies-binding.static.k8s.io"
  annotations:
    kubernetes.io/description: "Bind protect-policies policy to all admission resources"
spec:
  policyName: "protect-policies.static.k8s.io"
  validationActions:
  - Deny

有了这个策略，任何带有 platform.example.com/protected: "true" 标签的基于 API 的准入策略或 webhook 配置都受到保护，不会被篡改。保护本身存储在磁盘上，无法通过 API 删除。

需要知道的几件事

基于清单的配置故意设计为自包含的。它们不能引用 API 资源，这意味着策略没有 paramKind，准入 Webhook 没有 Service 引用（而是仅使用 URL），并且绑定只能引用同一清单集中的策略。这些限制存在是因为配置需要在没有任何集群状态的情况下工作，包括在 etcd 可用之前的启动阶段。

如果你运行多个 API 服务器实例，每个实例独立加载自己的清单文件。没有内置的跨服务器同步。这与其他基于文件的 API 服务器配置（如静态加密）的模型相同。启用此特性后，Kubernetes 会在相关指标上公开配置哈希作为标签，因此你可以检测漂移。

文件在运行时会被监视更改，因此你无需重启 API 服务器即可更新策略。如果你更新清单文件，API 服务器会验证新配置并原子性地切换到新配置。如果验证失败，它会保留之前的良好配置并记录错误。这意味着你可以使用标准配置管理工具（Ansible、Puppet，甚至挂载的 ConfigMap）在整个集群中推出策略更改，而不会导致 API 服务器停机。

启动时的初始加载更加严格：如果任何清单无效，API 服务器将不会启动。这是有意为之的。在启动时，快速失败比没有预期策略运行更安全。

尝试一下

要在 Kubernetes v1.36 中尝试此特性：

为每个 kube-apiserver 启用 ManifestBasedAdmissionControlConfig 特性门控。
创建一个包含静态清单文件的目录。如果需要将其挂载到 API 服务器运行的 Pod 中，请进行挂载。只读模式即可。
在你的 AdmissionConfiguration 中配置 staticManifestsDir，指定目录路径。
使用 --admission-control-config-file 指向你的 AdmissionConfiguration 文件启动 API 服务器。

完整文档位于 Manifest-Based Admission Control，你可以关注 KEP-5793 了解持续进展。

我们很想听听你的反馈。请在 Kubernetes Slack 上的 #sig-api-machinery 频道联系我们（如需邀请，请访问 https://slack.k8s.io/）。

如何参与

如果你有兴趣为这个特性或其他 SIG API Machinery 项目做出贡献，请加入 Kubernetes Slack 上的 #sig-api-machinery。也欢迎你参加 SIG API Machinery 会议，每两周周三举行一次。

Kubernetes v1.36：Pod 级资源管理器（Alpha）

Fri, 01 May 2026 10:35:00 -0800

Kubernetes v1.36 将 Pod 级资源管理器作为 Alpha 特性引入，为对性能敏感的工作负载带来了一种更灵活、更强大的资源管理模型。这一增强将 kubelet 的拓扑管理器（Topology Manager）、CPU 管理器和内存管理器扩展为支持 Pod 级别资源规约（.spec.resources），使它们从严格按容器分配的模型演进为以 Pod 为中心的模型。

为什么需要 Pod 级资源管理器？

当运行机器学习（ML）训练、高频交易应用或低延迟数据库这类对性能要求严苛的工作负载时，你通常需要为主要应用容器分配独占且经过 NUMA 对齐的资源，以确保性能可预测。

不过，现代 Kubernetes Pod 很少只包含一个容器。它们通常还会包含用于日志、监控、服务网格或数据摄取的边车容器。

在这一特性出现之前，这会带来一种取舍：为了让主应用获得 NUMA 对齐的独占资源，你必须为 Pod 中的每一个容器都分配基于整数的独占 CPU 资源。这对于轻量级边车来说可能是一种浪费。如果不这样做，你就会完全失去该 Pod 的 Guaranteed 服务质量（QoS）类，同时失去相应的性能收益。

引入 Pod 级资源管理器

为资源管理器启用 Pod 级别资源支持（通过 PodLevelResourceManagers 和 PodLevelResources 特性门控）后，kubelet 就能够创建混合资源分配模型。这为高性能工作负载带来了灵活性和效率，同时又不牺牲 NUMA 对齐。

真实世界中的用例

下面通过几个实际场景说明，在不同的拓扑管理器作用域下，这一特性可以如何应用：

1. 紧密耦合的数据库（拓扑管理器的 `pod` 作用域）

假设有一个对延迟敏感的数据库 Pod，其中包含一个主数据库容器、一个本地指标导出器，以及一个备份代理边车容器。

当配置为拓扑管理器的 pod 作用域时，kubelet 会基于整个 Pod 的资源预算执行一次统一的 NUMA 对齐。数据库容器会从该 NUMA 节点获得自己的独占 CPU 和内存切片。 Pod 预算中的剩余资源会形成一个新的 Pod 共享池。指标导出器和备份代理运行在这个 Pod 共享池中。它们彼此共享资源，但会与数据库的独占切片以及节点其余部分严格隔离。

这样一来，你就可以安全地将辅助容器与主工作负载放置在同一个 NUMA 节点上，同时又不必为这些辅助容器浪费专用核心。

apiVersion: v1
kind: Pod
metadata:
  name: tightly-coupled-database
spec:
  # Pod 级别资源定义整体预算和 NUMA 对齐规模。
  resources:
    requests:
      cpu: "8"
      memory: "16Gi"
    limits:
      cpu: "8"
      memory: "16Gi"
  initContainers:
  - name: metrics-exporter
    image: metrics-exporter:v1
    restartPolicy: Always
  - name: backup-agent
    image: backup-agent:v1
    restartPolicy: Always
  containers:
  - name: database
    image: database:v1
    # 这个 Guaranteed 容器从 Pod 预算中获得独占的 6 个 CPU 切片。
    # 剩余的 2 个 CPU 和 4Gi 内存会构成供边车使用的 Pod 共享池。
    resources:
      requests:
        cpu: "6"
        memory: "12Gi"
      limits:
        cpu: "6"
        memory: "12Gi"

2. 带基础设施边车的 ML 工作负载（拓扑管理器的 `container` 作用域）

设想一个 Pod 运行着 GPU 加速的 ML 训练工作负载，同时还带有一个通用的服务网格边车。

在拓扑管理器的 container 作用域下，kubelet 会逐个评估每个容器。你可以为 ML 容器分配独占且经过 NUMA 对齐的 CPU 和内存，以获得最佳性能。与此同时，服务网格边车并不需要进行 NUMA 对齐；它可以运行在节点范围内的通用共享池中。总体资源消耗仍会安全地受整个 Pod 的限制值约束，但你只需要把 NUMA 对齐的独占资源分配给那些真正需要它们的特定容器。

apiVersion: v1
kind: Pod
metadata:
  name: ml-workload
spec:
  # Pod 级别资源定义整体预算约束。
  resources:
    requests:
      cpu: "4"
      memory: "8Gi"
    limits:
      cpu: "4"
      memory: "8Gi"
  initContainers:
  - name: service-mesh-sidecar
    image: service-mesh:v1
    restartPolicy: Always
  containers:
  - name: ml-training
    image: ml-training:v1
    # 在 `container` 作用域下，这个 Guaranteed 容器会获得独占且经过 NUMA 对齐的资源，
    # 而边车则运行在节点的共享池中。
    resources:
      requests:
        cpu: "3"
        memory: "6Gi"
      limits:
        cpu: "3"
        memory: "6Gi"

CPU 配额（CFS）与隔离

当在一个 Pod 内运行这些混合工作负载时，隔离机制会根据分配方式的不同而有所区别：

独占容器： 获得独占 CPU 切片的容器会在容器级别禁用 CPU CFS 配额限制，这样它们运行时就不会被 Linux 调度器限流。
Pod 共享池容器： 落入 Pod 共享池的容器会在 Pod 级别应用 CPU CFS 配额限制，以确保它们不会消耗超过 Pod 剩余预算的资源。

如何启用 Pod 级资源管理器

使用这一特性需要 Kubernetes v1.36 或更高版本。要启用它，你必须为 kubelet 配置相应的特性门控和策略：

启用 PodLevelResources 和 PodLevelResourceManagers 特性门控。
将拓扑管理器配置为 none 之外的策略（即 best-effort、restricted 或 single-numa-node）。
在 KubeletConfiguration 中使用 topologyManagerScope 字段，将拓扑管理器作用域设置为 pod 或 container。
将 CPU 管理器配置为 static 策略。
将内存管理器配置为 Static 策略。

可观测性

为了帮助集群管理员监控并调试这些新的分配模型，我们在启用该特性门控时引入了几个新的 kubelet 指标：

resource_manager_allocations_total：统计某个管理器执行独占资源分配的总次数。 source 标签（"pod" 或 "node"）用于区分分配来源于节点级资源池，还是来源于预先分配的 Pod 级资源池。
resource_manager_allocation_errors_total：统计独占资源分配过程中出现的错误次数，并通过目标分配 source（"pod" 或 "node"）进行区分。
resource_manager_container_assignments：跟踪以特定分配类型运行的容器累计数量。 assignment_type 标签（"node_exclusive"、"pod_exclusive"、"pod_shared"）让你能够看到工作负载是如何分布的。

当前的限制与注意事项

虽然这一特性带来了新的可能性，但在其 Alpha 阶段仍有几点需要留意。有关兼容性、要求以及降级说明的完整细节，请务必查阅官方文档中的限制与注意事项。

开始使用并提供反馈

若要深入了解这一特性的技术细节和配置方式，请参阅官方概念文档：

Pod 级资源管理器

若要进一步了解 Pod 级别资源特性的整体情况，以及如何为 Pod 分配资源，请参阅：

分配 Pod 级别 CPU 和内存资源

随着这一特性在 Alpha 阶段持续演进，你的反馈尤为宝贵。欢迎通过 Kubernetes 的标准沟通渠道报告问题或分享你的使用经验：

Kubernetes v1.36：Pod 级别资源的原地垂直扩缩容升级至 Beta 版本

Thu, 30 Apr 2026 10:35:00 -0800

在 v1.34 中 Pod 级别资源升级到 Beta 版本，以及 v1.35 中原地 Pod 垂直扩缩容达到正式可用（GA）之后， Kubernetes 社区非常高兴地宣布：Pod 级别资源的原地垂直扩缩容已在 v1.36 中升级到 Beta 版本！

此特性现在通过 InPlacePodLevelResourcesVerticalScaling 特性门控默认启用。它允许用户更新运行中 Pod 的聚合 Pod 资源预算（.spec.resources），通常不需要容器重启。

为什么需要 Pod 级别的原地调整大小？

Pod 级别的资源模型通过允许容器共享一个集体资源池，简化了复杂 Pod（例如带有边车容器的 Pod）的管理。在 v1.36 中，你现在可以动态调整这个聚合边界。

这对于没有定义单个容器限制的 Pod 特别有用。这些容器会自动调整其有效边界以适应新调整大小的 Pod 级维度，允许你在高峰需求期间扩展共享池，而无需手动重新计算每个容器。

资源继承和 `resizePolicy`

当启动 Pod 级别的调整大小时，kubelet 将此更改视为每个从 Pod 级预算继承其限制的容器的调整大小事件。为了确定是否需要重启，kubelet 会参考各个容器中定义的 resizePolicy：

非破坏性更新：如果容器的 restartPolicy 设置为 NotRequired，kubelet 会尝试通过容器运行时接口（CRI）动态更新 CGroup 限制。
破坏性更新：如果设置为 RestartContainer，容器将被重启以安全应用新的聚合边界。

注意：目前，resizePolicy 不支持在 Pod 级别设置。kubelet 始终遵循各个容器的设置来决定更新是否可以原地应用或需要重启。

示例：调整共享资源池大小

在这个场景中，一个 Pod 定义了 2 CPU 的 Pod 级别限制。由于各个容器没有定义自己的限制，它们共享这个总池。

1. 初始 Pod 规范

apiVersion: v1
kind: Pod
metadata:
  name: shared-pool-app
spec:
  resources: # Pod-level limits
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: main-app
    image: my-app:v1
    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]
  - name: sidecar
    image: logger:v1
    resizePolicy: [{resourceName: "cpu", restartPolicy: "NotRequired"}]

2. 调整大小操作

要将 CPU 容量增加一倍至 4 个 CPU，请使用 resize 子资源应用补丁：

kubectl patch pod shared-pool-app --subresource resize --patch \
  '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'

节点级现实：可行性和安全性

应用调整大小补丁只是第一步。kubelet 执行多项检查并遵循特定顺序以确保节点稳定性：

1. 可行性检查

在接受调整大小之前，kubelet 会验证新的聚合请求是否适合节点的可分配容量。如果节点过度承诺，调整大小不会被忽略；相反，PodResizePending 条件会反映 Deferred 或 Infeasible 状态，提示为什么“信封”没有增长的即时反馈。

2. 更新顺序

为防止资源“超调”，kubelet 按特定顺序协调 CGroup 更新：

增加时：首先扩展 Pod 级 CGroup，在扩大各个容器 CGroup 之前创建“空间”。
减少时：首先限制容器 CGroup，然后才缩小聚合 Pod 级 CGroup。

可观测性：跟踪调整大小状态

随着升级到 Beta 版本，Kubernetes 使用 Pod 状况来跟踪调整大小的生命周期：

PodResizePending：规范已更新，但节点尚未接受更改（例如，由于容量）。
PodResizeInProgress：节点已接受调整大小（status.allocatedResources），但更改尚未完全应用到 CGroup（status.resources）。

status:
  allocatedResources:
    cpu: "4"
  resources:
    limits:
      cpu: "4"
  conditions:
  - type: PodResizeInProgress
    status: "True"

约束和要求

仅支持 CGroup v2：准确的聚合执行所必需。
CRI 支持：需要支持 UpdateContainerResources CRI 调用的容器运行时（例如 containerd v2.0+ 或 CRI-O）。
特性门控：需要 PodLevelResources、InPlacePodVerticalScaling、InPlacePodLevelResourcesVerticalScaling 和 NodeDeclaredFeatures。
仅支持 Linux：目前仅适用于基于 Linux 的节点。

下一步

在我们向正式可用（GA）迈进的过程中，社区正在专注于垂直 Pod 自动缩放器（VPA）集成，使 VPA 能够发布 Pod 级资源建议并自动触发原地执行。

开始使用并提供反馈

我们鼓励你测试此特性并通过标准的 Kubernetes 沟通渠道提供反馈：

Kubernetes v1.36：借助 Memory QoS 实现分层内存保护

Wed, 29 Apr 2026 10:35:00 -0800

我谨代表 SIG Node 宣布 Kubernetes v1.36 中 Memory QoS 特性（Alpha）的更新。 Memory QoS 使用 cgroup v2 的内存控制器，为内核提供更好的指引来处理容器内存。它最早在 v1.22 中引入，并在 v1.27 中更新。在 Kubernetes v1.36 中，我们引入了以下内容：可选启用的内存预留、基于 QoS 类的分层保护、可观测性指标，以及针对 memory.high 的内核版本告警。

v1.36 的新变化

使用 `memoryReservationPolicy` 选择性启用内存预留

v1.36 将节流与预留分离开来。启用该特性门控后，会开启 memory.high 节流（kubelet 基于 memoryThrottlingFactor 设置 memory.high，默认值为 0.9），但内存预留现在由一个独立的 kubelet 配置字段控制：

None（默认）：不写入 memory.min 或 memory.low。通过 memory.high 进行的节流仍然有效。
TieredReservation：kubelet 基于 Pod 的 QoS 类写入分层内存保护：

Guaranteed Pod 通过 memory.min 获得硬保护。例如，一个请求 512 MiB 内存的 Guaranteed Pod 会得到：

$ cat /sys/fs/cgroup/kubepods.slice/kubepods-pod6a4f2e3b_1c9d_4a5e_8f7b_2d3e4f5a6b7c.slice/memory.min
536870912

内核在任何情况下都不会回收这部分内存。如果无法兑现这一保证，它会对其他进程触发 OOM killer 以释放内存页。

Burstable Pod 通过 memory.low 获得软保护。对于同样请求 512 MiB 内存的 Burstable Pod：

$ cat /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod8b3c7d2e_4f5a_6b7c_9d1e_3f4a5b6c7d8e.slice/memory.low
536870912

在正常压力下，内核会避免回收这部分内存；但如果另一种选择是系统范围的 OOM，内核仍可能回收其中一部分。

BestEffort Pod 既不会获得 memory.min，也不会获得 memory.low。它们的内存仍然是完全可回收的。

与 v1.27 行为的对比

在更早的版本中，启用 MemoryQoS 特性门控后，会立即为每个带有内存请求的容器设置 memory.min。 memory.min 是一种硬预留，无论内存压力如何，内核都不会回收它。

假设一个节点有 8 GiB RAM，而 Burstable Pod 的请求总量达到 7 GiB。在更早版本中，这 7 GiB 会作为 memory.min 被锁定，从而给内核、系统守护进程或 BestEffort 工作负载留下极少余量，并增加 OOM kill 的风险。

在 v1.36 的分层预留机制下，这些 Burstable 请求会映射到 memory.low，而不是 memory.min。在正常压力下，内核仍会保护这部分内存；但在极端压力下，它可以回收其中一部分以避免系统范围的 OOM。只有 Guaranteed Pod 才会使用 memory.min，这使得硬预留保持在更低水平。

借助 v1.36 中的 memoryReservationPolicy，你可以先启用节流，观察工作负载行为，然后在节点拥有足够余量时再选择启用预留。

可观测性指标

kubelet 的 /metrics 端点会暴露两个 Alpha 级稳定性指标：

指标	说明
`kubelet_memory_qos_node_memory_min_bytes`	Guaranteed Pod 的 `memory.min` 总量
`kubelet_memory_qos_node_memory_low_bytes`	Burstable Pod 的 `memory.low` 总量

这些指标对于容量规划非常有用。如果 kubelet_memory_qos_node_memory_min_bytes 正在逐渐逼近节点的物理内存，你就知道硬预留已经变得紧张了。

$ curl -sk https://localhost:10250/metrics | grep memory_qos
# HELP kubelet_memory_qos_node_memory_min_bytes [ALPHA] Total memory.min in bytes for Guaranteed pods
kubelet_memory_qos_node_memory_min_bytes 5.36870912e+08
# HELP kubelet_memory_qos_node_memory_low_bytes [ALPHA] Total memory.low in bytes for Burstable pods
kubelet_memory_qos_node_memory_low_bytes 2.147483648e+09

内核版本检查

在版本低于 5.9 的内核上，memory.high 节流可能触发内核活锁问题。这个缺陷已在内核 5.9 中修复。在 v1.36 中，当启用该特性门控时，kubelet 会在启动时检查内核版本，如果内核版本低于 5.9 就记录一条告警日志。该特性仍然可以继续工作，这只是信息提示，并不是硬阻断。

Kubernetes 如何将 Memory QoS 映射到 cgroup v2

Memory QoS 使用四个 cgroup v2 内存控制器接口：

memory.max：硬内存限制，与之前版本一致
memory.min：硬内存保护，在 TieredReservation 下仅对 Guaranteed Pod 设置
memory.low：软内存保护，在 TieredReservation 下对 Burstable Pod 设置
memory.high：内存节流阈值，与之前版本一致

下表展示了在配置 memoryReservationPolicy: TieredReservation 时， Kubernetes 容器资源如何映射到 cgroup v2 接口。对于默认值 memoryReservationPolicy: None，不会设置 memory.min 或 memory.low。

QoS 类	`memory.min`	`memory.low`	`memory.high`	`memory.max`
Guaranteed	设置为 `requests.memory` （硬保护）	不设置	不设置（requests == limits，因此节流没有意义）	设置为 `limits.memory`
Burstable	不设置	设置为 `requests.memory` （软保护）	基于节流因子公式计算	设置为 `limits.memory` （如果已指定）
BestEffort	不设置	不设置	基于节点可分配内存计算	不设置

cgroup 层级

cgroup v2 要求父 cgroup 的内存保护值至少要与其所有子 cgroup 之和一样大。 kubelet 通过以下方式维持这一点：将 kubepods 根 cgroup 上的 memory.min 设置为所有 Guaranteed 和 Burstable Pod 内存请求之和，并将 Burstable QoS cgroup 上的 memory.low 设置为所有 Burstable Pod 内存请求之和。这样，内核就能够正确执行容器级和 Pod 级的保护值。

kubelet 直接使用 runc 的 libcontainer 库管理 Pod 级别和 QoS 类级别的 cgroup，而容器级别的 cgroup 则由容器运行时（containerd 或 CRI-O）管理。

如何使用？

前提条件

Kubernetes v1.36 或更高版本
使用 cgroup v2 的 Linux。推荐使用 5.9 或更高版本的内核；更早版本的内核也能工作，但可能会遇到活锁问题。你可以运行 mount | grep cgroup2 来验证 cgroup v2 是否已启用。
支持 cgroup v2 的容器运行时（containerd 1.6+、CRI-O 1.22+）

配置

要启用带分层保护的 Memory QoS：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: true
memoryReservationPolicy: TieredReservation  # 可选值：None（默认）、TieredReservation
memoryThrottlingFactor: 0.9  # 可选，默认值为 0.9

如果你只想启用 memory.high 节流，而不启用内存保护，可以省略 memoryReservationPolicy，或者将其设置为 None：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: true
memoryReservationPolicy: None  # 默认值

如何进一步了解？

参与其中

此特性由 SIG Node 推动。如果你有兴趣参与贡献或提供反馈，可以通过 Slack（#sig-node）、邮件列表或定期举行的 SIG Node 会议找到我们。请将缺陷报告提交到 kubernetes/kubernetes，并将增强提案提交到 kubernetes/enhancements。

Kubernetes v1.36：细粒度 kubelet API 鉴权正式发布（GA）

Fri, 24 Apr 2026 10:35:00 -0800

我谨代表 Kubernetes SIG Auth 和 SIG Node 宣布，细粒度 kubelet API 鉴权已在 Kubernetes v1.36 中正式发布（GA）！

KubeletFineGrainedAuthz 特性门控在 Kubernetes v1.32 中作为可选启用的 Alpha 特性引入，并在 v1.33 中进入 Beta 阶段（默认启用）。如今，该特性已正式发布，且特性门控被锁定为启用状态。此特性可针对 kubelet 的 HTTPS API 提供更精确、遵循最小权限原则的访问控制，替代在常见监控与可观测性场景下授予范围过宽的 nodes/proxy 权限的做法。

动机：`nodes/proxy` 问题

kubelet 暴露了一个 HTTPS 端点，其中包含多个 API，可访问敏感程度不同的数据，包括 Pod 列表、节点指标、容器日志，以及至关重要的在运行中的容器内执行命令的能力。

在此特性出现之前，kubelet 鉴权采用的是一种粗粒度模型。启用 webhook 鉴权时，几乎所有 kubelet API 路径都会映射到单一的 nodes/proxy 子资源。这意味着，任何需要从 kubelet 读取指标或健康状态的工作负载，都必须拥有 nodes/proxy 权限，而这一权限同时也赋予了在节点上运行的任意容器中执行任意命令的能力。

这有什么问题？

将 nodes/proxy 授予监控代理、日志采集器或健康检查工具，违背了最小权限原则。一旦这些工作负载中的任何一个被攻破，攻击者就能够在该节点上的每一个容器中执行命令。 nodes/proxy 权限实质上相当于节点级的超级用户能力，而将其广泛授予会显著扩大安全事件的影响范围。

这个问题多年来一直被社区充分认识到（参见 kubernetes/kubernetes#83465），也是推动此增强项 KEP-2862 的核心动因。

`nodes/proxy GET` 的 WebSocket 远程代码执行风险

实际情况比乍看起来更严重。安全研究人员在 2026 年初的研究中演示，仅凭 nodes/proxy GET 这一通常授予监控工具的最小只读权限，就可以被滥用来在可访问节点上的任意 Pod 中执行命令。

根本原因在于 WebSocket 连接的工作方式与 kubelet 将 HTTP 方法映射到 RBAC 动词的方式之间存在不匹配。 WebSocket 协议（RFC 6455）要求在初始连接握手时发起一个 HTTP GET 请求。 kubelet 会将这个 GET 映射为 RBAC get 动词，并在鉴权时不进行二次检查，以确认后续写操作所需的 create 权限是否同时存在。攻击者借助 websocat 之类的 WebSocket 客户端，可以直接访问 10250 端口上的 kubelet /exec 端点，并执行任意命令：

websocat --insecure \
  --header "Authorization: Bearer $TOKEN" \
  --protocol v4.channel.k8s.io \
  "wss://$NODE_IP:10250/exec/default/nginx/nginx?output=1&error=1&command=id"

uid=0(root) gid=0(root) groups=0(root)

细粒度 `kubelet` 鉴权如何工作

启用 KubeletFineGrainedAuthz 后，kubelet 现在会在回退到 nodes/proxy 子资源之前，先执行一次额外且更具体的鉴权检查。多个常用的 kubelet API 路径被映射到了各自专属的子资源：

`kubelet` API	资源	子资源
`/stats/*`	nodes	stats
`/metrics/*`	nodes	metrics
`/logs/*`	nodes	log
`/pods`	nodes	pods, proxy
`/runningPods/`	nodes	pods, proxy
`/healthz`	nodes	healthz, proxy
`/configz`	nodes	configz, proxy
`/spec/*`	nodes	spec
`/checkpoint/*`	nodes	checkpoint
其他所有路径	nodes	proxy

对于现在拥有细粒度子资源的端点（/pods、/runningPods/、/healthz 和 /configz），kubelet 会先针对具体子资源发送一次 SubjectAccessReview。如果该检查成功，请求即获准通过；如果失败，kubelet 会再使用粗粒度的 nodes/proxy 子资源重试，以保持向后兼容。

这种双重检查方式确保了平滑的迁移路径。已有的、依赖 nodes/proxy 权限的工作负载仍可继续运行，而新的部署则可以从一开始就采用最小权限访问方式。

这在实践中意味着什么

以 Prometheus node exporter 或某个需要从 kubelet 抓取 /metrics 的监控 DaemonSet 为例。过去，你需要像下面这样配置一个 RBAC ClusterRole：

# 旧方式：权限范围过宽
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-agent
rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get"]

这赋予了监控代理远超实际所需的访问权限。有了细粒度鉴权后，你现在可以精确限定权限范围：

# 新方式：遵循最小权限原则
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-agent
rules:
- apiGroups: [""]
  resources: ["nodes/metrics", "nodes/stats"]
  verbs: ["get"]

这样一来，监控代理就可以从 kubelet 读取 metrics 与 stats，同时完全不具备在容器中执行命令的能力。

已更新的 `system:kubelet-api-admin` `ClusterRole`

启用 RBAC 鉴权时，内置的 system:kubelet-api-admin ClusterRole 会自动更新，以包含所有新的细粒度子资源权限。这可确保已经在使用该角色的集群管理员（包括 API server 所使用的 kubelet 客户端）无需任何手动配置变更，仍然保有完整访问能力。

该角色现在包含以下权限：

nodes/proxy
nodes/stats
nodes/metrics
nodes/log
nodes/spec
nodes/checkpoint
nodes/configz
nodes/healthz
nodes/pods

升级注意事项

由于 kubelet 会执行双重鉴权检查（先细粒度检查，再回退到 nodes/proxy），升级到 v1.36 对大多数集群来说应当是无缝的：

现有工作负载：已经拥有 nodes/proxy 权限的工作负载无需任何改动即可继续运行。回退到 nodes/proxy 的机制保证了向后兼容。
API server：始终通过 system:kubelet-api-admin 拥有 nodes/proxy 权限，因此无论特性门控状态如何，kube-apiserver 与 kubelet 之间的通信都不受影响。
混合版本集群：也能被平滑处理。如果 kubelet 支持细粒度鉴权而 API server 不支持（或反过来），nodes/proxy 权限就会作为回退机制发挥作用。

验证该特性是否已启用

你可以通过检查 kubelet 的 metrics 端点，确认该特性是否在某个节点上处于启用状态。由于 10250 端口上的 metrics 端点需要鉴权，你首先需要为发起请求的 Pod 或服务账号创建适当的 RBAC 绑定。

第 1 步：创建 ServiceAccount 和 ClusterRole

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubelet-metrics-checker
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubelet-metrics-reader
rules:
- apiGroups: [""]
  resources: ["nodes/metrics"]
  verbs: ["get"]

第 2 步：将 ClusterRole 绑定到 ServiceAccount

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubelet-metrics-checker
subjects:
- kind: ServiceAccount
  name: kubelet-metrics-checker
  namespace: default
roleRef:
  kind: ClusterRole
  name: kubelet-metrics-reader
  apiGroup: rbac.authorization.k8s.io

应用这些清单：

kubectl apply -f serviceaccount.yaml
kubectl apply -f clusterrole.yaml
kubectl apply -f clusterrolebinding.yaml

第 3 步：使用该 ServiceAccount 运行一个 Pod，并检查特性标志

kubectl run kubelet-check \
  --image=curlimages/curl \
  --serviceaccount=kubelet-metrics-checker \
  --restart=Never \
  --rm -it \
  -- sh

然后在 Pod 内获取节点 IP，并查询 metrics 端点：

# 获取令牌
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

# 查询 kubelet 指标，并筛选特性门控
curl -sk \
  --header "Authorization: Bearer $TOKEN" \
  https://$NODE_IP:10250/metrics \
  | grep kubernetes_feature_enabled \
  | grep KubeletFineGrainedAuthz

如果该特性已启用，你应当会看到类似下面的输出：

kubernetes_feature_enabled{name="KubeletFineGrainedAuthz",stage="GA"} 1

注意：请将 $NODE_IP 替换为你要检查的节点 IP 地址。你可以使用 kubectl get nodes -o wide 获取节点 IP。

从 Alpha 到 GA 的历程

版本	阶段	说明
v1.32	Alpha	引入 `KubeletFineGrainedAuthz` 特性门控，默认禁用
v1.33	Beta	默认启用；为 `/pods`、`/runningPods/`、`/healthz`、`/configz` 增加细粒度检查
v1.36	GA	特性门控被锁定为启用状态；细粒度 `kubelet` 鉴权始终处于活动状态

下一步是什么？

随着细粒度 kubelet 鉴权现已 GA，Kubernetes 社区可以开始建议，并最终强制要求监控与可观测性工作负载使用特定子资源，而不是 nodes/proxy。之所以需要尽快推进这一迁移，是因为已有研究表明 nodes/proxy GET 可通过 WebSocket 协议被滥用，从而实现无日志记录的远程代码执行。这一风险存在于数十个被广泛部署的 Helm Chart 的默认 RBAC 配置中。随着时间推移，我们预计会出现以下变化：

生态系统采用：Prometheus、Datadog agent 以及其他 DaemonSet 等监控工具，可以更新其默认 RBAC 配置，改用 nodes/metrics、nodes/stats 和 nodes/pods，而不再使用 nodes/proxy。这会直接消除这些工作负载面临的 WebSocket RCE 攻击面。
策略执行：当存在细粒度替代方案时，准入控制器与策略引擎可以标记或拒绝授予 nodes/proxy 的 RBAC 绑定，帮助组织以规模化方式落实最小权限访问。
弃用路径：随着采用范围扩大，nodes/proxy 最终可能会在监控用途中被弃用，从而进一步缩小 Kubernetes 集群的攻击面。

参与其中

这一增强项由 SIG Auth 和 SIG Node 推动。如果你有兴趣为 Kubernetes 的安全与鉴权特性贡献力量，欢迎加入我们：

SIG Auth
SIG Node
Slack：#sig-auth 和 #sig-node
KEP-2862：细粒度 kubelet API 鉴权

期待听到你对这一特性的反馈与使用经验！

Kubernetes v1.36：用户命名空间终于正式可用

Thu, 23 Apr 2026 10:35:00 -0800

经过数年的开发，Kubernetes 中的用户命名空间（User Namespaces）支持已随着 v1.36 发布进入正式发布（GA）阶段。这是一个仅适用于 Linux 的特性。

对于从事底层容器运行时（Container Runtimes）和 rootless 技术的我们来说，这是一个期待已久的里程碑。我们终于走到了可以将 rootless 安全隔离用于 Kubernetes 工作负载的阶段。

这一特性还开启了一种关键模式：让工作负载在拥有特权的同时，依然被限制在用户命名空间内。当设置 hostUsers: false 时，CAP_NET_ADMIN 这类权能（capabilities）会变成 被命名空间化（namespaced） 的权能，这意味着它们只会授予容器本地资源的管理能力，而不会影响主机。这实际上开启了此前只有运行完全特权容器（fully privileged container）才能实现的新用例。

UID 0 的问题

在容器内以 root 身份运行的进程，从内核视角看，在主机上同样是 root。如果攻击者成功逃逸出容器，无论是利用内核漏洞，还是借助配置错误的挂载（misconfigured mount），他们都会在主机上获得 root 权限。

虽然运行容器时已经有许多安全防护措施，但这些措施并不会改变进程的底层身份，它依然保留着 root 的某些“部分能力”。

核心机制：ID-mapped mounts

通往 GA 的道路并不只是 Kubernetes API 的演进，更关键的是让内核真正为我们所用。在早期阶段，最大的阻碍之一是卷的所有权问题。如果你把容器映射到较高的 UID 范围，Kubelet 就必须递归地对挂载卷中的每个文件执行 chown，这样容器才能对这些文件进行读写。对于大型卷来说，这一操作的成本高得惊人，足以摧毁启动性能。

实现这一目标的关键，是 ID-mapped mounts（在 Linux 5.12 中引入，并在后续版本中持续完善）。借助这一机制，内核可以在挂载时重映射文件所有权，而不必改写磁盘上的实际所有权信息。

当一个卷被挂载到启用了用户命名空间的 Pod 中时，内核会透明地转换 UID（user ids）和 GID（group ids）。对容器来说，这些文件看起来像是由 UID 0 拥有。而在磁盘上，文件所有权完全不会变化，因此不需要执行 chown。这是一个 O(1) 操作，既即时又高效。

在 Kubernetes v1.36 中使用它

使用用户命名空间非常直接：你只需要在 Pod spec 中设置 hostUsers: false。无需修改容器镜像，也不需要复杂配置。它仍然使用 Alpha 阶段引入的同一套接口。在 Pod（或 PodTemplate）的 spec 中，你可以显式选择不使用主机用户命名空间：

apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  hostUsers: false
  containers:
  - name: app
    image: fedora:42
    securityContext:
      runAsUser: 0

如果你想进一步了解用户命名空间在实践中的工作方式，以及它如何缓解被评为 HIGH 的 CVE，请参阅此前的博客文章： User Namespaces alpha、 User Namespaces stateful pods in alpha、 User Namespaces beta，以及 User Namespaces enabled by default。

参与其中

如果你对用户命名空间感兴趣，或希望参与贡献，这里有一些有用的链接：

致谢

这一特性历经多年才走到今天：第一份 KEP 在 10 年前由其他贡献者提出，而我们在过去 6 年里一直积极推动它向前发展。我们感谢所有在 SIG Node、容器运行时以及 Linux 内核领域参与贡献的人。同时，也特别感谢那些在多个 Alpha 和 Beta 周期中帮助打磨设计的评审者与早期采用者。

SELinux 卷标签变更进入 GA 阶段（以及 v1.37 中可能的影响）

Wed, 22 Apr 2026 10:35:00 -0800

如果你在 Linux 上运行带有 SELinux 强制模式的 Kubernetes，请提前规划：未来某个版本（预计为 v1.37）预计将默认启用 SELinuxMount 特性门控。这会使大多数工作负载的卷设置更快，但它可能会破坏以微妙方式仍依赖于旧版递归重新标记模型的应用程序（例如，在同一节点上的特权和非特权 Pod 之间共享一个卷）。 Kubernetes v1.36 是审计集群、修复或选择退出此更改的正确版本。

如果你的节点不使用 SELinux，则没有任何变化：当 SELinux 在 Linux 内核中不可用或被禁用时， kubelet 会跳过整个 SELinux 逻辑。你可以完全跳过本文。

本文建立在 Kubernetes 1.27：高效的 SELinux 重新标记（Beta）一文中描述的早期工作基础上，该文介绍了 SELinuxMountReadWriteOncePod 特性门控。需要解决的问题保持不变，但是本文将相同的方法扩展到所有卷。

问题描述

启用了安全增强 Linux（SELinux）的 Linux 系统使用附加到对象（例如文件和网络套接字）上的标签来进行访问控制决策。历史上，容器运行时将 SELinux 标签应用到 Pod 及其所有卷。 Kubernetes 仅将 Pod 的 securityContext 字段中的 SELinux 标签传递给容器运行时。

然后容器运行时递归地更改对 Pod 容器可见的所有文件上的 SELinux 标签。如果卷上有许多文件，这可能非常耗时，尤其是当卷位于远程文件系统上时。

注意：

如果容器使用卷的 subPath，则只重新标记整个卷的该 subPath。这允许具有两个不同 SELinux 标签的两个 Pod 使用同一个卷，只要它们使用不同的 subpath。

如果 Pod 在 Kubernetes API 中没有分配任何 SELinux 标签，容器运行时会分配一个唯一的随机标签，这样可能逃逸容器边界的进程无法访问主机上任何其他容器中的数据。容器运行时仍会用此随机 SELinux 标签递归地重新标记所有 Pod 卷。

Kubernetes 的改进

在堆栈支持的情况下，kubelet 可以使用 -o context=<label> 挂载卷，以便内核为该挂载上的所有 inode 应用正确的标签，而无需递归遍历 inode。该路径受特性门控限制，并且需要（除其他外）Pod 暴露足够的 SELinux 标签（例如 spec.securityContext.seLinuxOptions.level），并且卷驱动程序选择加入（对于 CSI，设置 CSIDriver 字段 spec.seLinuxMount: true）。

项目分阶段推出此功能：

ReadWriteOncePod 卷在 SELinuxMountReadWriteOncePod 特性门控下处理，自 v1.28 起默认启用，在 v1.36 中达到 GA。
更广泛的覆盖范围在 SELinuxMount 标志下处理，与 Pod 上的 spec.securityContext.seLinuxChangePolicy 字段配合使用。

如果 Pod 及其卷满足所有以下条件，Kubernetes 将直接以正确的 SELinux 标签挂载卷。这种挂载将在恒定时间内完成，容器运行时无需递归地重新标记其上的任何文件。要进行此类挂载，需要满足以下条件：

操作系统必须支持 SELinux。在未检测到 SELinux 支持的情况下， kubelet 和容器运行时不会对 SELinux 执行任何操作。

特性门控 SELinuxMountReadWriteOncePod 必须启用。如果你运行的是 Kubernetes v1.36，则该特性无条件启用。

Pod 必须使用具有适用 accessModes 的 PersistentVolumeClaim：
- 要么卷具有 accessModes: ["ReadWriteOncePod"]
- 要么卷可以使用任何其他访问模式，但需要满足以下条件：特性门控 SELinuxChangePolicy 和 SELinuxMount 都已启用，并且 Pod 的 spec.securityContext.seLinuxChangePolicy 设置为 nil（默认）或 MountOption。
特性门控 SELinuxMount 在 Kubernetes 1.36 中为 Beta 阶段且默认禁用。所有其他 SELinux 相关的特性门控现在都已达到正式发布（GA）。

如果其中任何特性门控被禁用，SELinux 标签将始终通过递归遍历卷（或其 subPath）由容器运行时应用。

Pod 必须在其安全上下文中至少分配了 seLinuxOptions.level，或者该 Pod 中的所有容器都必须在容器级别的安全上下文中设置它。 Kubernetes 将从操作系统默认值（通常为 system_u、system_r 和 container_t）中读取默认的 user、role 和 type。

如果 Kubernetes 不知道 SELinux 的“级别”，容器运行时将在卷挂载后分配一个随机级别。在这种情况下，容器运行时仍会递归地重新标记卷。

负责该卷的卷插件或 CSI 驱动程序支持使用 SELinux 挂载选项进行挂载。

这些树内卷插件支持使用 SELinux 挂载选项进行挂载：fc 和 iscsi。

支持使用 SELinux 挂载选项进行挂载的 CSI 驱动程序必须通过设置 seLinuxMount 字段在其 CSIDriver 实例中声明此功能。

由其他卷插件或未设置 seLinuxMount: true 的 CSI 驱动程序管理的卷将由容器运行时递归地重新标记。

破坏性变更

SELinuxMount 特性门控以微妙的方式改变了多个 Pod 之间可以共享的卷。

以下两种情况在递归重新标记下都能正常工作：

具有不同 SELinux 标签的两个 Pod 共享同一个卷，但它们各自使用不同的 subPath 访问该卷。

特权 Pod 和非特权 Pod 共享同一个卷。

当 SELinux 处于活动状态时，上述场景将不适用于 Kubernetes 挂载的现代目标行为。相反，其中一个 Pod 将停留在 ContainerCreating 状态，直到另一个 Pod 被终止。

第一种情况非常小众，在实践中从未见过。虽然第二种情况仍然相当罕见，但已在应用程序中观察到这种设置。 Kubernetes v1.36 提供了指标和事件来识别这些 Pod，并允许集群管理员通过 Pod 字段 spec.securityContext.seLinuxChangePolicy 选择退出挂载选项。

`seLinuxChangePolicy`

新的 Pod 字段 spec.securityContext.seLinuxChangePolicy 指定如何将 SELinux 标签应用到所有 Pod 卷。在 Kubernetes v1.36 中，此字段是稳定 Pod API 的一部分。

有三个可用的选项：

字段未设置（默认）: 在 Kubernetes v1.36 中，行为取决于 SELinuxMount 特性门控是否启用。默认情况下，该特性门控未启用，SELinux 标签递归应用。如果你在集群中启用了该特性门控，并且满足所有其他条件，则将使用挂载选项应用标签。

Recursive: SELinux 标签递归应用。这选择退出使用挂载选项。

MountOption: 如果满足所有其他条件，则使用挂载选项应用 SELinux 标签。此选项仅在 SELinuxMount 特性门控启用时可用。

SELinux 警告控制器（可选）

Kubernetes v1.36 在控制平面中提供了一个新的控制器 selinux-warning-controller。此控制器在 kube-controller-manager 控制器内运行。要使用它，你需要在 kube-controller-manager 命令行上传递 --controllers=*,selinux-warning-controller；你还不能明确地将 SELinuxChangePolicy 特性门控覆盖为禁用。

控制器监视集群中的所有 Pod，当发现两个 Pod 以与 SELinuxMount 特性门控不兼容的方式共享同一卷时会发出事件。所有此类冲突的 Pod 将收到一个事件，例如：

SELinuxLabel "system_u:system_r:container_t:s0:c98,c99" conflicts with pod my-other-pod that uses the same volume as this pod with SELinuxLabel "system_u:system_r:container_t:s0:c0,c1". If both pods land on the same node, only one of them may access the volume.

当冲突的 Pod 运行在不同名字空间时，实际的 Pod 名称可能会被隐藏，以防止跨名字空间边界泄露信息。

即使这些 Pod 不在同一节点上运行，控制器也会报告此类事件，以确保所有 Pod 都能正常工作，而不考虑 Kubernetes 调度器的决定。它们下次可能会在同一节点上运行。

此外，控制器发出指标 selinux_warning_controller_selinux_volume_conflict，列出 Pod 之间所有当前的冲突。该指标具有用于识别冲突 Pod 及其 SELinux 标签的标签，例如：

selinux_warning_controller_selinux_volume_conflict{pod1_name="my-other-pod",pod1_namespace="default",pod1_value="system_u:object_r:container_file_t:s0:c0,c1",pod2_name="my-pod",pod2_namespace="default",pod2_value="system_u:object_r:container_file_t:s0:c0,c2",property="SELinuxLabel"} 1

启用此选择性加入控制器存在安全后果：它可能泄露名字空间名称，这些名称始终存在于指标中。 Kubernetes 项目假定只有集群管理员可以访问 kube-controller-manager 指标。

建议的升级路径

为确保从 v1.36 平滑升级到启用 SELinuxMount 的版本（预计为 v1.37），我们建议你按照以下步骤操作：

在 kube-controller-manager 中启用 selinux-warning-controller。

检查 selinux_warning_controller_selinux_volume_conflict 指标。它显示 Pod 之间的所有潜在冲突。对于每个冲突的 Pod（Deployment、StatefulSet 等），要么应用选择退出（设置 Pod 的 spec.securityContext.seLinuxChangePolicy: Recursive），要么重新设计应用程序以消除此类冲突。例如，你的 Pod 真的需要以特权身份运行吗？

检查 volume_manager_selinux_volume_context_mismatch_warnings_total 指标。当实际启动在 SELinuxMount 被禁用时运行的 Pod 时，此指标由 kubelet 发出，但此类 Pod 在 SELinuxMount 启用时将无法启动。此指标列出了将经历真正冲突的 Pod 数量。不幸的是，此指标不会将确切的 Pod 名称公开为标签。完整的 Pod 名称仅在 selinux_warning_controller_selinux_volume_conflict 指标中可用。

一旦两个指标都被考虑在内，升级到启用了 SELinuxMount 的 Kubernetes 版本。

考虑使用 MutatingAdmissionPolicy、变更性 Webhook 或策略引擎如 Kyverno 或 Gatekeeper 来将选择退出应用到名字空间或整个集群中的所有 Pod。

当 SELinuxMount 启用时，kubelet 将发出指标 volume_manager_selinux_volume_context_mismatch_errors_total，其中包含因 SELinux 标签与使用同一卷的现有 Pod 冲突而无法启动的 Pod 数量。如果 selinux-warning-controller 被启用，确切的 Pod 名称仍应在 selinux_warning_controller_selinux_volume_conflict 指标中可用。

进一步阅读

KEP：使用挂载加速 SELinux 卷重新标记
SELinux 卷重新标记特性门控
故事 3：集群升级
为 Pod 配置安全上下文 — 高效的 SELinux 卷重新标记和 selinux-warning-controller

致谢

如果你遇到问题、有反馈或想要贡献，请在 Kubernetes Slack 的 #sig-node 和 #sig-storage 中找到我们，或加入 SIG Node 或 SIG Storage 会议。

Kubernetes v1.36：ハル (Haru)

Wed, 22 Apr 2026 00:00:00 +0000

编辑：Chad M. Crowell、Kirti Goyal、Sophia Ugochukwu、Swathi Rao、Utkarsh Umre

与之前的版本类似，Kubernetes v1.36 的发布引入了新的稳定（GA）、Beta 和 Alpha 特性。持续交付高质量版本，凸显了我们开发周期的韧性，以及社区充满活力的支持。

此版本包含 70 项增强。其中，18 项已进阶至稳定阶段，25 项进入 Beta 阶段，25 项进阶至 Alpha 阶段。

本次发布还包含一些弃用与移除内容，请务必阅读相关说明。

发布主题与徽标

我们以 Kubernetes v1.36 开启 2026 年。这个版本到来之时，季节更迭，山间光影流转。ハル（Haru）在日语中富含多重意象；其中我们最贴近的含义包括：春（spring）、晴れ（hare，晴空）和遥か（haruka，遥远）。一个季节、一片天空和一条地平线。你将在接下来的内容中看到这三者。

该版本徽标由 avocadoneko / Natsuho Ide 创作，灵感来自葛饰北斋的《富嶽岳三十六景》（富三十六景，Fugaku Sanjūrokkei）。这一系列也诞生了了神奈川冲浪里这样的传世杰作。我们的 v1.36 徽标重新诠释了这个系列中最著名的作品之一：《凯风快晴》（凱風快晴，Gaifū Kaisei），又名赤富士（Aka Fuji）：夏日黎明中被照亮成红色、经历漫长融雪后已不覆雪的山。三十六景与 v1.36 相映成趣，也提醒我们即便是北斋也没有止步于此。¹ Kubernetes 舵轮守望着这一幕，与山一同融入天空。

富士山脚下坐着 Stella（左）和 Nacho（右），两只猫的项圈上带有 Kubernetes 舵轮，象征着狛犬的角色：守护日本神社的一对狮犬守护像。它们成对出现，因为没有什么是独自守护的。 Stella 和 Nacho 代表着远比这两对爪子庞大得多的群体： SIG 和工作组、维护者和评审者、文档、博客与翻译背后的人们、发布团队、迈出第一步的首次贡献者，以及年复一年回归的长期贡献者。一如既往，Kubernetes v1.36 由众多双手托举。

徽标中横跨赤富士的书法是“晴れに翔け”（hare ni kake），意为“翱翔于晴空”。这是一个对句的前半句，完整对句太长，无法完全放在山上：

晴れに翔け、未来よ明け
hare ni kake, asu yo ake
“翱翔于晴空；迎向明日朝阳。”²

这就是我们寄托于此版本的愿望：让这个版本、这个项目，以及共同交付它的每个人，都能翱翔于晴空。赤富士上破晓的晨光不是终点，而是一条通往未来的道路：这个版本把我们带向下一个版本，而下一个版本又会通向再下一个版本，一路迈向任何单一视角都无法穷尽的遥远地平线。

_{1. 这个系列非常受欢迎，北斋又增加了十幅版画，使总数达到四十六幅。}
_{2. “未来”表示最宽泛意义上的“未来”，不只是明天，还包括一切尚未到来的事物。它通常读作 mirai；这里采用非正式读法 asu。}

重点更新速览

Kubernetes v1.36 带来了大量新特性与改进。下面是发布团队希望重点介绍的几个更新！

稳定（GA）阶段：细粒度 API 鉴权

我们很高兴代表 Kubernetes SIG Auth 和 SIG Node 宣布：细粒度 kubelet API 鉴权在 Kubernetes v1.36 中进阶至正式发布（GA）！

KubeletFineGrainedAuthz 特性门控在 Kubernetes v1.32 中作为可选的 Alpha 特性引入，随后在 v1.33 中进阶为 Beta（默认启用）。现在，此特性已正式发布（GA）。该特性针对 kubelet 的 HTTPS API 实现了更精确、符合最小权限原则的访问控制，替代了在常见监控和可观测性用例中授予过于宽泛的 nodes/proxy 权限的需求。

此项工作是 KEP #2862 的一部分，由 SIG Auth 和 SIG Node 牵头完成。

Beta：资源健康状态

在 v1.34 发布之前，Kubernetes 缺少一种原生方式来报告已分配设备的健康状况，这使得诊断由硬件故障导致的 Pod 崩溃变得困难。在 v1.31 中聚焦于设备插件的初始 Alpha 版本基础上， Kubernetes v1.36 通过将每个 Pod 的 .status 中的 allocatedResourcesStatus 字段提升至 Beta，扩展了这一特性。此字段为所有专用硬件提供统一的健康报告机制。

用户现在可以运行 kubectl describe pod 来判断容器的崩溃循环是否由 Unhealthy 或 Unknown 设备状态导致，无论相关硬件是通过传统插件还是较新的 DRA 框架制备。这种增强的可见性使管理员和自动化控制器能够快速识别故障硬件，并简化高性能工作负载的恢复流程。

此项工作是 KEP #4680 的一部分，由 SIG Node 牵头完成。

Alpha：工作负载感知调度（WAS）特性

此前，Kubernetes 调度器和 Job 控制器将 Pod 作为独立单元进行管理，这常常会导致复杂分布式工作负载出现碎片化调度或资源浪费。 Kubernetes v1.36 引入了一整套 Alpha 阶段的工作负载感知调度（Workload-Aware Scheduling，WAS）特性，将 Job 控制器与修订后的 Workload API 以及新的解耦 PodGroup API 原生集成，从而把相关 Pod 作为单个逻辑实体处理。

Kubernetes v1.35 已经支持编组调度：它要求在任何 Pod 绑定到节点之前，至少有指定数量的 Pod 可被调度。 v1.36 更进一步，引入新的 PodGroup 调度周期，以原子方式评估整个组：组内所有 Pod 要么一起绑定，要么一个都不绑定。

此项工作跨越多个 KEP（包括 #4671、#5547、 #5832、#5732 和 #5710），由 SIG Scheduling 和 SIG Apps 牵头完成。

进阶至稳定阶段的特性

以下列出 v1.36 发布后进入稳定（GA）阶段的一些改进。

卷组快照

经过数个 Beta 周期后，VolumeGroupSnapshot 支持在 Kubernetes v1.36 中达到正式发布（GA）。此特性允许你同时为多个 PersistentVolumeClaim 创建崩溃一致性快照。卷组快照支持依赖一组用于组快照的扩展 API。这些 API 允许用户为一组卷创建崩溃一致性快照。一个关键目标是允许你将这组快照恢复到新卷，并基于某个崩溃一致性恢复点恢复工作负载。

此项工作是 KEP #3476 的一部分，由 SIG Storage 牵头完成。

可变卷挂载限制

在 Kubernetes v1.36 中，可变 CSINode 可分配数量特性进阶至稳定（GA）阶段。这一增强允许容器存储接口（CSI）驱动动态更新所报告的某个节点可处理的最大卷数量。

通过这项更新，kubelet 可以动态更新节点的卷限制和容量信息。 kubelet 会基于周期性检查，或响应来自 CSI 驱动的资源耗尽错误来调整这些限制，且无需重启组件。这确保 Kubernetes 调度器能保持对存储可用性的准确视图，避免因过期的卷限制导致 Pod 调度失败。

此项工作是 KEP #4876 的一部分，由 SIG Storage 牵头完成。

ServiceAccount 令牌外部签名 API

在 Kubernetes v1.36 中，面向 ServiceAccount 的外部 ServiceAccount 令牌签名器特性进阶至稳定（GA）阶段，使集群可以将令牌签名卸载到外部系统，同时仍能与 Kubernetes API 清晰集成。集群现在可以依赖外部 JWT 签名器签发投射的服务账户令牌，这些令牌遵循标准的服务账户令牌格式，并在需要时支持延长过期时间。这对已经依赖外部身份或密钥管理系统的集群尤其有用，因为 Kubernetes 可以与其集成，而不必在控制平面内重复管理密钥。

kube-apiserver 已被连接到外部签名器，以发现并缓存其公钥，并验证并非由 kube-apiserver 自身签发的令牌，因此现有身份认证与鉴权流程会继续按预期工作。在 Alpha 和 Beta 阶段，外部签名器插件的 API 与配置、路径验证以及 OIDC 发现都经过了加固，以便安全处理真实部署和轮换模式。

随着 v1.36 中进入 GA，外部 ServiceAccount 令牌签名现在成为一种完全受支持的选项，可供集中管理身份和签名的平台使用，简化与外部 IAM 系统的集成，并减少在控制平面内直接管理签名密钥的需求。

此项工作是 KEP #740 的一部分，由 SIG Auth 牵头完成。

进阶至稳定阶段的 DRA 特性

在 Kubernetes v1.36 中，随着关键治理和选择特性进阶至稳定（GA）阶段，动态资源分配（DRA）生态的一部分已经达到完整的生产成熟度。 DRA 管理员访问进阶至 GA，为集群管理员全局访问和管理硬件资源提供了永久且安全的框架；同时，优先级列表的稳定化确保资源选择逻辑在所有集群环境中保持一致且可预测。

现在，组织可以在长期 API 稳定性和向后兼容性的保障下，放心部署任务关键型硬件自动化。这些特性使用户能够实现复杂的资源共享策略和管理性覆盖，而这些能力对大规模 GPU 集群和多租户 AI 平台至关重要；这也标志着下一代资源管理的核心架构基础已经完成。

此项工作是 KEP #5018 和 KEP #4816 的一部分，由 SIG Auth 和 SIG Scheduling 牵头完成。

变更性准入策略

随着 MutatingAdmissionPolicy（变更准入策略）在 Kubernetes v1.36 中进阶至稳定（GA），声明式集群管理的成熟度达到新高度。这一里程碑为传统 Webhook 提供了原生、高性能的替代方案：管理员可以使用通用表达式语言（CEL）直接在 API 服务器中定义资源变更，在许多常见用例中完全替代对外部基础设施的需求。

现在，集群操作人员可以修改传入请求，而无需承担管理自定义准入 Webhook 所带来的延迟和运维复杂性。通过将变更逻辑迁移到声明式、版本化的策略中，组织可以获得更可预测的集群行为、更低的网络开销，以及在长期 API 稳定性完整保障下的强化安全模型。

此项工作是 KEP #3962 的一部分，由 SIG API Machinery 牵头完成。

使用 `validation-gen` 对 Kubernetes 原生类型进行声明式验证

随着声明式验证（使用 validation-gen）在 Kubernetes v1.36 中进阶至稳定（GA），自定义资源的开发效率达到新水平。这一里程碑允许开发者使用通用表达式语言（CEL），直接在 Go 结构体标签中定义复杂验证逻辑，从而替代手动编写复杂 OpenAPI 模式这一通常容易出错的任务。

现在，Kubernetes 贡献者无需编写自定义验证函数，而是可以直接在 API 类型定义（types.go）中使用 IDL 标记注释（例如 +k8s:minimum 或 +k8s:enum）定义验证规则。 validation-gen 工具会解析这些注释，并在编译时自动生成稳健的 API 验证代码。这降低了维护开销，并确保 API 验证与源代码保持一致和同步。

此项工作是 KEP #5073 的一部分，由 SIG API Machinery 牵头完成。

移除 Kubernetes API 类型对 gogo protobuf 的依赖

随着 gogoprotobuf 移除工作的完成， Kubernetes 代码库的安全性和长期可维护性在 Kubernetes v1.36 中迈出重要一步。这项工作消除了对无人维护的 gogoprotobuf 库的重要依赖；该库已经成为潜在安全漏洞的来源，也阻碍了现代 Go 语言特性的采用。

项目没有迁移到标准 Protobuf 生成方式，因为这会给 Kubernetes API 类型带来兼容性风险；相反，项目选择对所需的生成逻辑进行 fork，并将其内置到 k8s.io/code-generator 中。这种方式在保留现有 API 行为和序列化兼容性的同时，成功从 Kubernetes 依赖图中消除了无人维护的运行时依赖。对于 Kubernetes API Go 类型的使用者而言，这一变更降低了技术债，并避免了与标准 protobuf 库的意外误用。

此项工作是 KEP #5589 的一部分，由 SIG API Machinery 牵头完成。

节点日志查询

过去，Kubernetes 要求集群管理员通过 SSH 登录节点，或实现客户端读取器，以调试与控制平面节点或工作节点相关的问题。虽然某些问题仍然需要直接访问节点，但与 kube-proxy 或 kubelet 有关的问题可以通过检查其日志来诊断。节点日志为集群管理员提供了一种方法：使用 kubelet API 和 kubectl 插件查看这些日志，从而简化故障排查，无需登录节点；这类似于调试与 Pod 或容器相关的问题。这种方法与操作系统无关，并要求服务或节点将日志写入 /var/log。

此特性在生产工作负载上经过充分性能验证后，于 Kubernetes 1.36 中达到 GA。它通过 NodeLogQuery 特性门控在 kubelet 上默认启用。此外，还必须启用 enableSystemLogQuery kubelet 配置选项。

此项工作是 KEP #2258 的一部分，由 SIG Windows 牵头完成。

支持 Pod 中的用户命名空间

随着对用户命名空间的支持进阶至稳定（GA），容器隔离与节点安全在 Kubernetes v1.36 中达到重要成熟度里程碑。这一期待已久的特性允许将容器的 root 用户映射到主机上的非特权用户，从而提供关键的纵深防御层：即使某个进程逃逸出容器，它也不会对底层节点拥有管理权限。

现在，集群操作人员可以放心地为生产工作负载启用这种加固隔离，以缓解容器逃逸漏洞的影响。通过将容器内部身份与主机身份解耦， Kubernetes 提供了一种稳健、标准化的机制，在长期 API 稳定性的完整保障下，保护多租户环境和敏感基础设施免受未授权访问。

此项工作是 KEP #127 的一部分，由 SIG Node 牵头完成。

支持基于 cgroup v2 的 PSI

随着压力停滞信息（PSI）指标导出进阶至稳定（GA），节点资源管理和可观测性在 Kubernetes v1.36 中变得更加精确。此特性使 kubelet 能够报告 CPU、内存和 I/O 的“压力”指标，相比传统利用率指标，它提供了关于资源竞争的更细粒度视图。

集群操作人员和自动伸缩器可以使用这些指标区分两类系统：一种只是繁忙，另一种则因资源耗尽而出现停滞。借助这些信号，用户可以更准确地调整 Pod 资源请求，提升垂直自动伸缩的可靠性，并在“吵闹邻居”效应导致应用性能下降或节点不稳定之前发现它们。

此项工作是 KEP #4205 的一部分，由 SIG Node 牵头完成。

VolumeSource：OCI 制品和/或镜像

随着 OCI 卷源支持进阶至稳定（GA），容器数据分发在 Kubernetes v1.36 中变得更加灵活。此特性允许 kubelet 直接从任何符合 OCI 标准的仓库拉取和挂载内容，例如容器镜像或制品仓库，从而突破了从外部存储提供商或 ConfigMap 挂载卷这一传统要求。

现在，开发者和平台工程师可以将应用数据、模型或静态资产打包为 OCI 制品，并使用他们已经用于容器镜像的同一套仓库和版本控制工作流将其交付给 Pod。镜像与卷管理的这种融合简化了 CI/CD 流水线，减少了只读内容对专用存储后端的依赖，并确保数据在任何环境中都保持可移植且可安全访问。

此项工作是 KEP #4639 的一部分，由 SIG Node 牵头完成。

Beta 阶段的新特性

以下列出 v1.36 发布后进入 Beta 阶段的一些改进。

缓解控制器陈旧状态

Kubernetes 控制器中的陈旧状态是一个会影响许多控制器的问题，并可能以细微方式影响控制器行为。通常要等到为时已晚，即生产环境中的控制器已经采取了错误操作之后，人们才会发现，由控制器作者某些底层假设导致的陈旧状态已经成为问题。这可能会在缓存陈旧期间进行控制器调谐时导致冲突更新或数据损坏。

我们很高兴地宣布，Kubernetes v1.36 包含一些新特性，有助于缓解控制器陈旧状态，并为控制器行为提供更好的可观测性。这可以防止基于过时的集群状态视图执行调谐，而这种调谐往往会导致有害行为。

此项工作是 KEP #5647 的一部分，由 SIG API Machinery 牵头完成。

IP/CIDR 验证改进

在 Kubernetes v1.36 中，面向 API IP 和 CIDR 字段的 StrictIPCIDRValidation 特性进阶至 Beta，收紧验证以捕获此前可能漏过的格式错误地址和前缀。这有助于防止 Service、Pod、NetworkPolicy 或其他资源引用无效 IP 时产生隐蔽配置缺陷；否则这些缺陷可能导致令人困惑的运行时行为或安全意外。

控制器已经更新，会对写回对象的 IP 进行规范化，并在遇到已经存储的错误值时发出警告，因此集群可以逐步收敛到干净、一致的数据。进入 Beta 后，StrictIPCIDRValidation 已准备好进行更广泛的使用，随着网络与策略不断演进，它可为操作人员提供更可靠的 IP 相关配置防护。

此项工作是 KEP #4858 的一部分，由 SIG Network 牵头完成。

将 kubectl 用户偏好与集群配置分离

用于自定义 kubectl 用户偏好的 .kuberc 特性继续处于 Beta 阶段，并默认启用。 ~/.kube/kuberc 文件允许用户将别名、默认命令行参数和其他个人设置与保存集群端点和凭据的 kubeconfig 文件分开存放。这种分离可以防止个人偏好干扰 CI 流水线或共享的 kubeconfig 文件，同时在不同集群和上下文中保持一致的 kubectl 体验。

在 Kubernetes v1.36 中，.kuberc 得到扩展，能够为凭据插件定义策略（允许列表或拒绝列表），以强制实施更安全的身份认证实践。如有需要，用户可以通过设置 KUBECTL_KUBERC=false 或 KUBERC=off 环境变量来禁用此功能。

此项工作是 KEP #3104 的一部分，由 SIG CLI 牵头，并得到了 SIG Auth 的帮助。

Job 挂起时可变更的容器资源

在 Kubernetes v1.36 中，MutablePodResourcesForSuspendedJobs 特性进阶至 Beta 并默认启用。这项更新放宽了 Job 验证，允许在 Job 挂起期间更新容器的 CPU、内存、 GPU 以及扩展资源的请求和限制。

这一能力允许队列控制器和操作人员根据实时集群状况调整批处理工作负载需求。例如，排队系统可以挂起传入的 Job，调整其资源需求以匹配可用容量或配额，然后取消挂起。此特性严格将可变性限制在已挂起的 Job （或其 Pod 已在挂起时终止的 Job）上，以防止对正在运行的 Pod 造成破坏性变更。

此项工作是 KEP #5440 的一部分，由 SIG Apps 牵头完成。

受限的身份扮演（Impersonation）

在 Kubernetes v1.36 中，用于用户身份扮演的 ConstrainedImpersonation 特性进阶至 Beta，将历史上“全有或全无”的机制收紧为真正能够遵循最小权限原则的机制。启用此特性时，身份扮演者必须拥有两组不同的权限：一组用于扮演给定身份，另一组用于代表该身份执行特定操作。这可以防止支持工具、控制器或节点代理即使在身份扮演 RBAC 配置错误的情况下，也通过身份扮演获得超出其自身被允许范围的访问权限。现有的 impersonate 规则会继续工作，但 API 服务器会优先使用新的受限检查，使迁移成为增量过程，而不是一次性切换。随着 v1.36 中进入 Beta，ConstrainedImpersonation 已经过测试、具备文档，并已准备好被依赖身份扮演进行调试、代理或节点级控制器的平台团队更广泛采用。

此项工作是 KEP #5284 的一部分，由 SIG Auth 牵头完成。

Beta 阶段的 DRA 特性

随着若干核心特性进阶至 Beta 并默认启用，动态资源分配（DRA）框架在 Kubernetes v1.36 中达到又一个成熟度里程碑。通过推进可分区设备和可消耗容量，这次转变让 DRA 超越了基础分配，允许对 GPU 等硬件进行更细粒度的共享；同时，设备污点和容忍确保专用资源只被合适的工作负载使用。

现在，用户可以通过 ResourceClaim 设备状态以及在 Pod 调度前确保设备挂接的能力，受益于更可靠且更可观测的资源生命周期。通过将这些特性与扩展资源支持集成， Kubernetes 为传统设备插件系统提供了一个稳健、生产就绪的替代方案，使复杂的 AI 与 HPC 工作负载能够以前所未有的精度和运维安全性管理硬件。

此项工作跨越多个 KEP（包括 #5004、#4817、 #5055、#5075、#4815 和 #5007），由 SIG Scheduling 和 SIG Node 牵头完成。

Kubernetes 组件的 Statusz

在 Kubernetes v1.36 中，面向核心 Kubernetes 组件的 ComponentStatusz 特性门控进阶至 Beta，提供一个默认启用的 /statusz 端点，用于呈现每个组件的实时构建和版本细节。这个低开销的 z-page 会公开启动时间、运行时长、 Go 版本、二进制版本、仿真版本和最低兼容版本等信息，使操作人员和开发者无需深入日志或配置，就能快速准确了解正在运行的内容。

此端点默认提供人类可读的文本视图，并通过显式内容协商提供一个版本化的结构化 API（config.k8s.io/v1beta1），以 JSON、YAML 或 CBOR 形式供程序访问。访问权限授予 system:monitoring 组，使其与健康和指标端点上的现有保护保持一致，并避免暴露敏感数据。

进入 Beta 后，ComponentStatusz 在所有核心控制平面组件和节点代理程序上默认启用，并由单元测试、集成测试和端到端测试提供支撑，因此可以安全地用于生产环境中的可观测性和调试工作流。

此项工作是 KEP #4827 的一部分，由 SIG Instrumentation 牵头完成。

Kubernetes 组件的 Flagz

在 Kubernetes v1.36 中，面向核心 Kubernetes 组件的 ComponentFlagz 特性门控进阶至 Beta，标准化了 /flagz 端点，用于公开每个组件启动时实际生效的命令行标志。这为集群操作人员和开发者提供了组件配置的实时集群内可见性，使调试意外行为或验证某个标志发布在重启后是否真正生效变得容易得多。

此端点同时支持人类可读的文本视图和版本化的结构化 API（初始为 config.k8s.io/v1beta1），因此你既可以在事故期间用 curl 查看它，也可以在准备好后将其接入自动化工具。访问权限授予 system:monitoring 组，且敏感值可以被遮蔽，使配置可见性与健康和状态端点周边的现有安全实践保持一致。

进入 Beta 后，ComponentFlagz 现在默认启用，并已在所有核心控制平面组件和节点代理程序中实现；单元测试、集成测试和端到端测试为其提供支撑，以确保该端点在生产集群中可靠。

此项工作是 KEP #4828 的一部分，由 SIG Instrumentation 牵头完成。

混合版本代理（又称未知版本互操作代理）

在 Kubernetes v1.36 中，混合版本代理特性在 v1.28 引入的 Alpha 版本基础上进阶至 Beta，为混合版本集群提供更安全的控制平面升级。现在，每个 API 请求都可以路由到为所请求的组、版本和资源提供服务的 apiserver 实例，从而减少因版本偏差导致的 404 和失败。

此特性依赖对等聚合发现，因此各 apiserver 会共享它们公开哪些资源和版本的信息，随后在需要时使用这些数据透明地重路由请求。关于被重路由流量和代理行为的新指标，可帮助操作人员了解请求被转发的频率以及被转发到哪些对等实例。这些变更结合起来，使在生产环境中运行高可用的混合版本 API 控制平面变得更容易，同时支持执行多步骤或部分控制平面升级。

此项工作是 KEP #4020 的一部分，由 SIG API Machinery 牵头完成。

基于 cgroups v2 的内存 QoS

Kubernetes 现在在 Linux cgroup v2 节点上通过更智能、分层的内存保护增强内存 QoS，使内核控制更好地与 Pod 请求和限制对齐，减少共享同一节点的工作负载之间的干扰和抖动。这一迭代还改进了 kubelet 对 memory.high 和 memory.min 的设置方式，增加了指标和防护机制以避免活锁，并引入配置选项，使集群操作人员可以针对其环境调整内存保护行为。

此项工作是 KEP #2570 的一部分，由 SIG Node 牵头完成。

Alpha 阶段的新特性

以下列出 v1.36 发布后进入 Alpha 阶段的一些改进。

基于自定义指标的 HPA 缩容到零

到目前为止，HorizontalPodAutoscaler（HPA）要求至少保留一个活跃副本，因为它只能基于运行中 Pod 的指标（如 CPU 或内存）计算扩缩容需求。 Kubernetes v1.36 继续推进 Alpha 阶段的 HPA 缩容到零特性（默认禁用），允许工作负载在使用 Object 或 External 指标时专门缩容到零个副本。

现在，用户可以进行实验：在没有待处理工作时让重型工作负载完全空闲，从而显著降低基础设施成本。虽然此特性仍受 HPAScaleToZero 特性门控控制，但它使 HPA 即使在没有运行中 Pod 时也能保持活跃，并在外部指标（例如队列长度）表明有新任务到达时，自动将 Deployment 扩容回来。

此项工作是 KEP #2021 的一部分，由 SIG Autoscaling 牵头完成。

Alpha 阶段的 DRA 特性

过去，动态资源分配（DRA）框架缺少与高级控制器的无缝集成，并且对设备特定元数据或可用性的可见性有限。 Kubernetes v1.36 引入了一批 Alpha 阶段的 DRA 增强，包括面向工作负载的原生 ResourceClaim 支持，以及 DRA 原生资源，用于为 CPU 管理提供 DRA 的灵活性。

现在，用户可以利用 Downward API 将复杂资源属性直接暴露给容器，并受益于改进后的资源可用性可见性，从而实现更可预测的调度。这些更新结合对设备属性中列表类型的支持，将 DRA 从低层原语转变为稳健的系统，能够处理现代 AI 和高性能计算（HPC）栈的复杂网络与计算需求。

此项工作跨越多个 KEP（包括 #5729、#5304、 #5517、#5677 和 #5491），由 SIG Scheduling 和 SIG Node 牵头完成。

Kubernetes 指标的原生直方图支持

随着原生直方图支持在 Alpha 阶段引入，高分辨率监控在 Kubernetes v1.36 中达到新的里程碑。传统 Prometheus 直方图依赖静态、预定义的桶，往往迫使用户在数据精度和内存使用之间取舍；这项更新允许控制平面导出稀疏直方图，并基于实时数据动态调整其分辨率。

现在，集群操作人员可以捕获 kube-apiserver 和其他核心组件的精确延迟分布，而无需承担手动管理桶的开销。这一架构转变确保 SLI 和 SLO 更可靠，提供高保真热力图，即使在最难预测的工作负载峰值期间也能保持准确。

此项工作是 KEP #5808 的一部分，由 SIG Instrumentation 牵头完成。

基于清单的准入控制配置

随着 Alpha 阶段的基于清单的准入控制配置引入，准入控制器管理在 Kubernetes v1.36 中迈向更加声明式且一致的模型。长期以来，准入插件需要通过分散的命令行参数或独立且复杂的配置文件进行配置。这一变更允许管理员直接通过结构化清单定义准入控制的期望状态，从而应对这一长期挑战。

现在，集群操作人员可以使用与其他 Kubernetes 对象相同的版本化、声明式工作流来管理准入插件设置，显著降低集群升级期间配置漂移和手动错误的风险。通过将这些配置集中到统一清单中， kube-apiserver 变得更易于审计和自动化，为更安全、可复现的集群部署铺平道路。

此项工作是 KEP #5793 的一部分，由 SIG API Machinery 牵头完成。

CRI 列表流式传输

随着 CRI 列表流式传输在 Alpha 阶段引入， Kubernetes v1.36 使用了新的内部流式操作。此增强将 kubelet 与容器运行时之间传统的整体式 List 请求替换为更高效的服务器端流式 RPC，以解决大规模节点上常见的内存压力和延迟峰值问题。

现在，kubelet 不再等待包含所有容器或镜像数据的单个巨大响应，而是可以在结果被流式传输时增量处理。这一转变显著降低了 kubelet 的峰值内存占用，并提升了高密度节点上的响应能力，确保即使每个节点上的容器数量持续增长，集群管理也能保持流畅。

此项工作是 KEP #5825 的一部分，由 SIG Node 牵头完成。

其他值得注意的变化

Ingress NGINX 退役

为优先保障生态系统的安全，Kubernetes SIG Network 和安全响应委员会（Security Response Committee）已于 2026 年 3 月 24 日退役 Ingress NGINX。自该日期起，不再发布后续版本、不再修复缺陷，也不再更新以修复新发现的安全漏洞。现有 Ingress NGINX 部署将继续运行，Helm Chart 和容器镜像等安装制品也将继续可用。

完整详情请参阅官方退役公告。

卷的 SELinux 标签提速（GA）

Kubernetes v1.36 将 SELinux 卷挂载改进提升为正式可用。此变更使用 mount -o context=XYZ 选项替代了递归文件重标记，在挂载时为整个卷应用正确的 SELinux 标签。它带来更一致的性能，并减少启用 SELinux 强制模式系统上的 Pod 启动延迟。

该特性在 v1.28 作为 Beta 引入，适用于 ReadWriteOncePod 卷。在 v1.32，它新增了指标和退出选项（securityContext.seLinuxChangePolicy: Recursive）以帮助发现冲突。现在在 v1.36，它进入稳定（GA）阶段，并默认适用于所有卷； Pod 或 CSIDriver 可通过 spec.seLinuxMount 显式启用。

不过，我们预计该特性在未来 Kubernetes 版本中可能带来破坏性变更风险，潜在原因是在同一节点上的特权 Pod 和非特权 Pod 之间共享同一个卷。

开发者有责任为 Pod 设置 seLinuxChangePolicy 字段和 SELinux 卷标签。无论他们是在编写 Deployment、StatefulSet、DaemonSet，还是包含 Pod 模板的自定义资源，对这些设置不够谨慎都可能导致一系列问题，例如 Pod 共享卷时无法正确启动。

Kubernetes v1.36 是审计集群的理想版本。要了解更多信息，请查看博客 SELinux Volume Label Changes goes GA (and likely implications in v1.37)。

有关此增强的更多细节，请参阅 KEP-1710：加快递归 SELinux 标签变更。

v1.36 的升级、弃用与移除

进阶至稳定阶段

这里列出了所有进阶至稳定（也称为正式发布，GA）阶段的特性。有关包括新特性以及从 Alpha 进阶至 Beta 的完整更新列表，请参阅发布说明。

此版本共有 18 项增强提升至稳定阶段：

弃用、移除与社区更新

随着 Kubernetes 的发展与成熟，为提升项目整体健康度，特性可能会被弃用、移除或被更好的特性替代。关于这一过程的更多信息，请参阅 Kubernetes 的弃用与移除策略。 Kubernetes v1.36 包含若干项弃用内容。

Service `.spec.externalIPs` 的弃用

在本次发布中，Service spec 中的 externalIPs 字段被弃用。这意味着此功能仍然存在，但将在 Kubernetes 的未来版本中不再工作。如果你当前依赖此字段，应计划迁移。这个字段多年来一直是已知的安全隐患，会让集群流量面临中间人攻击风险，如 CVE-2020-8554 所述。从 Kubernetes v1.36 起，使用它时你会看到弃用警告，并计划在 v1.43 完全移除。

如果你的 Service 仍依赖 externalIPs，可考虑使用 LoadBalancer 服务处理云托管入口、使用 NodePort 做简单端口暴露，或使用 Gateway API 以更灵活且更安全的方式处理外部流量。

有关此字段及其弃用的更多细节，请参阅外部 IP，或阅读 KEP-5707：弃用 service.spec.externalIPs。

移除 `gitRepo` 卷驱动

gitRepo 卷类型自 v1.11 起已被弃用。在 Kubernetes v1.36 中，gitRepo 卷插件被永久禁用，且无法重新启用。此变更可保护集群免受关键安全问题影响，因为使用 gitRepo 可能让攻击者以 root 身份在节点上运行代码。

尽管 gitRepo 多年来一直处于弃用状态，且已有更好的替代方案被推荐，但在此前版本中它在技术上仍可使用。从 v1.36 开始，这条路径将被永久关闭，因此任何依赖 gitRepo 的现有工作负载都需要迁移到受支持方案，例如 init 容器或外部 git-sync 风格工具。

有关此移除的更多细节，请参阅 KEP-5040：移除 gitRepo 卷驱动。

发布说明

请在我们的发布说明中查看 Kubernetes v1.36 发布的完整细节。

可用性

Kubernetes v1.36 可通过 GitHub 或 Kubernetes 下载页面获取。

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

发布团队

Kubernetes 的存在离不开社区的支持、投入和辛勤工作。每个发布团队都由专注的社区志愿者组成，他们共同构建你所依赖的 Kubernetes 发布版本中的诸多组成部分。这需要来自社区各个角落的专业能力：从代码本身到文档与项目管理。

我们感谢整个发布团队为向社区交付 Kubernetes v1.36 所付出的辛勤时间。发布团队成员既包括首次参与的 shadow，也包括经过多个发布周期锤炼、再次回归的团队负责人。我们特别感谢发布负责人 Ryota Sawada：他带领我们走过一个成功的发布周期，以亲力亲为的方式解决挑战，并带来推动社区前行的能量与关怀。

项目活跃度

CNCF K8s 的 DevStats 项目汇总了与 Kubernetes 及其各子项目活跃度相关的一系列有趣数据点。这些数据涵盖从个人贡献到参与贡献公司的数量等多个方面，体现了推动该生态演进所投入努力的深度与广度。

在 v1.36 发布周期（从 2026 年 1 月 12 日到 2026 年 4 月 22 日，共 15 周）期间， Kubernetes 收到了来自多达 106 家公司与 491 名个人的贡献。在更广泛的云原生生态中，这一数字上升到 370 家公司，共计 2235 名贡献者。

请注意，这里的“贡献”统计包括：提交代码、进行代码评审、发表评论、创建 Issue 或 PR、评审 PR（包括博客与文档）以及对 Issue 与 PR 的评论等。如果你有兴趣参与贡献，请访问贡献者网站上的 Getting Started。

数据来源：

活动更新

了解即将到来的 Kubernetes 与云原生活动，包括 KubeCon + CloudNativeCon、KCD 与全球其他重要会议。保持关注并参与 Kubernetes 社区！

2026 年 4 月

KCD - Kubernetes Community Days: Guadalajara：2026 年 4 月 18 日｜墨西哥 Guadalajara

2026 年 5 月

KCD - Kubernetes Community Days: Toronto：2026 年 5 月 13 日｜加拿大 Toronto
KCD - Kubernetes Community Days: Texas：2026 年 5 月 15 日｜美国 Austin
KCD - Kubernetes Community Days: Istanbul：2026 年 5 月 15 日｜土耳其 Istanbul
KCD - Kubernetes Community Days: Helsinki：2026 年 5 月 20 日｜芬兰 Helsinki
KCD - Kubernetes Community Days: Czech & Slovak：2026 年 5 月 21 日｜捷克 Prague

2026 年 6 月

KCD - Kubernetes Community Days: New York：2026 年 6 月 10 日｜美国 New York
KubeCon + CloudNativeCon India 2026：2026 年 6 月 18-19 日｜印度 Mumbai

2026 年 7 月

KubeCon + CloudNativeCon Japan 2026：2026 年 7 月 29-30 日｜日本 Yokohama

2026 年 9 月

KubeCon + CloudNativeCon China 2026：2026 年 9 月 8-9 日｜中国上海

2026 年 10 月

KCD - Kubernetes Community Days: UK：2026 年 10 月 19 日｜英国 Edinburgh

2026 年 11 月

KCD - Kubernetes Community Days: Porto：2026 年 11 月 19 日｜葡萄牙 Porto
KubeCon + CloudNativeCon North America 2026：2026 年 11 月 9-12 日｜美国 Salt Lake

你可以在此处查看最新活动详情。

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

欢迎在 2026 年 5 月 20 日（星期三）16:00（UTC） 与 Kubernetes v1.36 发布团队成员一起，了解本次发布的重点亮点。有关更多信息与注册方式，请访问 CNCF Online Programs 网站上的活动页面。

参与其中

参与 Kubernetes 最简单的方式之一，是加入与你兴趣相符的众多特别兴趣小组（Special Interest Groups，SIG）之一。你想向 Kubernetes 社区发布一些内容吗？欢迎在我们每周的社区会议上发声，也可以通过以下渠道参与交流。感谢你持续的反馈与支持。

在 Bluesky 关注我们 @kubernetes.io 获取最新动态
在 Discuss 加入社区讨论
在 Slack 加入社区
在 Stack Overflow 提问（或回答问题）
分享你的 Kubernetes 故事
在博客阅读更多 Kubernetes 最新动态
进一步了解 Kubernetes 发布团队

Kubernetes v1.36 抢先一览

Mon, 30 Mar 2026 00:00:00 +0000

Kubernetes v1.36 将于 2026 年 4 月底发布。本次发布将包含移除和弃用项，并带来数量可观的增强功能。以下是我们在这个发布周期中最期待的一些特性。

请注意，本文信息反映的是 v1.36 开发的当前状态，发布前仍可能发生变化。

Kubernetes API 的移除与弃用流程

Kubernetes 项目针对功能有一套文档完善的弃用策略。该策略规定，稳定版 API 只有在有新的稳定替代版本时才会被弃用，并且 API 在每个稳定级别都有最短生命周期。被弃用的 API 会被标记为将在未来 Kubernetes 版本中移除。它在移除前会继续工作（自弃用起至少一年），但使用时会显示告警。被移除的 API 在当前版本中将不再可用，此时你必须迁移到替代方案。

正式可用（GA）或稳定版 API 可以标记为弃用，但不得在 Kubernetes 的一个主版本内被移除。
Beta 或预发布 API 版本在弃用后必须继续支持 3 个版本。
Alpha 或实验性 API 版本可以在任何版本中移除，无需提前发出弃用通知；在同一功能已有不同实现时，此过程也可能变为撤回。

无论 API 被移除是因为某功能从 beta 晋升到稳定，还是因为该 API 本身未能成功升级，所有移除都遵循这一弃用策略。每当 API 被移除时，弃用指南都会提供迁移选项。

这一原则近期的一个实践案例是 ingress-nginx 项目的退役，该消息由 SIG-Security 于 2026 年 3 月 24 日宣布。随着项目维护权发生变化，社区被鼓励评估符合当前安全与维护最佳实践的替代的 Ingress 控制器实现。这一过渡体现了支撑 Kubernetes 本身的同一生命周期原则，确保持续演进且不造成突发中断。

Ingress NGINX 退役

完整详情请参阅官方退役公告。

Kubernetes v1.36 的弃用和移除

Service 中 `.spec.externalIPs` 的弃用

Service spec 中的 externalIPs 字段正在被弃用，这意味着你很快将失去把任意 externalIPs 路由到 Service 的快捷方式。这个字段多年来一直是已知的安全隐患，会让集群流量面临中间人攻击风险，如 CVE-2020-8554 所述。 Kubernetes v1.36 起该字段会触发弃用告警，并计划在 v1.43 移除。

关于此增强功能的更多细节，请参阅 KEP-5707：弃用 service.spec.externalIPs

`gitRepo` 卷驱动的移除

gitRepo 卷类型自 v1.11 起已被弃用。从 Kubernetes v1.36 开始，gitRepo 卷插件将被永久禁用，且无法重新启用。此变更可保护集群免受关键安全问题影响，因为使用 gitRepo 可能让攻击者以 root 身份在节点上运行代码。

尽管 gitRepo 多年来一直处于弃用状态，且已有更好的替代方案被推荐，但在此前版本中它在技术上仍可使用。从 v1.36 开始，这条路径将被永久关闭，因此任何依赖 gitRepo 的现有工作负载都需要迁移到受支持方案，例如 init 容器或外部 git-sync 风格工具。

关于此增强功能的更多细节，请参阅 KEP-5040：移除 gitRepo 卷驱动

Kubernetes v1.36 的重点增强功能

以下增强功能很可能包含在即将发布的 v1.36 中。这不是承诺，发布内容仍可能发生变化。

卷的 SELinux 标签提速（GA）

Kubernetes v1.36 将 SELinux 卷挂载改进提升为正式可用。此变更用 mount -o context=XYZ 选项替代了递归文件重标记，在挂载时为整个卷应用正确的 SELinux 标签。它带来更一致的性能，并减少启用 SELinux 强制模式系统上的 Pod 启动延迟。

该功能在 v1.28 作为 beta 引入，适用于 ReadWriteOncePod 卷。在 v1.32，它新增了指标和退出选项（securityContext.seLinuxChangePolicy: Recursive）以帮助发现冲突。现在在 v1.36 进入稳定阶段，并将该机制扩展为默认面向所有卷； Pod 或 CSIDriver 可通过 spec.SELinuxMount 显式启用。

不过，我们预计该功能在未来 Kubernetes 版本中可能带来破坏性变更风险，原因是可能混用特权和非特权 Pod。正确设置 Pod 上的 seLinuxChangePolicy 字段和 SELinux 卷标签，是 Pod 作者的责任。无论开发者是在编写 Deployment、StatefulSet、DaemonSet，还是包含 Pod 模板的自定义资源，都需要承担这一责任。对这些设置不够谨慎会在 Pod 共享卷时导致一系列问题。

关于此增强功能的更多细节，请参阅 KEP-1710：加快递归 SELinux 标签变更

ServiceAccount Token 的外部签名

作为 beta 功能，Kubernetes 已支持 ServiceAccount Token 的外部签名。这使集群可以集成外部密钥管理系统或签名服务，而不只依赖内部管理密钥。

通过这一增强，kube-apiserver 可以将令牌签名委托给外部系统，例如云密钥管理服务或硬件安全模块。这提升了安全性，并简化了依赖集中式签名基础设施的集群的密钥管理。我们预计它将在 Kubernetes v1.36 升级为稳定（GA）。

关于此增强功能的更多细节，请参阅 KEP-740：支持服务账户令牌的外部签名

DRA 驱动对设备污点和容忍的支持

Kubernetes v1.33 引入了对通过动态资源分配（DRA）管理的物理设备的污点和容忍支持。通常，任何设备都可用于调度。但这一增强允许 DRA 驱动将设备标记为污点，从而确保这些设备不会用于调度。或者，集群管理员可创建 DeviceTaintRule，将符合特定选择条件（例如某个驱动的所有设备）的设备标记为污点。这改进了调度控制，并有助于确保专用硬件资源仅被显式请求它们的工作负载使用。

在 Kubernetes v1.36 中，该功能在完成更全面测试后升级为 beta，默认可用，无需功能开关，并向用户反馈开放。

要了解污点和容忍，请参阅污点和容忍。关于此增强功能的更多细节，请参阅 KEP-5055：DRA：设备污点和容忍。

DRA 对可分区设备的支持

Kubernetes v1.36 通过引入对可分区设备的支持扩展了动态资源分配（DRA），允许将单个硬件加速器拆分为多个可在工作负载之间共享的逻辑单元。这对 GPU 等高成本资源尤其有用，因为将整个设备独占给单个工作负载可能导致利用不足。

通过这一增强，平台团队可以通过仅为每个工作负载分配所需设备份额来提升整体集群效率，而不是完整预留设备。这使得在保持隔离和控制的同时，更容易在同一硬件上运行多个工作负载，帮助组织从其基础设施中获得更多价值。

要了解更多信息，请参阅 KEP-4815：DRA 可分区设备

想了解更多？

Kubernetes 发布说明也会发布新功能和弃用信息。我们将在该版本的 CHANGELOG 中正式公布 Kubernetes v1.36 的更新内容。

Kubernetes v1.36 计划于 2026 年 4 月 22 日（周三）发布。请持续关注后续更新。

你也可以在以下版本的发布说明中查看变更公告：

参与其中

参与 Kubernetes 最简单的方式是加入与你兴趣匹配的众多特别兴趣小组（SIG）之一。如果你有想向 Kubernetes 社区分享的内容，欢迎在我们的每周社区会议以及下列渠道中发声。感谢你持续的反馈与支持。

在 Bluesky 关注我们 @kubernetes.io 获取最新动态
在 Discuss 加入社区讨论
在 Slack 加入社区
在 Server Fault 或 Stack Overflow 提问（或回答问题）
分享你的 Kubernetes 故事
在博客阅读更多 Kubernetes 最新动态
进一步了解 Kubernetes Release Team

Ingress2Gateway 1.0 正式发布：通往 Gateway API 的途径

Fri, 20 Mar 2026 11:00:00 -0800

随着 Ingress-NGINX 计划于 2026 年 3 月正式退役，Kubernetes 网络图景正处于一个转折点。对于大多数组织而言，问题不在于是否迁移到 Gateway API，而在于如何安全地完成迁移。

从 Ingress 迁移到 Gateway API 是 API 设计的根本性转变。 Gateway API 提供了一个模块化、可扩展的 API，并对 Kubernetes 原生的基于角色的访问控制（RBAC）提供了强大的支持。相反，Ingress API 较为简单，而像 Ingress-NGINX 这样的实现则通过晦涩难懂的注解、ConfigMap 和 CRD 来扩展 API。从 Ingress-NGINX 等 Ingress 控制器迁移过来，面临着一项艰巨的任务：捕捉 Ingress 控制器的所有细微差别，并将这种行为映射到 Gateway API。

Ingress2Gateway 是一款辅助工具，旨在帮助团队自信地从 Ingress API 迁移到 Gateway API。它会将 Ingress 资源/清单以及特定于实现的注解转换为 Gateway API，并在出现无法转换的配置时发出警告并提供建议。

今天，SIG Network 自豪地宣布 Ingress2Gateway 1.0 版本正式发布。这一里程碑标志着 Ingress2Gateway 正式上线，它是一款稳定且经过测试的迁移辅助工具，能够帮助团队实现网络架构的现代化。

Ingress2Gateway 1.0

Ingress-NGINX 注解支持

1.0 版本的主要改进在于更全面的 Ingress-NGINX 支持。在 1.0 版本之前，Ingress2Gateway 仅支持三种 Ingress-NGINX 注解。在 1.0 版本中，Ingress2Gateway 支持超过 30 种常用注解（CORS、后端 TLS、正则表达式匹配、路径重写等）。

全面的集成测试

每个受支持的 Ingress-NGINX 注解以及常用注解的典型组合，都由控制器级别的集成测试提供支持，以验证 Ingress-NGINX 配置与生成的 Gateway API 的行为等效性。

这些测试在实际集群中运行，并比较运行时行为（路由、重定向、重写等），而不仅仅是 YAML 结构。

测试内容：

启动一个 Ingress-NGINX 控制器
启动多个 Gateway API 控制器
应用具有特定于实现的配置的 Ingress 资源
使用 ingress2gateway 将 Ingress 资源转换为 Gateway API，并应用生成的清单
验证 Gateway API 控制器和 Ingress 控制器是否表现出相同的行为。

一套全面的测试套件不仅可以捕获开发中的错误，还可以确保转换的正确性，尤其是在考虑到意想不到的极端情况和意外的默认值的情况下，从而避免在生产环境中发现这些问题。

通知与错误处理

迁移并非“一键式”操作。揭示细微差别和难以翻译的行为与翻译受支持的配置同样重要。 1.0 版本优化了通知的格式和内容，让你清楚地了解缺失的内容以及如何修复。

使用 Ingress2Gateway

Ingress2Gateway 是一个迁移助手，而非一劳永逸的替代方案。

它的目标是：

迁移受支持的 Ingress 配置和行为
识别不受支持的配置并提供替代方案
重新评估并可能舍弃不理想的配置

本节的其余部分将向你展示如何安全地迁移以下 Ingress-NGINX 配置。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "1G"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "1"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "1"
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_set_headers "Request-Id: $req_id";
  name: my-ingress
  namespace: my-ns
spec:
  ingressClassName: nginx
  rules:
    - host: my-host.example.com
      http:
        paths:
          - backend:
              service:
                name: website-service
                port:
                  number: 80
            path: /users/(\d+)
            pathType: ImplementationSpecific
  tls:
    - hosts:
        - my-host.example.com
      secretName: my-secret

1. 安装 Ingress Gateway

如果你已设置好 Go 环境，则可以使用以下命令安装 Ingress Gateway：

go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

否则，

brew install ingress2gateway

你还可以从 GitHub 下载二进制文件，或者从源代码构建。

2. 运行 Ingress2Gateway

你可以传递 Ingress2Gateway 的 Ingress 清单，或者让该工具直接从你的集群读取清单。

# 传递文件
ingress2gateway print --input-file my-manifest.yaml,my-other-manifest.yaml --providers=ingress-nginx > gwapi.yaml

# 使用集群中的命名空间
ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml

# 或者使用整个集群
ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yaml

说明：

你还可以传递 --emitter <agentgateway|envoy-gateway|kgateway> 来输出特定于实现的扩展。

3. 检查输出

这是最关键的一步。

上一节中的命令会将 Gateway API 清单输出到 gwapi.yaml 文件，同时还会发出警告，说明哪些内容翻译不准确以及需要手动检查哪些内容。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: my-ns
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: my-host.example.com
    name: my-host-example-com-http
    port: 80
    protocol: HTTP
  - hostname: my-host.example.com
    name: my-host-example-com-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 443
  rules:
  - backendRefs:
    - name: website-service
      port: 80
    filters:
    - cors:
        allowCredentials: true
        allowHeaders:
        - DNT
        - Keep-Alive
        - User-Agent
        - X-Requested-With
        - If-Modified-Since
        - Cache-Control
        - Content-Type
        - Range
        - Authorization
        allowMethods:
        - GET
        - PUT
        - POST
        - DELETE
        - PATCH
        - OPTIONS
        allowOrigins:
        - '*'
        maxAge: 1728000
      type: CORS
    matches:
    - path:
        type: RegularExpression
        value: (?i)/users/(\d+).*
    name: rule-0
    timeouts:
      request: 10s
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com-ssl-redirect
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 80
  rules:
  - filters:
    - requestRedirect:
        scheme: https
        statusCode: 308
      type: RequestRedirect

Ingress2Gateway 已成功将部分注解转换为对应的 Gateway API。例如，nginx.ingress.kubernetes.io/enable-cors 注解被转换为 CORS 过滤器。但仔细检查后发现，nginx.ingress.kubernetes.io/proxy-{read,send}-timeout 和 nginx.ingress.kubernetes.io/proxy-body-size 注解并未完全映射。日志显示了这些缺失的原因以及转换背后的逻辑。

┌─ WARN  ────────────────────────────────────────
│  Unsupported annotation nginx.ingress.kubernetes.io/configuration-snippet
│  source: INGRESS-NGINX
│  object: Ingress: my-ns/my-ingress
└─
┌─ INFO  ────────────────────────────────────────
│  Using case-insensitive regex path matches. You may want to change this.
│  source: INGRESS-NGINX
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  ingress-nginx only supports TCP-level timeouts; i2gw has made a best-effort translation to Gateway API timeouts.request. Please verify that this meets your needs. See documentation: https://gateway-api.sigs.k8s.io/guides/http-timeouts/
│  source: INGRESS-NGINX
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  Failed to apply my-ns.my-ingress.metadata.annotations."nginx.ingress.kubernetes.io/proxy-body-size" from my-ns/my-ingress: Most Gateway API implementations have reasonable body size and buffering defaults
│  source: STANDARD_EMITTER
│  object: HTTPRoute: my-ns/my-ingress-my-host-example-com
└─
┌─ WARN  ────────────────────────────────────────
│  Gateway API does not support configuring URL normalization (RFC 3986, Section 6). Please check if this matters for your use case and consult implementation-specific details.
│  source: STANDARD_EMITTER
└─

警告信息显示，Ingress2Gateway 不支持 nginx.ingress.kubernetes.io/configuration-snippet 注解。你需要查看 Gateway API 的实现文档，了解是否有其他方法可以实现相同的功能。

该工具还提示我们，Ingress-NGINX 的正则表达式匹配是不区分大小写的前缀匹配，因此匹配模式为 (?i)/users/(\d+).*。大多数组织希望通过移除路径模式开头的 (?i) 和结尾的 .* 来将其更改为区分大小写的精确匹配。

Ingress2Gateway 已尽力将 nginx.ingress.kubernetes.io/proxy-{send,read}-timeout 注解转换为 HTTP 路由中的 10 秒请求超时（https://gateway-api.sigs.k8s.io/guides/http-timeouts/）。如果此服务的请求超时时间需要更短，例如 3 秒，你可以相应地修改 Gateway API 清单。

此外，nginx.ingress.kubernetes.io/proxy-body-size 在 Gateway API 中没有对应的注解，因此未进行转换。但是，大多数 Gateway API 实现都为最大请求体大小和缓冲设置了合理的默认值，因此这在实践中可能不会造成问题。此外，一些消息发送器可能会通过特定于实现的扩展来支持此注解。例如，在之前的 ingress2gateway print 命令中添加 --emitter agentgateway、--emitter envoy-gateway 或 --emitter kgateway 标志，会在生成的 Gateway API 清单中添加额外的特定于实现的配置，以尝试捕获请求体大小配置。

我们还看到了关于 URL 规范化的警告。诸如 Agentgateway、Envoy Gateway、Kgateway 和 Istio 等网关 API 实现都具有一定程度的 URL 规范化功能，但不同实现的行为各不相同，且无法通过标准网关 API 进行配置。你应该检查并测试你的网关 API 实现的 URL 规范化行为，以确保其与你的使用场景兼容。

为了与 Ingress-NGINX 的默认行为保持一致，Ingress2Gateway 还在 80 端口上添加了一个监听器和一个 HTTP 请求重定向过滤器，用于将 HTTP 流量重定向到 HTTPS。你可能根本不需要处理 HTTP 流量，因此可以移除 80 端口上的监听器和相应的 HTTPRoute。

注意：

务必仔细检查生成的输出和日志。

手动应用这些更改后，网关 API 清单可能如下所示。

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: nginx
  namespace: my-ns
spec:
  gatewayClassName: nginx
  listeners:
  - hostname: my-host.example.com
    name: my-host-example-com-https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - group: ""
        kind: Secret
        name: my-secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  annotations:
    gateway.networking.k8s.io/generator: ingress2gateway-dev
  name: my-ingress-my-host-example-com
  namespace: my-ns
spec:
  hostnames:
  - my-host.example.com
  parentRefs:
  - name: nginx
    port: 443
  rules:
  - backendRefs:
    - name: website-service
      port: 80
    filters:
    - cors:
        allowCredentials: true
        allowHeaders:
        - DNT
        ...
        allowMethods:
        - GET
        ...
        allowOrigins:
        - '*'
        maxAge: 1728000
      type: CORS
    matches:
    - path:
        type: RegularExpression
        value: /users/(\d+)
    name: rule-0
    timeouts:
      request: 3s

4. 验证

现在你已经拥有了 Gateway API 清单文件，应该在开发集群中对其进行全面测试。在这种情况下，你至少应该仔细检查 Gateway API 实现的最大请求体大小默认值是否符合你的需求，并验证三秒超时是否足够。

在开发集群中验证行为后，将你的 Gateway API 配置部署到现有 Ingress 旁边。我们强烈建议你使用加权 DNS、云负载均衡器或平台流量拆分功能逐步转移流量。这样，你可以快速从测试中遗留的任何配置错误中恢复。

最后，当你将所有流量转移到 Gateway API 控制器后，请删除 Ingress 资源并卸载 Ingress 控制器。

总结

Ingress2Gateway 1.0 的发布仅仅是个开始，我们希望你能使用 Ingress2Gateway 安全地迁移到 Gateway API。随着 Ingress-NGINX 将于 2026 年 3 月停止服务，我们诚邀社区成员帮助我们提升配置覆盖率、扩展测试范围并改进用户体验。

Gateway API 相关资源

Gateway API 的功能非常强大，可能会让你感到不知所措。以下是一些可以帮助你使用 Gateway API 的资源：

监听器集允许应用程序开发人员管理 Gateway 监听器。
gwctl 为你提供 Gateway 资源的全面视图，例如附件和代码检查错误。
Gateway API Slack：Kubernetes Slack 频道上的 #sig-network-gateway-api 讨论区（https://kubernetes.slack.com）
Ingress2Gateway Slack：Kubernetes Slack 频道上的 #sig-network-ingress2gateway 讨论区（https://kubernetes.slack.com）
GitHub：kubernetes-sigs/ingress2gateway

在 Kubernetes 上使用 Agent Sandbox 运行智能体

Fri, 20 Mar 2026 10:00:00 -0800

人工智能领域正经历着一场巨大的架构变革。在生成式人工智能的早期，与模型交互通常被视为一个瞬态的、无状态的函数调用：一个启动、执行可能仅 50 毫秒便终止的请求。

如今，人工智能 2.0 正在取代人工智能 1.0。人工智能生态系统正从短暂、孤立的任务转向部署多个持续运行的、协同工作的 AI 智能体。这些自主智能体需要维护上下文信息、使用外部工具、编写和执行代码，并在较长时间内相互通信。

当平台工程团队寻找合适的架构来托管这些新型 AI 工作负载时， Kubernetes 脱颖而出，成为自然之选。然而，将这些独特的智能体工作负载映射到传统的 Kubernetes 原语需要一种新的抽象。

这正是新的 Agent Sandbox 项目（目前由 SIG Apps 开发）发挥作用的地方。

Kubernetes 的优势（以及抽象鸿沟）

Kubernetes 之所以成为云原生应用编排的事实标准，正是因为它解决了可扩展性、稳健的网络和生态系统成熟度方面的挑战。然而，随着人工智能从短暂的推理请求演变为长时间运行的自主智能体，我们正在见证一种新的运行模式的出现。

相比之下，AI 智能体通常是隔离的、有状态的、单例工作负载。它们充当生命周期管理（LLM）的数字工作空间或执行环境。智能体需要一个持久的身份和一个安全的暂存区来编写和执行（通常是不受信任的）代码。至关重要的是，由于这些长时间运行的智能体除了短暂的活动爆发外，大部分时间都处于空闲状态，因此它们需要一个支持诸如暂停和快速恢复等机制的生命周期。

虽然理论上可以通过为每个智能体串联一个大小为 1 的 StatefulSet、一个无头服务和一个 PersistentVolumeClaim 来近似实现这一点，但大规模管理这些组件将成为运维噩梦。

由于这些独特的特性，传统的 Kubernetes 原语无法完美契合。

Kubernetes Agent Sandbox 简介

为了弥合这一差距，SIG Apps 正在开发 agent-sandbox。该项目引入了一个声明式、标准化的 API，专门针对单例、有状态工作负载（例如 AI 智能体运行时）量身定制。

该项目的核心是引入了 Sandbox CRD。它是一个轻量级的单容器环境，完全基于 Kubernetes 原语构建，提供以下功能：

针对不受信任代码的强隔离：当 AI 智能体自主生成和执行代码时，安全性至关重要。 Sandbox 自定义资源原生支持不同的运行时环境，例如 gVisor 或 Kata Containers。这为多租户、不受信任的执行提供了必要的内核和网络隔离。
生命周期管理：与针对稳定、无状态流量优化的传统 Web 服务器不同， AI 智能体作为有状态的工作空间运行，在两次任务之间可能被闲置数小时。 Agent Sandbox 支持将这些闲置环境缩减至零以节省资源，同时确保它们可以从上次中断的地方恢复。
稳定的身份：协同的多智能体系统需要稳定的网络。每个 Sandbox 都拥有稳定的主机名和网络身份，使不同的智能体能够无缝地相互发现和通信。

利用扩展来缩放智能体规模

由于人工智能领域发展迅猛，我们构建了一个扩展 API 层，以支持更快的迭代和开发。

启动一个新的 Pod 会增加大约一秒钟的开销。部署新版本的微服务时，这完全可以接受，但如果智能体在空闲后被调用，一秒钟的冷启动会中断交互的连续性。它迫使用户或编排服务等待环境配置完成，模型才能开始思考或行动。SandboxWarmPool 通过维护一个预配置的 Sandbox Pod 池来解决这个问题，从而有效地消除了冷启动。用户或编排服务只需针对 SandboxTemplate 发出 SandboxClaim，控制器就会立即将一个预热的、完全隔离的环境交给智能体。

快速入门

准备好亲自体验了吗？你可以选择最新版本，将 Agent Sandbox 的核心组件和扩展程序直接安装到你的学习或 Sandbox 集群中。

由于项目进展迅速，我们建议你使用最新版本。

# 将 “vX.Y.Z” 替换为来自 https://github.com/kubernetes-sigs/agent-sandbox/releases
# 的特定版本标签（例如，“v0.1.0”）。
export VERSION="vX.Y.Z"

# 安装核心组件：
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/manifest.yaml

# 安装扩展组件（可选）：
kubectl apply -f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/${VERSION}/extensions.yaml

# 安装 Python SDK（可选）：
# 创建一个虚拟 Python 环境
python3 -m venv .venv
source .venv/bin/activate
# 从 PyPI 安装
pip install k8s-agent-sandbox

安装完成后，你可以试用 AI 智能体的 Python SDK，或者部署一个现成的示例，看看启动一个隔离的智能体环境是多么容易。

智能体的未来在于云原生

无论是 50 毫秒的无状态任务，还是持续数周、大部分时间处于空闲状态的协作流程，通过扩展 Kubernetes，添加专为隔离的有状态单例设计的原语，我们都能充分利用云原生生态系统的强大优势。

Agent Sandbox 项目是开源且由社区驱动的。如果你正在构建 AI 平台、开发智能体框架，或者对 Kubernetes 的可扩展性感兴趣，我们诚邀您参与其中：

在 GitHub 上查看项目：kubernetes-sigs/agent-sandbox
加入 Kubernetes Slack 上的 #sig-apps 和 #agent-sandbox 频道参与讨论。

无形的重写：现代化 Kubernetes 镜像推广工具

Tue, 17 Mar 2026 00:00:00 +0000

你从 registry.k8s.io 拉取的每个容器镜像都是通过 kpromo（Kubernetes 镜像推广工具）完成的。它将镜像从临时仓库复制到生产环境，使用 cosign 进行签名，在 20 多个区域镜像间复制签名，并生成 SLSA 来源证明。如果这个工具出问题，Kubernetes 就无法发布。在过去几周里，我们从零开始重写了它的核心，删除了 20% 的代码库，使其速度大幅提升，而没有人注意到。这正是我们的目的。

一点历史

镜像推广工具始于 2018 年末，是由 Linus Arver 发起的 Google 内部项目。目标很简单：用社区拥有的、基于 GitOps 的工作流程取代手动的、由 Google 员工控制的容器镜像复制到 k8s.gcr.io 的过程。推送到临时仓库，打开一个包含 YAML 清单的 PR，获得审查和合并，自动化处理其余部分。 KEP-1734 将此提议正式化。

2019 年初，代码迁移到 kubernetes-sigs/k8s-container-image-promoter 并快速发展。在接下来的几年里，Stephen Augustus 将多个工具（cip、gh2gcs、krel promote-images、promobot-files）整合到一个名为 kpromo 的 CLI 中。仓库更名为 promo-tools。 Adolfo Garcia Veytia (Puerco) 添加了 cosign 签名和 SBOM 支持。 Tyler Ferrara 构建了漏洞扫描功能。 Carlos Panato 保持项目健康且可发布的状态。 42 位贡献者在 60 多个版本中做出了约 3,500 次提交。

它运行得很好。但到 2025 年，代码库承载了来自多个 SIG 和子项目七年增量添加的负担。 README 直白地说：你会看到重复的代码、多种完成相同任务的技术以及多个 TODO。

我们需要解决的问题

Kubernetes 核心镜像的生产推广任务通常需要 30 分钟以上，并且经常因速率限制错误而失败。核心推广逻辑已经变成一个难以扩展的单体，难以扩展且难以测试，使得添加来源证明或漏洞扫描等新功能变得非常困难。

在 SIG Release 路线图上，有两个工作项已经搁置了一段时间："重写制品推广工具"和"使制品验证更健壮"。我们在 SIG Release 会议和 KubeCon 上讨论过这些问题，项目看板 #171 上的开放研究问题记录了八个需要回答的问题，然后才能继续。

一个问题解决所有疑问

2026 年 2 月，我们打开了 Issue #1701 （"重写制品推广流水线"），并在一个跟踪 Issue 中回答了所有八个研究问题。重写是分阶段进行的，以便每个步骤都可以独立审查、合并和验证。以下是我们所做的：

Phase 1: 速率限制 (#1702)。重写了速率限制，使用自适应退避正确限制所有仓库操作。

Phase 2: 接口 (#1704)。将仓库和认证操作放在清晰的接口后面，以便可以独立替换和测试。

Phase 3: 流水线引擎 (#1705)。构建了一个流水线引擎，将推广作为一系列不同阶段运行，而不是一个大函数。

Phase 4: 来源证明 (#1706)。为临时镜像添加了 SLSA 来源验证。

Phase 5: 扫描器和 SBOM (#1709)。添加了漏洞扫描和 SBOM 支持。将默认值切换到新的流水线引擎。此时我们发布了 v4.2.0，让它在生产环境中试运行后再继续。

Phase 6: 分离签名和复制 (#1713)。将镜像签名与签名复制分离到各自的流水线阶段，消除了导致大多数生产失败的速率限制争用。

Phase 7: 移除旧流水线 (#1712)。完全删除了旧的代码路径。

Phase 8: 移除旧依赖 (#1716)。删除了审计子系统、已弃用的工具和端到端测试基础设施。

Phase 9: 删除单体 (#1718)。移除了旧的单体核心及其支持包。在第 7 到第 9 阶段删除了数千行代码。

每个阶段独立发布。第二天发布了 v4.3.0，完全移除了旧代码。

新架构就位后，一系列后续改进得以实现：并行化仓库读取 (#1736)、所有网络操作的重试逻辑 (#1742)、防止流水线挂起的每请求超时 (#1763)、 HTTP 连接复用 (#1759)、本地仓库集成测试 (#1746)、移除已弃用的凭证文件支持 (#1758)、重新设计证明处理以使用 cosign 的 OCI API 并移除已弃用的 SBOM 支持 (#1764)，以及在 in-toto 证明框架中注册的专用推广记录谓词类型 (#1767)。如果没有重写提供的清晰分离，这些改进会难上加难。 v4.4.0 发布了所有这些改进，并默认启用了来源证明生成和验证。

新的流水线

推广流水线现在有七个清晰分离的阶段：

graph LR
    Setup --> Plan --> Provenance --> Validate --> Promote --> Sign --> Attest

阶段	功能
Setup	验证选项，预热 TUF 缓存。
Plan	解析清单，读取仓库，计算需要推广的镜像。
Provenance	验证临时镜像上的 SLSA 证明。
Validate	检查 cosign 签名，模拟运行在此退出。
Promote	服务端复制镜像，保留摘要。
Sign	使用无密钥 cosign 签名推广的镜像。
Attest	使用专用的 in-toto 谓词类型生成推广来源证明。

阶段按顺序运行，因此每个阶段都获得对完整速率限制预算的独占访问权。不再有争用。镜像仓库的签名复制不再是此流水线的一部分，而是作为一个专门的定期 Prow job 运行。

使其更快

架构就位后，我们转向性能优化。

并行仓库读取 (#1736)：计划阶段读取 1,350 个仓库。我们将其并行化，计划阶段从大约 20 分钟降至约 2 分钟。

两阶段标签列出 (#1761)：不是检查 20 多个镜像上的所有 46,000 个镜像组，我们首先只检查源仓库。大约 57% 的镜像根本没有签名，因为它们是在签名启用之前推广的。我们完全跳过这些，将 API 调用减少大约一半。

复制前的源检查 (#1727)：在遍历给定镜像的所有镜像仓库之前，我们首先检查签名是否存在于主仓库上。在大多数签名已经复制的稳定状态下，这将工作从大约 17 小时减少到约 15 分钟。

每请求超时 (#1763)：我们观察到间歇性挂起，停滞的连接阻塞流水线超过 9 小时。现在每个网络操作都有自己的超时，临时失败会自动重试。

连接复用 (#1759)：我们开始在操作间复用 HTTP 连接和认证状态，消除了冗余的令牌协商。这解决了一个长期存在的请求（始于 2023 年）。

数字说明

以下是重写的总体情况。

合并了 40 多个 PR，发布了 3 个版本（v4.2.0、 v4.3.0、 v4.4.0）
添加了超过 10,000 行代码，删除了超过 16,000 行代码，净减少约 5,000 行（代码库缩小 20%）
性能全面大幅提升
通过重试逻辑、每请求超时和自适应速率限制提高了健壮性
关闭了 19 个长期存在的问题

代码库缩小了五分之一，同时获得了来源证明、流水线引擎、漏洞扫描集成、并行化操作、重试逻辑、针对本地仓库的集成测试以及独立的签名复制模式。

非用户可见的变更

这是一个硬性要求。kpromo cip 命令接受相同的标志并读取相同的 YAML 清单。 post-k8sio-image-promo Prow 作业在整个过程中继续工作。 kubernetes/k8s.io 中的推广清单没有变化。没有人需要更新他们的工作流程或配置。

我们在生产环境早期发现了两个回归问题。一个 (#1731) 导致仓库密钥不匹配，使每个镜像都显示为"丢失"，因此没有任何镜像被推广。另一个 (#1733) 将默认线程数设置为零，阻塞了所有 goroutine。两者都在几小时内修复。分阶段发布策略（v4.2.0 包含新引擎， v4.3.0 移除旧代码）为我们提供了一条清晰的回滚路径，幸运的是我们从未需要使用它。

下一步

跨所有镜像仓库的签名复制仍然是推广周期中最昂贵的部分。 Issue #1762 提议通过让 archeio（registry.k8s.io 重定向服务）将签名标签请求路由到单个规范上游，而不是每个区域的后端，来完全消除它。另一个选择是将签名移到更接近仓库基础设施本身的位置。这两种方法都需要与 SIG Release 和基础设施团队进一步讨论，但任何一种都会在每个推广周期中减少数千次 API 调用，并进一步简化代码库。

致谢

这个项目是一个跨越七年的社区努力。感谢 Linus、 Stephen、 Adolfo、 Carlos、 Ben、 Marko、 Lauri、 Tyler、 Arnaud，以及多年来贡献代码、审查和规划的许多其他人。 SIG Release 和发布工程社区为重写每个 Kubernetes 版本都依赖的基础设施提供了背景、讨论和耐心。

如果你想参与，请加入 Kubernetes Slack 上的 #release-management 频道，或查看仓库。

宣布成立 AI 网关工作组

Mon, 09 Mar 2026 10:00:00 -0800

Kubernetes 社区包含多个特别兴趣小组（SIG）和工作组（WG），旨在促进相关贡献者之间就重要议题展开讨论。今天，我们很高兴地宣布成立 AI 网关工作组，这是一项专注于为 Kubernetes 环境中支持 AI 工作负载的网络基础设施制定标准和最佳实践的新举措。

什么是 AI 网关？

在 Kubernetes 环境中，AI 网关指的是网络网关基础设施（包括代理服务器、负载均衡器等），它通常实现 Gateway API 规范，并针对 AI 工作负载提供增强功能。 AI 网关并非定义一个独立的产品类别，而是描述旨在对 AI 流量实施策略的基础设施，包括：

基于 token 的 AI API 速率限制。
推理 API 的细粒度访问控制。
有效负载检查，实现智能路由、缓存和防护机制。
支持 AI 特有的协议和路由模式。

工作组章程和使命

AI 网关工作组遵循清晰的章程运作，其使命是为 Kubernetes 特别兴趣小组（SIG）及其子项目制定提案。其主要目标包括：

标准制定：为 Kubernetes 中的 AI 工作负载网络创建声明式 API、标准和指南。
社区协作：促进讨论并就 AI 基础设施的最佳实践达成共识。
可扩展架构：确保 AI 专用网关扩展的可组合性、可插拔性和有序处理。
基于标准的方法：基于已建立的网络基础，在成熟的标准之上构建 AI 专用功能。

活跃提案

AI 网关工作组目前有多个活跃提案，旨在解决 AI 工作负载网络领域的关键挑战：

有效载荷处理

有效载荷处理提案旨在满足 AI 工作负载检查和转换完整 HTTP 请求和响应有效载荷的关键需求。

这可以实现：

AI 推理安全

防御恶意提示和提示注入攻击。
对 AI 响应进行内容过滤。
对 AI 流量进行基于特征的检测和异常检测。

AI 推理优化

基于请求内容的语义路由。
智能缓存，以降低推理成本并缩短响应时间。
集成 RAG 系统，以增强上下文信息。

该提案定义了声明式有效载荷处理器配置、有序处理流水线和可配置故障模式的标准 —— 所有这些对于生产级 AI 工作负载部署都至关重要。

出口网关

现代 AI 应用越来越依赖外部推理服务，无论是用于构建专用模型、实现故障转移，还是优化成本。

出口网关提案旨在定义将流量安全地路由到集群外部的标准。主要特性包括：

外部 AI 服务集成

安全访问云端 AI 服务（OpenAI、Vertex AI、Bedrock 等）。
为第三方 AI API 提供托管身份验证和令牌注入。
具备区域合规性和故障转移功能。

高级流量管理

为外部 FQDN 和服务定义后端资源。
TLS 策略管理和证书颁发机构控制。
为集中式 AI 基础设施提供跨集群路由。

我们正在解决的用户场景

提供外部 AI 服务托管访问的平台运营商。
需要跨多个云提供商进行推理故障转移的开发人员。
执行 AI 流量区域限制的合规工程师。
将 AI 工作负载集中部署在专用集群上的组织。

即将举行的活动

KubeCon + CloudNativeCon Europe 2026，阿姆斯特丹

AI 网关工作组成员将在阿姆斯特丹举行的 KubeCon + CloudNativeCon Europe 上发表演讲，探讨人工智能与网络交叉领域的问题，包括工作组正在推进的提案，以及 AI 网关与模型上下文协议（MCP）和代理网络模式的交叉应用。本次会议将展示 AI 网关工作组的提案如何为下一代 AI 部署和通信模式构建所需的基础设施。会议还将介绍工作组路线图的初始设计、早期原型和新兴方向。更多详情，请点击此处查看我们的会议：

AI 已抵达网关！Kubernetes 中的 AI 网关工作组简介

参与其中

AI 网关工作组代表 Kubernetes 社区致力于 AI 工作负载网络标准化。随着 AI 日益融入现代应用，我们需要强大且标准化的基础设施，以满足推理工作负载的独特需求，同时保持 Kubernetes 用户所期望的安全性、可观测性和可靠性标准。

我们的提案目前正在积极开发中，并已开始在各个网关项目中实施。我们正与 SIG Network 紧密合作，增强网关 API，并与更广泛的云原生社区协作，以确保我们的标准能够满足实际生产需求。

无论您是网关实现者、平台运维人员、AI 应用开发者，还是仅仅对 Kubernetes 和 AI 的交叉领域感兴趣，我们都欢迎您的参与。工作组采用开放贡献模式——您可以查看我们的提案、参加每周例会，或在我们的 GitHub 代码库上发起讨论。

了解更多信息：

访问工作组的 GitHub 代码库。
阅读工作组的章程。
参加每周四下午 2 点（美国东部时间）的每周例会。
加入工作组的 Slack 频道（#wg-ai-gateway）（访问 https://slack.k8s.io/ 获取邀请）。
加入 AI Gateway 邮件列表（https://groups.google.com/a/kubernetes.io/g/wg-ai-gateway）。

Kubernetes 中 AI 基础设施的未来正在构建中，加入我们，了解如何贡献力量，帮助塑造 Kubernetes 中 AI 感知网关功能的未来。

SIG Architecture 聚焦：API 治理

Thu, 12 Feb 2026 00:00:00 +0000

这是 SIG Architecture 聚焦系列的第五篇访谈，将介绍不同的子项目。本篇聚焦 SIG Architecture：API 治理。

在这篇 SIG Architecture 聚焦访谈中，我们采访了 API 治理子项目负责人 Jordan Liggitt。

介绍

FM：Jordan 你好，感谢你接受采访。请先简单介绍一下你自己、你的职责，以及你是如何参与 Kubernetes 的。

JL：我叫 Jordan Liggitt。我是一名基督徒、丈夫、四个孩子的父亲，白天在 Google 做软件工程师，私下还是个业余音乐人。我出生在德克萨斯州（现在也仍然喜欢把那里称作自己的起点），但我人生大部分时间都生活在北卡罗来纳州。

我从 2014 年开始参与 Kubernetes。当时我在 Red Hat 负责认证和授权，提交给 Kubernetes 的第一个 PR 是尝试给 Kubernetes API 服务器增加一个 OAuth 服务器。那个 PR 最终一直停留在 WIP 状态，没有合并。后来我换了一种方式，在另一个项目里以“叠加在核心 Kubernetes API 服务器之上”的思路来实现（这也可以看作后文的一个伏笔），六个月后我关闭了那个 PR。

尽管开局如此，我还是持续参与了进来，帮助构建 Kubernetes 的认证与授权能力，并从早期的 Beta API（例如 v1beta3）到 v1 的过程中参与核心 Kubernetes API 的定义与演进。基于这些贡献，我在 2016 年被标记为 API reviewer，并在 2017 年成为 API approver。

现在，我在 SIG Architecture 里共同负责 API 治理和代码组织两个子项目，同时也是 SIG Auth 的技术负责人。

FM：那你是什么时候开始具体参与 API 治理项目的？

JL：大约在 2019 年。

API 治理的目标与范围

FM：你会如何描述这个子项目的主要目标，以及它介入的领域？

这个领域覆盖 Kubernetes 的各种 API，而且有一些“大家未必意识到它是 API”的接口：命令行参数、配置文件、二进制如何运行、它们如何与容器运行时这类后端组件通信，以及如何持久化数据。很多人提到“API”时只想到 REST API。它当然是最大、最显眼、受众最多的一类，但这些其他表面同样也是 API。它们的受众更窄，因此灵活性更高一些，但依然需要认真对待。

我们的目标是在保持稳定的同时继续推动创新。如果你什么都不改，稳定当然最容易做到，但那也和演进、增长的目标相冲突。所以我们要在“保持稳定”和“允许变化”之间取得平衡。

FM：说到变化。为了确保一致性和质量（这显然也是这个项目存在的原因之一）， Kubernetes 变更生命周期里有哪些具体的质量门禁？ API 治理是在发布周期中介入，还是通过前置指南介入，或者是在两者之间？你们在哪些时间点来确保这个职责真正落地？

JL：我们有指南和约定，既包含 API 通用规范，也包含 API 变更规范。这些都是“活文档”，会随着新场景不断更新。它们内容很多、也比较密集，所以我们还会在设计阶段或实现阶段实际参与来配合。

有时候受限于带宽，团队会在没有得到 API Review 反馈的情况下先推进设计。这没问题，但这也意味着实现开始时才会进行 API 评审，届时可能会出现比较大范围的反馈。因此，无论是创建新 API，还是修改既有 API，我们都会在设计阶段或实现阶段介入。

FM：这是发生在 Kubernetes Enhancement Proposal（KEP）流程里吗？既然增强功能必须走 KEP，我理解其中一部分会和 API 治理交叉。

JL：KEP 的详细程度差异很大。有些 KEP 会直接给出 API 定义。遇到这种情况，我们就可以在设计阶段做 API 评审，随后实现阶段主要就是核对是否忠实于设计。

尽早介入是理想状态。但有些 KEP 更偏概念，把细节留给实现阶段。这并不错误，只是意味着实现会更偏探索式。这样 API Review 的介入就会更晚，并且可能会建议结构性调整。

无论哪种方式都有取舍：前期做更详细的设计，还是在实现中迭代发现。不同人和团队有不同工作方式，我们保持灵活，也乐于在前期或实现阶段提供咨询。

FM：这让我想到 Fred Brooks 在《人月神话》中提到的观点：概念完整性是产品质量的核心。无论流程怎么组织，总得有一个环节去审视即将落地的内容，确保概念完整性。Kubernetes 到处都在使用 API（对外和对内都有），所以 API 治理对维护这种完整性至关重要。这个是如何被固化下来的？

JL：是的，约定文档沉淀了我们长期积累的模式：不同场景下该怎么做。我们还有自动化 lint 和检查项，来保障例如 spec/status 语义这类模式的正确性。这些自动化工具能在人工遗漏时帮助我们发现问题。

当新场景出现时（而且一直在出现），我们会思考应对方式，并把结论回灌到文档和工具里。有时需要尝试几轮，才能收敛到一个真正好用的方案。

FM：确实。每次新的互动都会让指南更好。

JL：没错。有时候第一种做法最后会被证明不够好，可能要经历两三次迭代才能得到稳健的结果。

Custom Resource Definition 带来的影响

FM：在你的经验里，有没有某个变化、事件或领域特别值得一提，或者特别复杂、特别有意思？

JL：真正的分水岭是 Custom Resources。在那之前，每个 API 都是我们手工定义并完整评审的。虽然也有不一致之处，但每个类型和字段我们都清楚、也都能控制。

Custom Resources 出现之后，任何人都可以定义任何内容。第一个版本甚至不要求 schema。这让它功能极其强大，立即释放了创新空间，但也让我们在稳定性和一致性方面开始追赶。

当 Custom Resources 晋升到 GA 后，schema 成为必需，但出于向后兼容仍保留了一些“逃生口”。从那时起，我们一直在努力让 CRD 作者获得与内置资源接近的校验能力。而 CRD 的内置校验规则也只是最近几个版本才达到 GA。

所以，CRD 开启了“几乎任何内容都可以定义”的阶段。而内置校验规则是第二个重要里程碑：把一致性重新带回来。

这一路上的三个核心主题是：定义 schema、校验数据，以及处理既有的无效数据。借助渐进式收紧校验（在不破坏现有对象的前提下允许数据逐步改进），我们现在可以在不破坏既有对象的情况下，引导 CRD 作者遵循约定。

API 治理在整体中的位置

FM：API 治理和 SIG Architecture、API Machinery 分别是什么关系？

JL：API Machinery 提供的是构建 API 的实际代码和工具。他们不会去评审存储、网络、调度等领域的 API 本身。

SIG Architecture 负责系统整体方向，并与 API Machinery 协作，确保系统能力能支撑这个方向。 API 治理则和其他基于这套基础设施构建能力的 SIG 协作，定义约定与模式，确保大家以一致方式使用 API Machinery 提供的能力。

FM：谢谢，这样流程就很清晰了。再回到发布周期：增强冻结、代码冻结这些阶段会改变你们的工作负载吗？还是说 API 治理更多是持续性的工作？

JL：我们主要在两个地方介入：设计和实现。增强冻结前，设计相关介入会增加；代码冻结前，实现相关介入会增加。不过很多工作会跨多个发布周期，所以即便是在相对平缓的阶段，也始终会有一些面向未来版本的设计与实现在推进。在这些高强度时段之间，我们通常会有时间投入长期设计工作。

我们看到的一个反模式是：团队构思一个大特性几个月，然后在增强冻结前三周才拿出来说“这是设计，请评审”。对这类有 API 影响的大变更，更好的做法是尽早让 API 治理参与进来。

而且发布周期里确实有适合做这件事的窗口期，比如两个冻结阶段之间，大家带宽相对更充足。这是做长期评审工作的最佳时机。

如何参与

FM：很明确。那从团队协作和新贡献者角度看，大家可以如何参与 API 治理？应该从什么入手？

JL：通常最好的办法是跟一个具体变更，而不是试图一次性学完所有东西。挑一个小 API 变更，可以是别人正在做的，也可以是你自己想做的，然后完整观察它的全流程：设计、实现、评审。

高带宽评审（例如视频实时讨论）通常非常有效。如果你正在做或跟踪某个变更，可以问问是否能约个时间一起过设计或 PR。旁听这类讨论会非常有帮助。

先从小变更开始，再做更大的，再到一个全新的 API。这样你会逐步理解这些约定在实践中是如何应用的。

FM：非常好。最后还有什么想补充的吗？

JL：有。我们之所以如此重视兼容性和稳定性，是为了用户。对贡献者来说，这些要求有时像痛苦的阻碍，妨碍重构或带来繁琐工作；但用户已经把自己的系统和我们集成在一起，而我们对他们有承诺：我们希望他们相信，我们不会打破这份契约。所以即使这意味着更多工作、更慢节奏，甚至需要重复实现，我们依然选择稳定性。

我们并不是想设置障碍，而是希望让用户有更好的使用体验。

我们很多问题都在关注未来：你现在想做的这个东西，以后如何演进而不破坏兼容性？我们假设未来会知道得更多，因此希望设计能为未来变化留出空间。

我们也假设自己会犯错。那关键问题就是：如何给自己留下改进通道，同时继续履行兼容性承诺？

FM：完全同意。Jordan，谢谢你，我想我们已经覆盖了所有关键点。这次访谈让大家对 API 治理项目及其在 Kubernetes 全局中的作用有了非常清晰的认识。

JL：谢谢。

节点就绪控制器简介

Tue, 03 Feb 2026 10:00:00 +0800

在标准的 Kubernetes 模型中，节点是否适合运行工作负载取决于一个简单的“就绪”状态。然而，在现代 Kubernetes 环境中，节点需要复杂的底层架构依赖项（例如网络代理、存储驱动程序、GPU 固件或自定义健康检查）才能完全运行，从而可靠地托管 Pod。

今天，我代表 Kubernetes 项目宣布推出节点就绪控制器。

该项目引入了一个声明式系统来管理节点污点，从而在节点启动过程中扩展了就绪保护机制，使其超越了标准条件。

通过基于自定义健康信号动态管理污点，该控制器确保工作负载仅部署在满足所有底层架构特定要求的节点上。

为什么需要节点就绪控制器？

对于具有复杂引导要求的集群，Kubernetes 核心节点的“就绪”状态通常不足以满足需求。运维人员经常需要确保特定的 DaemonSet 或本地服务在节点进入调度池之前处于健康状态。

节点就绪控制器通过允许运维人员定义针对特定节点组的自定义调度门控来弥补这一不足。这使你能够在异构集群中强制执行不同的就绪要求，例如，确保配备 GPU 的节点只有在验证了专用驱动程序后才能接受 Pod，而通用节点则遵循标准路径。

它提供三大主要优势：

自定义就绪状态定义：定义特定平台上的“就绪”状态。
自动化污点管理：控制器会根据状态自动应用或移除节点污点，防止 Pod 部署到未就绪的基础设施上。
声明式节点引导：可靠地管理多步骤节点初始化，并清晰地观察引导过程。

核心概念和特性

控制器以节点就绪规则（NodeReadinessRule，NRR）API 为核心，该 API 允许你为节点定义声明式的“门控”。

灵活的强制执行模式

控制器支持两种不同的运行模式：

持续强制执行: 在节点的整个生命周期内主动维护就绪保证。如果关键依赖项（例如设备驱动程序）之后发生故障，则该节点会立即被标记为“已污染”，以防止新的调度。
仅引导强制执行: 专门用于一次性初始化步骤，例如预拉取大型镜像或硬件配置。一旦满足条件，控制器会将引导过程标记为已完成，并停止监控该节点的该特定规则。

状态报告

控制器响应节点状态，而非自行执行健康检查。这种解耦设计使其能够与生态系统中现有的其他工具以及自定义解决方案无缝集成：

节点问题检测器（NPD）：使用现有的 NPD 配置和自定义脚本来报告节点健康状况。
就绪状态报告器：项目提供的一个轻量级代理，可以部署用于定期检查本地 HTTP 端点并相应地更新节点状态。

通过试运行确保运行安全

在整个集群中部署新的就绪规则存在固有风险。为了降低这种风险，试运行模式允许运维人员首先模拟对集群的影响。在此模式下，控制器会记录预期操作并更新规则状态以显示受影响的节点，而无需实际应用污点，从而在强制执行前实现安全验证。

示例：CNI 引导

以下 NodeReadinessRule 确保节点在 CNI 代理正常工作之前保持不可调度状态。控制器监控自定义的 cniplugin.example.net/NetworkReady 条件，并且仅当该状态为 True 时才移除 readiness.k8s.io/acme.com/network-unavailable 污点。

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: network-readiness-rule
spec:
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/acme.com/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

演示：

参与方式

节点就绪控制器（Node Readiness Controller）刚刚起步，我们的初始版本已经发布，我们正在寻求社区反馈以完善路线图。继我们在 KubeCon NA 2025 上富有成效的非正式会议讨论之后，我们很高兴能继续进行线下交流。

欢迎参加 KubeCon + CloudNativeCon Europe 2026 的维护者专场会议： 解决非确定性调度问题：节点就绪控制器简介。

与此同时，你可以通过以下方式贡献力量或关注我们的进展：

GitHub：https://sigs.k8s.io/node-readiness-controller
Slack：加入 #sig-node-readiness-controller 参与讨论
文档：入门指南

Ingress NGINX：Kubernetes 指导委员会和安全响应委员会的声明

Thu, 29 Jan 2026 00:00:00 +0000

Kubernetes 将于 2026 年 3 月停止维护 Ingress NGINX，该基础设施是大约一半云原生环境的关键组成部分。 Ingress NGINX 的停止维护计划已于 2026 年 3 月正式宣布，此前多年来， Kubernetes 一直公开警告该项目急需贡献者和维护者。项目停止维护后，将不再发布任何错误修复、安全补丁或任何类型的更新。此事不能被忽视、敷衍了事，更不能拖延到最后一刻才处理。我们再怎么强调这种情况的严重性，以及立即开始迁移到替代方案（例如 Gateway API 或众多第三方 Ingress 控制器）的重要性都不为过。

必须明确指出：在 Ingress NGINX 退役后继续使用，将使你和你的用户面临攻击风险。目前没有任何替代方案可以直接替换 Ingress NGINX。这需要规划和工程时间。大约一半的用户会受到影响。你还有两个月的时间来准备。

现有部署将继续运行，因此，除非你主动检查，否则你可能直到系统遭到入侵才会意识到自己受到影响。 在大多数情况下，你可以使用集群管理员权限运行 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 命令，来检查你是否依赖于 Ingress NGINX。

尽管 Ingress NGINX 项目广受欢迎，被各种规模的公司广泛使用，而且维护者也多次呼吁贡献者加入，但它始终未能获得急需的贡献者。根据 Datadog 的内部研究，目前约有 50% 的云原生环境依赖于该工具，然而在过去的几年里，它一直由一两个人利用业余时间维护。由于没有足够的人员来将该工具维护到我们和用户都认为安全的水平，负责任的选择是逐步停止该项目，并将精力重新集中到诸如 Gateway API 等现代替代方案上。

我们做出这个决定并非轻率之举；尽管目前会带来诸多不便，但为了所有用户和整个生态系统的安全，这是必要的。遗憾的是，Ingress NGINX 最初设计的灵活性 —— 曾经是一大优势——如今却成了无法解决的负担。由于技术债务不断累积，以及一些根本性的设计决策加剧了安全漏洞，即便未来资源到位，继续维护该工具也已不再合理，甚至不可能。

我们联合发布此声明，旨在强调此次变更的规模之大，以及若忽视此问题可能对相当一部分 Kubernetes 用户造成严重风险。你务必立即检查你的集群。如果你依赖 Ingress NGINX，则必须开始规划迁移。

谢谢，

Kubernetes 指导委员会

Kubernetes 安全响应委员会

使用 kind 体验 Gateway API

Wed, 28 Jan 2026 00:00:00 +0000

本文档将指导你在 kind 上设置一个使用 Gateway API 的本地实验环境。此设置专为学习和测试而设计，可帮助你在没有生产环境复杂性的情况下理解 Gateway API 概念。

注意：

这是一个实验性学习设置，不应用于生产环境。本文档中使用的组件不适合生产使用。当你准备在生产环境中部署 Gateway API 时，请选择适合你需求的实现。

概述

在本指南中，你将：

使用 kind（Kubernetes in Docker）设置本地 Kubernetes 集群
部署 cloud-provider-kind，它提供 LoadBalancer Service 和 Gateway API 控制器
创建 Gateway 和 HTTPRoute 以将流量路由到演示应用
在本地测试你的 Gateway API 配置

此设置非常适合学习、开发和体验 Gateway API 概念。

前提条件

在开始之前，请确保你的本地机器上安装了以下工具：

Docker - 运行 kind 和 cloud-provider-kind 所需
kubectl - Kubernetes 命令行工具
kind - Kubernetes in Docker
curl - 测试路由所需

创建 kind 集群

运行以下命令创建一个新的 kind 集群：

kind create cluster

这将创建一个在 Docker 容器中运行的单节点 Kubernetes 集群。

安装 cloud-provider-kind

接下来，你需要 cloud-provider-kind，它为此设置提供两个关键组件：

为 LoadBalancer 类型的 Service 分配地址的 LoadBalancer 控制器
实现 Gateway API 规范的 Gateway API 控制器

它还会自动在你的集群中安装 Gateway API 的自定义资源定义（CRD）。

在创建 kind 集群的同一主机上，将 cloud-provider-kind 作为 Docker 容器运行：

VERSION="$(basename $(curl -s -L -o /dev/null -w '%{url_effective}' https://github.com/kubernetes-sigs/cloud-provider-kind/releases/latest))"
docker run -d --name cloud-provider-kind --rm --network host -v /var/run/docker.sock:/var/run/docker.sock registry.k8s.io/cloud-provider-kind/cloud-controller-manager:${VERSION}

注意：在某些系统上，你可能需要提升权限才能访问 Docker socket。

验证 cloud-provider-kind 是否正在运行：

docker ps --filter name=cloud-provider-kind

你应该看到容器已列出并处于运行状态。你也可以检查日志：

docker logs cloud-provider-kind

体验 Gateway API

现在你的集群已设置完成，你可以开始体验 Gateway API 资源。

cloud-provider-kind 会自动提供一个名为 cloud-provider-kind 的 GatewayClass。你将使用此类来创建你的 Gateway。

值得注意的是，虽然 kind 不是云提供商，但该项目命名为 cloud-provider-kind，因为它提供模拟云环境的功能。

部署 Gateway

以下清单将：

创建一个名为 gateway-infra 的新命名空间
部署一个监听端口 80 的 Gateway
接受主机名匹配 *.exampledomain.example 模式的 HTTPRoute
允许来自任何命名空间的路由附加到 Gateway。注意：在实际集群中，建议在 allowedRoutes namespace selector 字段上使用 Same 或 Selector 值来限制附加。

应用以下清单：

---
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: gateway-infra
spec:
  gatewayClassName: cloud-provider-kind
  listeners:
  - name: default
    hostname: "*.exampledomain.example"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All

然后验证你的 Gateway 是否已正确编程并分配了地址：

kubectl get gateway -n gateway-infra gateway

预期输出：

NAME      CLASS                 ADDRESS      PROGRAMMED   AGE
gateway   cloud-provider-kind   172.18.0.3   True         5m6s

PROGRAMMED 列应显示 True，ADDRESS 字段应包含 IP 地址。

部署演示应用

接下来，部署一个简单的 echo 应用来帮助你测试 Gateway 配置。此应用：

监听端口 3000
回显请求详情，包括路径、头部和环境变量
在名为 demo 的命名空间中运行

应用以下清单：

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: echo
  name: echo
  namespace: demo
spec:
  ports:
  - name: http
    port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app.kubernetes.io/name: echo
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: echo
  name: echo
  namespace: demo
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: echo
  template:
    metadata:
      labels:
        app.kubernetes.io/name: echo
    spec:
      containers:
      - env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        image: registry.k8s.io/gateway-api/echo-basic:v20251204-v1.4.1
        name: echo-basic

创建 HTTPRoute

现在创建一个 HTTPRoute，将流量从你的 Gateway 路由到 echo 应用。此 HTTPRoute 将：

响应对主机名 some.exampledomain.example 的请求
将流量路由到 echo 应用
附加到 gateway-infra 命名空间中的 Gateway

应用以下清单：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
  namespace: demo
spec:
  parentRefs:
  - name: gateway
    namespace: gateway-infra
  hostnames: ["some.exampledomain.example"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: echo
      port: 3000

测试路由

最后一步是使用 curl 测试你的路由。你将使用主机名 some.exampledomain.example 向 Gateway 的 IP 地址发出请求。以下命令仅适用于 POSIX shell，可能需要根据你的环境进行调整：

GW_ADDR=$(kubectl get gateway -n gateway-infra gateway -o jsonpath='{.status.addresses[0].value}')
curl --resolve some.exampledomain.example:80:${GW_ADDR} http://some.exampledomain.example

你应该收到类似以下的 JSON 响应：

{
 "path": "/",
 "host": "some.exampledomain.example",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/8.15.0"
  ]
 },
 "namespace": "demo",
 "ingress": "",
 "service": "",
 "pod": "echo-dc48d7cf8-vs2df"
}

如果你看到此响应，恭喜你！你的 Gateway API 设置工作正常。

故障排除

如果某些内容未按预期工作，你可以通过检查资源状态进行故障排除。

检查 Gateway 状态

首先，检查你的 Gateway 资源：

kubectl get gateway -n gateway-infra gateway -o yaml

查看 status 部分的条件。你的 Gateway 应该有：

Accepted: True - Gateway 已被控制器接受
Programmed: True - Gateway 已成功配置
.status.addresses 填充了 IP 地址

检查 HTTPRoute 状态

接下来，检查你的 HTTPRoute：

kubectl get httproute -n demo echo -o yaml

检查 status.parents 部分的条件。常见问题包括：

ResolvedRefs 设置为 False，原因是 BackendNotFound；这意味着后端 Service 不存在或名称错误
Accepted 设置为 False；这意味着路由无法附加到 Gateway（检查命名空间权限或主机名匹配）

后端未找到时的示例错误：

status:
  parents:
  - conditions:
    - lastTransitionTime: "2026-01-19T17:13:35Z"
      message: backend not found
      observedGeneration: 2
      reason: BackendNotFound
      status: "False"
      type: ResolvedRefs
    controllerName: kind.sigs.k8s.io/gateway-controller

检查控制器日志

如果资源状态没有揭示问题，请检查 cloud-provider-kind 日志：

docker logs -f cloud-provider-kind

这将显示 LoadBalancer 和 Gateway API 控制器的详细日志。

清理

当你完成实验后，可以清理资源：

删除 Kubernetes 资源

删除命名空间（这将删除其中的所有资源）：

kubectl delete namespace gateway-infra
kubectl delete namespace demo

停止 cloud-provider-kind

停止并移除 cloud-provider-kind 容器：

docker stop cloud-provider-kind

由于容器是使用 --rm 标志启动的，停止时会自动移除。

删除 kind 集群

最后，删除 kind 集群：

kind delete cluster

下一步

现在你已经在本地体验了 Gateway API，准备好探索生产就绪的实现了：

生产部署：查看 Gateway API 实现以找到符合你生产要求的控制器
了解更多：探索 Gateway API 文档了解 TLS、流量拆分和头部操作等高级功能
高级路由：按照 Gateway API 用户指南体验基于路径的路由、头部匹配、请求镜像和其他功能

最后提醒

这个 kind 设置仅用于开发和学习。对于实际工作负载，请始终使用生产级的 Gateway API 实现。

Headlamp 2025 年度项目亮点

Thu, 22 Jan 2026 10:00:00 +0800

本公告是对最初在 Headlamp 博客上发布的帖子的回顾。

Headlamp 在 2025 年取得了长足的发展。该项目持续成长，覆盖了更多平台和团队；通过插件机制支持了新的工作流和集成方式；同时也看到了来自更广泛社区的协作不断增强。

我们想借此机会分享一些最新进展，并重点介绍 Headlamp 在过去一年中的演进与变化。

更新

加入 Kubernetes SIG UI

今年标志着该项目的一个重要里程碑：Headlamp 现已成为 Kubernetes SIG UI 的正式组成部分。此举使路线图和设计讨论更贴近 Kubernetes 核心社区，并强化了 Headlamp 作为该项目现代化、可扩展 UI 的角色。

作为其中的一部分，我们还分享了更多关于让 Kubernetes 面向更广泛受众的内容，包括在 Enlightening with Whitney Lee 上的亮相以及在 KCD New York 2025 上的演讲。

Linux Foundation 导师计划

今年，我们很高兴通过 Linux Foundation 的导师计划与多名学生合作，我们的学员已经在 Headlamp 上留下了明显的印记：

Adwait Godbole 构建了 KEDA 插件，在 Headlamp 中添加了用于查看和管理 KEDA 资源（如 ScaledObjects 和 ScaledJobs）的 UI。

Dhairya Majmudar 为 Headlamp 设置了基于 OpenTelemetry 的可观测性堆栈，连接指标、日志和追踪，使项目更易于监控和调试。

Aishwarya Ghatole 领导了 Headlamp 插件的 UX 审计，识别可用性问题，并提出设计改进和插件用户画像。

Anirban Singha 开发了 Karpenter 插件，为 Headlamp 提供了专注于 Karpenter 自动扩缩容资源和决策的视图。

Aditya Chaudhary 改进了 Gateway API 支持，你可以在资源映射上看到网络关系，以及对许多新的 Gateway API 资源的改进支持。

Faakhir Zahid 完成了一种在集群中部署 Headlamp 时轻松管理插件安装的方法。

Saurav Upadhyay 致力于 Kubernetes API 调用的后端缓存，减少 API 服务器负载并提高 Headlamp 的性能。

新变更

多集群视图

管理多个集群具有挑战性：团队经常在工具之间切换，在尝试查看哪些内容在哪里运行时失去上下文。 Headlamp 通过提供单一视图来并排比较集群来解决这个问题。这使得跨环境理解工作负载变得更容易，并减少了查找资源所花费的时间。

View of multi-cluster workloads

项目

Kubernetes 应用通常跨越多个命名空间和资源类型，这使得故障排除感觉像是在拼拼图一样。我们添加了项目（Projects），为你提供以应用为中心的视图，将相关资源分组到多个命名空间——甚至集群中。这使你能够减少蔓延、更快地进行故障排除，并在无需深入研究 YAML 或集群范围列表的情况下进行协作。

View of the new Projects feature

变更：

新的"项目（Projects）"特性，用于将命名空间分组为以应用或团队为中心的项目

可扩展的项目详细信息视图，插件可以使用自己的标签页和操作进行自定义

Kubernetes 中的日常运维通常意味着在集群之间处理日志、终端、YAML 和仪表板。我们重新设计了 Headlamp 的导航，将这些视为一流的"活动"，你可以保持打开并随时返回，而不是在点击离开后立即丢失的一次性视图。

View of the new task bar

变更：

新的任务栏/活动模型允许你将日志、exec 会话和详细信息固定为正在进行的活动

活动概览，带有"全部关闭"操作和集群信息

表格中的多选和全局过滤器

感谢 Jan Jansen 和 Aditya Chaudhary。

搜索和映射

当生产环境中出现问题时，前两个问题通常是"它在哪里？"和"它连接到什么？"我们升级了搜索和映射视图，以便你可以更快地从高级症状定位到正确的对象集。

View of the new Advanced Search feature

变更：

高级搜索视图，支持对 Kubernetes 对象进行丰富的、基于表达式的查询

改进的全局搜索，理解标签和多个搜索项，甚至可以根据你找到的内容更新当前命名空间

网络部分中的 EndpointSlice 支持

更丰富的映射视图，现在包括自定义资源和 Gateway API 对象

感谢来自 Swisscom 的 Fabian、Alexander North 和 Victor Marcolino，以及 Aditya Chaudhary。

OIDC 和身份认证

我们在使 OIDC 设置更清晰、更具弹性方面做了实际工作，特别是对于集群内部署。

View of user information for OIDC clusters

变更：

在顶部栏中为 OIDC 认证用户显示用户信息

PKCE 支持更安全的身份认证流程，以及强化的令牌刷新处理

使用 -oidc-use-access-token=true 使用访问令牌的文档

改进了对 AKS 和 EKS 等公共 OIDC 客户端的支持

使用 OAuth2Proxy 在 AKS 上使用 Azure Entra-ID 设置 Headlamp 的新指南

感谢 David Dobmeier 和 Harsh Srivastava。

应用目录和 Helm

我们扩展了通过 Headlamp 部署和获取应用的方式，特别是支持原生 Helm 仓库。

变更：

功能更强大的 Helm chart，具有可选的后端 TLS 终止、PodDisruptionBudgets、自定义 Pod 标签等

改进了 Helm chart 中的格式并添加了缺失的访问令牌参数

新的集群内 Helm 支持，带有 --enable-helm 标志和服务代理

感谢来自 Oracle 的 Vrushali Shah 和 Murali Annamneni，以及 Pat Riehecky、Joshua Akers、 Rostislav Stříbrný、Rick L 和 Victor。

性能、可访问性和用户体验

最后，我们在你每天注意到但不总是成为头条的事情上花费了大量时间：启动时间、列表视图、日志查看器、可访问性以及小的网络 UX 细节。持续的可访问性自我审计也帮助我们识别关键问题，并使 Headlamp 更易于每个人使用。

View of the Learn section in docs

变更：

显著的桌面改进，应用加载速度提高高达 60%，为贡献者提供更快的开发模式重载

大量表格和日志查看器改进：持久排序顺序、一致的行操作、复制名称按钮、更好的工具提示以及更宽松的日志输入

可访问性和本地化改进，包括修复与缩放相关的布局问题、更好的颜色对比度、改进的屏幕阅读器支持以及扩展的语言覆盖范围

对资源的更多控制，包括实时 Pod CPU/内存指标、更丰富的 Pod 详细信息以及 Secret 和 CRD 字段的内联编辑

刷新的文档和插件入门体验，包括"学习"部分和插件展示

更完整的 NetworkPolicy UI 和网络相关的改进

提供夜间构建版本用于早期测试

感谢 Jaehan Byun 和 Jan Jansen。

插件和可扩展性

现在发现插件更简单了——不再需要在 Artifact Hub 和各种 GitHub 仓库之间跳转。浏览我们专门的插件页面，查看 Headlamp 认可的插件精选目录以及特色插件展示。

View of the Plugins showcase

Headlamp AI 助手

管理 Kubernetes 通常意味着记忆命令和处理各种工具。Headlamp 的新 AI 助手通过添加内置在 UI 中的自然语言界面改变了这一点。现在，你可以问"我的应用是否健康？"或"显示此部署的日志"，而不是输入 kubectl 或深入研究 YAML，并在上下文中获得答案，加快故障排除速度并简化新用户的入门。在此了解更多信息。

新增插件

除了新的 AI 助手，我们一直在发展 Headlamp 的插件生态系统，以便你可以将更多工作流集成到单个 UI 中，包括 Minikube、Karpenter 等集成。

最新插件发布的亮点：

Minikube 插件，提供本地存储的单节点 Minikube 集群

Karpenter 插件，支持 Azure 节点自动预配（NAP）

KEDA 插件，你可以在此了解更多信息

社区维护的 Gatekeeper 和 KAITO 插件

感谢来自 Oracle 的 Vrushali Shah 和 Murali Annamneni，以及 Anirban Singha、Adwait Godbole、 Sertaç Özercan、Ernest Wong 和 Chloe Lim。

其他插件更新

除了新增内容，我们还花时间改进了你们许多人已经在使用的插件，专注于更流畅的工作流和与核心 UI 的更好集成。

View of the Backstage plugin

变更：

Flux 插件：更新以支持 Flux v2.7，支持更新的 CRD，导航修复使其在最近的集群上平稳运行

应用目录：现在除了 Artifact Hub 之外还支持 Helm 仓库，可以通过 /serviceproxy 在集群内运行，并显示当前和最新的应用版本

插件目录：改进了卡片布局和可访问性，以及依赖项和 Storybook 测试更新

Backstage 插件：依赖项和构建更新，在此了解更多信息

插件开发

我们专注于使构建、测试和发布 Headlamp 插件更快、更清晰，并辅以改进的文档和更轻量的工具。

View of the Plugin Development guide

变更：

新增和扩展的插件架构和开发指南，包括如何发布和交付插件

添加了 i18n 支持文档，以便插件可以被翻译和本地化

添加了示例插件：ui-panels、 resource-charts、 custom-theme 和projects

改进了 Headlamp API 的类型检查，恢复了用于组件测试的 Storybook 支持，并减少了依赖项以加快安装速度并减少更新

记录了插件安装位置、插件设置中的 UI 标识符，以及区分已交付、UI 安装和开发模式插件的标签

安全升级

我们还在投资保持 Headlamp 的安全性——既通过加强身份认证的工作方式，也密切关注上游漏洞和工具的更新。

更新：

我们一直在跟进安全更新，定期更新依赖项并解决上游安全问题。

我们加强了 Helm chart 的默认安全上下文，并修复了破坏插件管理器的回归问题。

我们通过 PKCE 支持改进了 OIDC 安全性，帮助在集群中部署 Headlamp 时解除更安全和符合标准的 OIDC 设置的阻碍。

结论

感谢今年为 Headlamp 做出贡献的每个人——无论是通过合并请求、插件，还是简单地分享你如何使用该项目。看到团队采用和扩展该项目的不同方式是我们继续前进的重要动力。如果你的组织使用 Headlamp，请考虑将其添加到我们的采用者列表中。

如果你最近还没有尝试过 Headlamp，所有这些更新今天都可以使用。查看最新的 Headlamp 版本，探索新的视图、插件和文档，并在 Slack 或 GitHub 上与我们分享你的反馈——你的反馈有助于塑造 Headlamp 的未来发展方向。

宣布成立 Checkpoint/Restore 工作组

Wed, 21 Jan 2026 10:00:00 -0800

Kubernetes 社区包含多个特别兴趣小组（SIG）和工作组（WG），旨在促进感兴趣的贡献者之间就重要议题展开讨论。今天，我们宣布成立新的 Kubernetes Checkpoint Restore WG，专注于将 Checkpoint/Restore 功能集成到 Kubernetes 中。

动机和应用场景

工作组讨论了以下几个高层次的应用场景：

优化交互式工作负载（例如 Jupyter Notebook 和 AI 聊天机器人）的资源利用率
加速初始化时间较长的应用程序启动，包括 Java 应用程序和 LLM 推理服务
使用周期性 Checkpoint 机制，为长时间运行的工作负载（例如分布式模型训练）提供容错能力
提供具有透明 Checkpoint/Restore 功能的中断感知调度，允许抢占低优先级 Pod，同时保持应用程序的运行时状态
促进 Pod 跨节点迁移，以实现负载均衡和维护，而不会中断工作负载
启用 Checkpoint 取证功能，用于调查和分析安全事件，例如网络攻击、数据泄露和未经授权的访问。

在这些场景中，目标是促进 Kubernetes 社区与日益壮大的用户空间 Checkpoint/Restore（CRIU）生态系统之间的思想交流。CRIU 社区包含多个支持这些用例的项目，其中包括：

CRIU - 用于对运行中的应用程序和容器进行 Checkpoint 维护和 Restore 的工具
checkpointctl - 用于深入分析容器 Checkpoint 的工具
criu-coordinator - 用于与 CRIU 协同执行分布式应用程序 Checkpoint/Restore 的工具
checkpoint-restore-operator - 用于管理 Checkpoint 的 Kubernetes Operator

有关 Kubernetes 的 Checkpoint/Restore 集成的更多信息，请参阅此处。

联系我们

如果你有兴趣为 Kubernetes 或 CRIU 做贡献，可以通过以下几种方式参与：

请于每隔一周的周四 17:00 UTC 通过会议记录中的 Zoom 链接加入我们的会议；之前的会议录像可在此处观看。
在 Kubernetes Slack 上与我们交流：#wg-checkpoint-restore
发送邮件至 wg-checkpoint-restore 邮件列表

使用 clientcmd 实现统一的 API 服务器访问

Mon, 19 Jan 2026 10:00:00 -0800

如果你曾经想为 Kubernetes API 开发命令行客户端，特别是如果你考虑过让你的客户端可用作 kubectl 插件，你可能想知道如何让你的客户端让 kubectl 用户感到熟悉。快速浏览一下 kubectl options 的输出可能会让你感到沮丧： "我真的需要实现所有这些选项吗？"

别担心，其他人已经为你做了很多相关工作。实际上，Kubernetes 项目提供了两个库来帮助你在 Go 程序中处理 kubectl 风格的命令行参数： clientcmd 和 cli-runtime（后者使用 clientcmd）。本文将展示如何使用前者。

总体理念

作为 client-go 的一部分，clientcmd 的最终目的是提供 restclient.Config 的一个实例，该实例可以向 API 服务器发出请求。

它遵循 kubectl 语义：

默认值取自 ~/.kube 或等效位置；
可以使用 KUBECONFIG 环境变量指定文件；
所有上述设置都可以通过命令行参数进一步覆盖。

它不会设置 --kubeconfig 命令行参数，你可能希望这样做以与 kubectl 保持一致；你将在"绑定标志"一节中看到如何做到这一点。

可用特性

clientcmd 允许程序处理。

kubeconfig 选择（使用 KUBECONFIG）；
上下文选择；
命名空间选择；
客户端证书和私钥；
用户模拟；
HTTP 基本认证支持（用户名/密码）。

配置合并

在各种场景中，clientcmd 支持合并配置设置： KUBECONFIG 可以指定多个文件，其内容会被组合。这可能令人困惑，因为设置根据实现方式的不同而以不同方向合并。如果设置在 Map 中定义，第一个定义获胜，后续定义将被忽略。如果设置不在 Map 中定义，最后一个定义获胜。

当使用 KUBECONFIG 检索设置时，缺失的文件只会导致警告。如果用户显式指定路径（以 --kubeconfig 方式），则必须有相应的文件。

如果未定义 KUBECONFIG，则使用默认配置文件 ~/.kube/config（如果存在）。

整体流程

一般使用模式在 clientcmd 包文档中有简洁的表达：

loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()
// if you want to change the loading rules (which files in which order), you can do so here

configOverrides := &clientcmd.ConfigOverrides{}
// if you want to change override values or bind them to flags, there are methods to help you

kubeConfig := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides)
config, err := kubeConfig.ClientConfig()
if err != nil {
	// Do something
}
client, err := metav1.New(config)
// ...

在本文的上下文中，有六个步骤：

配置加载规则

clientcmd.NewDefaultClientConfigLoadingRules() 构建加载规则，该规则将使用 KUBECONFIG 环境变量的内容或默认配置文件名（~/.kube/config）。此外，如果使用默认配置文件，它能够从（非常）旧的默认配置文件（~/.kube/.kubeconfig）迁移设置。

你可以构建自己的 ClientConfigLoadingRules，但在大多数情况下默认值就足够了。

配置覆盖

clientcmd.ConfigOverrides 是一个 struct，存储将应用于从加载规则派生的配置中加载的设置的覆盖。在本文的上下文中，其主要目的是存储从命令行参数获取的值。这些使用 pflag 库处理，该库是 Go 的 flag 包的直接替代品，添加了对带长名称的双连字符参数的支持。

在大多数情况下，覆盖中没有什么需要设置的；我只会将它们绑定到标志上。

构建一组标志

在此上下文中，标志是命令行参数的表示，指定其长名称（如 --namespace）、短名称（如 -n）、默认值以及使用信息中显示的描述。标志存储在 FlagInfo 结构体的实例中。

有三组标志可用，表示以下命令行参数：

认证参数（证书、令牌、模拟、用户名/密码）；
集群参数（API 服务器、证书机构、TLS 配置、代理、压缩）
上下文参数（集群名称、kubeconfig 用户名、命名空间）

推荐的选择包括所有三组，以及命名的上下文选择参数和超时参数。

这些都可以使用 Recommended…Flags 函数获得。这些函数接受一个前缀，该前缀会添加到所有参数长名称之前。

因此调用 clientcmd.RecommendedConfigOverrideFlags("") 会产生诸如 --context、--namespace 等命令行参数。 --timeout 参数的默认值为 0，--namespace 参数有一个对应的短变体 -n。

添加前缀（如 "from-"）会产生诸如 --from-context、--from-namespace 等命令行参数。这在涉及单个 API 服务器的命令上可能看起来不是特别有用，但在涉及多个 API 服务器时（例如在多集群场景中）会派上用场。

这里有一个潜在的陷阱：前缀不会修改短名称，因此如果使用多个前缀，--namespace 需要小心：只有一个前缀可以与 -n 短名称关联。你必须清除与其他前缀的 --namespace 关联的短名称，或者如果没有合理的 -n 关联，则清除所有前缀的短名称。可以按以下方式清除短名称：

kflags := clientcmd.RecommendedConfigOverrideFlags(prefix)
kflags.ContextOverrideFlags.Namespace.ShortName = ""

类似地，可以通过清除长名称来完全禁用标志：

kflags.ContextOverrideFlags.Namespace.LongName = ""

绑定标志

一旦定义了一组标志，就可以使用 clientcmd.BindOverrideFlags 将命令行参数绑定到覆盖标志。这需要一个 pflag FlagSet，而不是 Go 的 flag 包中的 FlagSet。

如果你还想绑定 --kubeconfig，现在就应该这样做，通过绑定加载规则中的 ExplicitPath：

flags.StringVarP(&loadingRules.ExplicitPath, "kubeconfig", "", "", "absolute path(s) to the kubeconfig file(s)")

构建合并配置

有两个函数可用于构建合并配置：

顾名思义，两者之间的区别在于第一个可以使用提供的阅读器交互式地请求认证信息，而第二个仅根据调用者提供的信息进行操作。

这些函数名称中的"延迟（deferred）"指的是最终配置将尽可能晚地确定。这意味着这些函数可以在解析命令行参数之前调用，生成的配置将使用实际构建时已解析的任何值。

获取 API 客户端

合并配置作为 ClientConfig 实例返回。可以通过调用 ClientConfig() 方法从中获取 API 客户端。

如果没有提供配置（KUBECONFIG 为空或指向不存在的文件、~/.kube/config 不存在、并且没有通过命令行参数提供配置），默认设置将返回一个引用 KUBERNETES_MASTER 的模糊错误。这是遗留行为；已经多次尝试摆脱它，但为了 --kubectl 中的 --local 和 --dry-run 命令行参数而保留。你应该通过调用 clientcmd.IsEmptyConfig() 检空配置错误，并提供更明确的错误消息。

Namespace() 方法也很有用：它返回应该使用的名字空间。它还指示名字空间是否被用户覆盖（使用 --namespace）。

完整示例

这是一个完整的示例。

package main

import (
	"context"
	"fmt"
	"os"

	"github.com/spf13/pflag"
	v1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/clientcmd"
)

func main() {
	// Loading rules, no configuration
	loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()

	// Overrides and flag (command line argument) setup
	configOverrides := &clientcmd.ConfigOverrides{}
	flags := pflag.NewFlagSet("clientcmddemo", pflag.ExitOnError)
	clientcmd.BindOverrideFlags(configOverrides, flags,
		clientcmd.RecommendedConfigOverrideFlags(""))
	flags.StringVarP(&loadingRules.ExplicitPath, "kubeconfig", "", "", "absolute path(s) to the kubeconfig file(s)")
	flags.Parse(os.Args)

	// Client construction
	kubeConfig := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides)
	config, err := kubeConfig.ClientConfig()
	if err != nil {
		if clientcmd.IsEmptyConfig(err) {
			panic("Please provide a configuration pointing to the Kubernetes API server")
		}
		panic(err)
	}
	client, err := kubernetes.NewForConfig(config)
	if err != nil {
		panic(err)
	}

	// How to find out what namespace to use
	namespace, overridden, err := kubeConfig.Namespace()
	if err != nil {
		panic(err)
	}
	fmt.Printf("Chosen namespace: %s; overridden: %t\n", namespace, overridden)

	// Let's use the client
	nodeList, err := client.CoreV1().Nodes().List(context.TODO(), v1.ListOptions{})
	if err != nil {
		panic(err)
	}
	for _, node := range nodeList.Items {
		fmt.Println(node.Name)
	}
}

祝你编码愉快，感谢你有兴趣实现具有熟悉使用模式的工具！

Kubernetes v1.35：通过 exec 插件 allowList 限制 kubeconfig 调用的可执行文件，该插件已添加到 kuberc

Fri, 09 Jan 2026 10:30:00 -0800

你知道吗？kubectl 可以在你不知情的情况下，以调用用户的完整权限运行任意可执行文件（包括 shell 脚本）。每当你下载或自动生成 kubeconfig 时，users[n].exec.command 字段可以指定一个可执行文件代表你获取凭证。别误会，这是一个很棒的特性，允许你使用外部身份提供者向集群进行身份验证。然而，你可能已经看到了问题：你确切知道你的 kubeconfig 在系统上运行的是什么可执行文件吗？你信任生成你 kubeconfig 的流水线吗？如果生成 kubeconfig 的代码遭受了供应链攻击，或者生成流水线被入侵，攻击者很可能通过诱骗你的 kubeconfig 运行任意代码来对你的机器做些不好的事情。

为了让用户更好地控制在其系统上运行的内容，SIG-Auth 和 SIG-CLI 在 Kubernetes 1.35 中将凭证插件策略和允许列表作为 Beta 特性添加。所有使用 client-go 库的客户端都可以通过在 REST 配置上填写 ExecProvider.PluginPolicy 结构体来使用此特性。为了扩大此更改的影响，Kubernetes v1.35 还允许你无需编写任何应用代码即可管理此特性。你可以通过在 kuberc 配置文件中添加两个字段来配置 kubectl 强制执行策略和允许列表：credentialPluginPolicy 和 credentialPluginAllowlist。添加其中一个或两个字段会限制 kubectl 允许执行的凭证插件。

工作原理

此特性的完整描述可在我们的官方文档中找到，但这篇博客文章将简要概述新的安全控制选项。这些新特性处于 Beta 阶段，无需使用任何特性门控即可使用。

以下示例是最简单的情况：不指定新字段。

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference

这将保持 kubectl 的行为与以往相同，允许所有插件。

下一个示例在特性上是相同的，但更明确，因此如果这确实是你想要的，建议使用：

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: AllowAll

如果你不知道是否正在使用 exec 凭证插件，请尝试将策略设置为 DenyAll：

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: DenyAll

如果你确实正在使用凭证插件，你会很快发现 kubectl 尝试执行的内容。你会收到如下错误。

Unable to connect to the server: getting credentials: plugin "cloudco-login" not allowed: policy set to "DenyAll"

如果信息不足以调试问题，请在运行下一个命令时增加日志详细级别。例如：

# increase or decrease verbosity if the issue is still unclear
kubectl get pods --verbosity 5

选择性允许插件

如果你需要 cloudco-login 插件来完成日常工作怎么办？这就是为什么策略有第三个选项 Allowlist。要允许特定插件，请设置策略并添加 credentialPluginAllowlist：

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: /usr/local/bin/cloudco-login
  - name: get-identity

你会注意到允许列表中有两个条目。其中一个通过完整路径指定，另一个 get-identity 只是一个基本名称。当你只指定基本名称时，将使用 exec.LookPath 查找完整路径，它不展开通配符或处理通配符。目前不支持通配符。两种形式（基本名称和完整路径）都可以接受，但完整路径更好，因为它进一步缩小了允许的二进制文件的范围。

未来增强

目前，允许列表条目只有一个字段 name。将来，我们（Kubernetes SIG CLI）希望添加其他要求。一个有用的想法是校验和验证，例如，只有当二进制文件具有 sha256 校验和 b9a3fad00d848ff31960c44ebb5f8b92032dc085020f857c98e32a5d5900ff9c 并且存在于路径 /usr/bin/cloudco-login 时，才允许运行。

另一种可能性是只允许由一组可信签名密钥之一签名的二进制文件。

参与其中

凭证插件策略仍在开发中，我们非常感兴趣你的反馈。我们很想听听你喜欢它的哪些方面以及你希望它解决哪些问题。或者，如果你有时间贡献上述增强特性之一，它们将是开始为 Kubernetes 做出贡献的好方法。欢迎在 Slack 上加入讨论：

#sig-cli，
#sig-auth。

Kubernetes v1.35：向 CSI 驱动程序传递服务账号令牌的最佳方式

Wed, 07 Jan 2026 10:30:00 -0800

如果你维护使用服务账号令牌的 CSI 驱动程序， Kubernetes v1.35 带来了一项你希望了解的改进。自从引入 TokenRequests 特性以来， CSI 驱动程序请求的服务账号令牌一直通过 volume_context 字段传递给他们。虽然这可以工作，但它不是存储敏感信息的理想位置，我们已经看到过在 CSI 驱动程序中意外记录令牌的情况。

Kubernetes v1.35 引入了一个 Beta 解决方案来解决这个问题： 通过 Secret 字段实现服务账号令牌的 CSI 驱动程序选择加入。这允许 CSI 驱动程序通过 NodePublishVolumeRequest 中的 secrets 字段接收服务账号令牌，这是 CSI 规范中存储敏感数据的适当位置。

理解现有方法

当 CSI 驱动程序使用 TokenRequests 特性时，它们可以通过在 CSIDriver spec 中配置 TokenRequests 字段来请求工作负载身份的服务账号令牌。这些令牌作为卷属性映射的一部分传递给驱动程序，使用密钥 csi.storage.k8s.io/serviceAccount.tokens。

volume_context 字段可以工作，但它不是为敏感数据设计的。正因为如此，存在一些挑战：

首先，CSI 驱动程序使用的 protosanitizer 工具不会将卷上下文视为敏感数据，因此服务账号令牌可能会在记录 gRPC 请求时出现在日志中。这在 Secret Store CSI 驱动程序的 CVE-2023-2878 和 Azure File CSI 驱动程序的 CCVE-2024-3744 中都发生过。

其次，每个想避免此问题的 CSI 驱动程序都需要实现自己的清理逻辑，这导致了驱动程序之间的不一致。

CSI 规范在 NodePublishVolumeRequest 中已经有一个 secrets 字段，这正是为这类敏感信息设计的。挑战在于，我们不能仅仅改变令牌放置的位置，而不破坏期望在卷上下文中获取令牌的现有 CSI 驱动程序。

选择加入机制如何工作

Kubernetes v1.35 引入了一个选择加入机制，让 CSI 驱动程序选择如何接收服务账号令牌。这样，现有的驱动程序继续按当前方式工作，而驱动程序可以在准备好时迁移到更合适的 Secret 字段。

CSI 驱动程序可以在其 CSIDriver spec 中设置一个新字段：

#
# 注意：这只是一个配置示例。
#      请勿将此配置用于你自己的集群！
#
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example-csi-driver
spec:
  # ... 现有字段...
  tokenRequests:
  - audience: "example.com"
    expirationSeconds: 3600
  # 新增 Secret 传递选项
  serviceAccountTokenInSecrets: true  # 默认为 false

行为取决于 serviceAccountTokenInSecrets 字段：

当设置为 false（默认）时，令牌会被放置在 VolumeContext 中，密钥为 csi.storage.k8s.io/serviceAccount.tokens，与今天相同。当设置为 true 时，令牌仅被放置在 Secrets 字段中，使用相同的密钥。

关于 Beta 发布

CSIServiceAccountTokenSecrets 特性门控在 kubelet 和 kube-apiserver 上默认启用。由于 serviceAccountTokenInSecrets 字段默认为 false，启用特性门控不会改变任何现有行为。所有驱动程序继续通过卷上下文接收令牌，除非它们明确选择加入。这就是为什么我们觉得从 Beta 开始而不是 Alpha 会更安心。

CSI 驱动程序作者指南

如果你维护使用服务账号令牌的 CSI 驱动程序，以下是采用此特性的方法。

添加回退逻辑

首先，更新驱动程序代码以检查两个位置的令牌。这使你的驱动程序与新旧方法都兼容：

const serviceAccountTokenKey = "csi.storage.k8s.io/serviceAccount.tokens"

func getServiceAccountTokens(req *csi.NodePublishVolumeRequest) (string, error) {
    // Check secrets field first (new behavior when driver opts in)
    if tokens, ok := req.Secrets[serviceAccountTokenKey]; ok {
        return tokens, nil
    }

    // Fall back to volume context (existing behavior)
    if tokens, ok := req.VolumeContext[serviceAccountTokenKey]; ok {
        return tokens, nil
    }

    return "", fmt.Errorf("service account tokens not found")
}

此回退逻辑向后兼容，可以安全地包含在任何驱动程序版本中，即使在集群升级到 v1.35 之前也是如此。

推出顺序

CSI 驱动程序作者在采用此特性时需要遵循特定顺序，以避免破坏现有卷。

驱动程序准备（可以随时进行）

你可以立即通过添加检查 Secret 字段和卷上下文中令牌的回退逻辑来准备驱动程序。此代码更改向后兼容，可以安全地包含在任何驱动程序版本中，即使在集群升级到 v1.35 之前也是如此。我们鼓励你尽早添加此回退逻辑、发布版本，并在可行的情况下甚至 backport 到维护分支。

集群升级和特性启用

一旦你的驱动程序部署了回退逻辑，以下是在集群中启用该特性的安全推出顺序：

完成 kube-apiserver 升级到 1.35 或更高版本
完成所有节点上 kubelet 升级到 1.35 或更高版本
确保部署了具有回退逻辑的 CSI 驱动程序版本（如果尚未在准备阶段完成）
在所有节点上完全完成 CSI 驱动程序 DaemonSet 推出
更新你的 CSIDriver 清单以设置 serviceAccountTokenInSecrets: true

重要约束

最重要需要记住的是时机。如果你的 CSI 驱动程序 DaemonSet 和 CSIDriver 对象在同一个清单或 Helm Chart 中，你需要两次单独的更新。首先部署带有回退逻辑的新驱动程序版本，等待 DaemonSet 推出完成，然后更新 CSIDriver 以设置 serviceAccountTokenInSecrets: true。

此外，在所有驱动程序 Pod 推出完成之前不要更新 CSIDriver。如果你这样做了，在仍在运行旧驱动程序版本的节点上，卷挂载将失败，因为那些 Pod 只检查卷上下文。

为什么这很重要

采用此特性有助于以下几方面：

消除了在 gRPC 请求中作为卷上下文的一部分意外记录服务账号令牌的风险
使用 CSI 规范指定用于敏感数据的字段，这是正确的
protosanitizer 工具自动正确处理 Secret 字段，因此你不需要特定于驱动程序的变通方法
这是选择加入的，因此你可以按自己的节奏迁移，而不会破坏现有部署

号召行动

我们（Kubernetes SIG Storage）鼓励 CSI 驱动程序作者采用此特性并提供关于迁移体验的反馈。如果你对 API 设计有想法或在采用过程中遇到任何问题，请在 Kubernetes Slack 的 #csi 频道联系我们（获取邀请，请访问 https://slack.k8s.io/）。

你可以在 KEP-5538 上跟踪后续 Kubernetes 版本的进度。

Kubernetes v1.35: 通过就地重启 Pod 实现更高的效率

Mon, 05 Jan 2026 10:30:00 -0800

Kubernetes 1.35 版本引入了一项强大的新特性，满足了用户对 Pod 就地重启的迫切需求。这项名为“重启所有容器”（Restart All Containers，1.35 版本为 Alpha 版）的特性，相比于资源用量较高的删除并重建整个 Pod 的方式，能够更高效地重置 Pod 的状态。该特性对于 AI/ML 工作负载尤为实用，使应用程序开发人员能够专注于核心训练逻辑，同时将复杂的故障处理和恢复机制交给边车容器和声明式 Kubernetes 配置来处理。凭借 RestartAllContainers 和其他计划中的增强特性， Kubernetes 将继续构建更灵活、更健壮、更高效的 AI/ML 工作负载平台。

启用 RestartAllContainersOnContainerExits 特性门控即可使用此新特性。此 Alpha 特性扩展了容器重启规则特性，该特性在 Kubernetes 1.35 中升级为 Beta 版。

问题：当单个容器重启不足以解决问题，而重新创建 Pod 成本过高时

Kubernetes 长期以来一直支持 Pod 级别的重启策略（restartPolicy），最近也支持单个容器级别的重启策略。这些策略非常适合处理单个独立进程中的崩溃。然而，许多现代应用程序具有更复杂的容器间依赖关系。例如：

初始化容器通过挂载卷或生成配置文件来准备环境。如果主应用程序容器损坏了此环境，仅仅重启该容器是不够的，需要重新运行整个初始化过程。
监视边车监控系统健康状况。如果它检测到不可恢复但可重试的错误状态，则必须触发主应用程序容器从头开始重启。
管理远程资源的边车发生故障。即使边车自行重启，主容器也可能因为尝试访问过时或损坏的连接而卡住。

在所有这些情况下，我们期望的操作并非重启单个容器，而是重启所有容器。此前，实现此目的的唯一方法是删除 Pod，然后由控制器（例如 Job 或 ReplicaSet）创建一个新的 Pod。这个过程缓慢且成本高昂，涉及调度器、节点资源分配以及网络和存储的重新初始化。

在处理大规模 AI/ML 工作负载（≥ 1000 个节点，每个节点一个 Pod）时，这种低效性会更加严重。这些同步工作负载的一个常见要求是，当发生故障（例如节点崩溃）时，必须重新创建集群中的所有 Pod 以重置状态，然后才能恢复训练，即使其他 Pod 并未直接受到故障的影响。同时删除、创建和调度数千个 Pod 会造成巨大的瓶颈。此次故障造成的损失估计每月可能高达 10 万美元（资源浪费）。

处理 AI/ML 训练任务的这些故障需要复杂的集成，涉及训练框架和 Kubernetes，而这两者通常都很脆弱且繁琐。此特性引入了一种 Kubernetes 原生解决方案，提高了系统健壮性，并使应用程序开发人员能够专注于其核心训练逻辑。

就地重启 Pod 的另一个主要优势在于，将 Pod 保留在其分配的节点上可以进行进一步的优化。例如，可以实现与特定 Pod 标识绑定的节点级缓存，而当 Pod 不必要地在不同的节点上重新创建时，这种优化方式是无法实现的。

引入 `RestartAllContainers` 操作

为了解决这个问题，Kubernetes v1.35 在容器重启规则中添加了一个新的操作：RestartAllContainers。当容器以符合此操作规则的方式退出时，kubelet 会启动对 Pod 的快速就地重启。

这种就地重启非常高效，因为它保留了 Pod 最重要的资源：

Pod 的 UID、IP 地址和网络命名空间。
Pod 的沙箱及其所有连接的设备。
所有卷，包括 emptyDir 和从 PVC 挂载的卷。

终止所有正在运行的容器后，Pod 的启动序列将从头开始重新执行。这意味着所有初始化容器将按顺序再次运行，随后是边车容器和常规容器，从而确保在已知良好的环境中完全重新启动。除了临时容器（会被终止）之外，所有其他容器——包括之前成功或失败的容器——都将重新启动，而不管它们各自的重启策略如何。

应用案例

1. 高效重启机器学习/批处理作业

对于机器学习训练作业，在工作节点 Pod 发生故障时重新调度是一项代价高昂的操作，会浪费宝贵的计算资源。在一个拥有 1000 个节点的训练集群中，重新调度带来的开销每月可能会浪费超过 10 万美元的计算资源。

借助 RestartAllContainers 操作，你可以启用一种速度更快、混合的恢复策略来解决这个问题：仅重新创建“故障”Pod（例如，位于不健康节点上的 Pod），同时对其余健康的 Pod 触发 RestartAllContainers 操作。基准测试表明，这可以将恢复开销从几分钟降低到几秒钟。

通过就地重启，监视器边车可以监控主训练过程。如果遇到特定的可重试错误，监视器可以退出并返回指定的代码，从而触发工作 Pod 的快速重置，使其能够从上一个检查点重新启动，而无需 Job 控制器的参与。Kubernetes 现在原生支持此特性。

有关未来开发和 JobSet 特性的更多详细信息，请参阅 KEP-467 JobSet 就地重启。

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
  # 此初始化容器将在每次就地重启时重新运行。
  - name: setup-environment
    image: my-repo/setup-worker:1.0
  - name: watcher-sidecar
    image: my-repo/watcher:1.0
    restartPolicy: Always
    restartPolicyRules:
    - action: RestartAllContainers
      onExit:
        exitCodes:
          operator: In
          # 监视器返回特定退出代码会触发 Pod 完全重启。
          values: [88]
  containers:
  - name: main-application
    image: my-repo/training-app:1.0

2. 重新运行初始化容器以确保干净状态

设想这样一种场景：初始化容器负责获取凭据或设置共享卷。如果主应用程序发生故障，导致共享状态损坏，则需要重新运行初始化容器。

通过配置主应用程序在检测到此类损坏时以特定代码退出，你可以触发 RestartAllContainers 操作，从而确保初始化容器在应用程序重启之前提供一个干净的设置。

3. 处理高频率的类似任务执行

有些情况下，任务最好以 Pod 执行的形式呈现。每个任务都需要干净利落地执行。例如，游戏会话后端或队列项处理。如果任务频率很高，运行完整的 Pod 创建、调度和初始化流程会非常耗费资源，尤其是在任务执行时间可能很短的情况下。 Kubernetes 原生支持从头开始重启所有容器，无需自定义解决方案或框架即可处理这种情况。

使用方法

要试用此特性，你必须在运行 Kubernetes v1.35 或更高版本的 Kubernetes 集群组件（API 服务器和 kubelet）上启用 RestartAllContainersOnContainerExits 特性门控。此 Alpha 特性扩展了 ContainerRestartRules 特性，后者已在 v1.35 版本中升级为 beta 版，并默认启用。

启用后，你可以将 restartPolicyRules 添加到任何容器（Init、边车或常规容器），并使用 RestartAllContainers 操作。

该特性旨在方便现有应用程序使用。但是，如果应用程序不遵循某些最佳实践，则可能会导致应用程序本身或可观测性工具出现问题。启用此特性时，请确保所有容器都是可重入的，并且外部工具已准备好用于重新启动初始化容器。此外，重启所有容器时，kubelet 不会运行 preStop 钩子。这意味着容器必须设计为能够处理突然终止的情况，而无需依赖 preStop 钩子来实现优雅关闭。

观察重启

为了使重启过程可观察，Pod 的状态中添加了一个新的条件 AllContainersRestarting。当触发重启时，此条件变为 True；当所有容器终止且 Pod 准备好重新开始其生命周期时，此条件变为 False。这为用户和其他集群组件提供了关于 Pod 状态的清晰信号。

所有通过此操作重启的容器，其容器状态中的重启计数都会递增。

了解更多

阅读 Pod 生命周期的官方文档。
阅读 KEP-5532：容器退出时重启所有容器中的详细提案。
阅读 JobSet issue #467 中关于 JobSet 就地重启的提案。

我们期待你的反馈！

作为一项 Alpha 特性，RestartAllContainers 现已开放试用，欢迎你提出任何使用案例和反馈意见。此特性由 SIG Node 社区驱动。如果你有兴趣参与、分享想法或做出贡献，请加入我们！

你可以通过以下方式联系 SIG Node：

Slack：#sig-node
邮件列表

Kubernetes v1.35：扩展容忍度运算符以支持数值比较（Alpha）

Mon, 05 Jan 2026 10:30:00 -0800

许多生产级 Kubernetes 集群会混合使用按需（on-demand，高 SLA）节点与 spot/可抢占（preemptible，低 SLA）节点，以在保证关键工作负载可靠性的同时优化成本。平台团队需要一个“安全默认值”，让大多数工作负载远离风险容量，同时又允许特定工作负载用明确阈值显式选择接受（opt-in），例如“我可以容忍失败概率最高 5% 的节点”。

目前，Kubernetes 的污点与容忍度（taints and tolerations）可以匹配精确值或检查键是否存在，但无法进行数值阈值比较。你不得不创建离散的污点类别、使用外部准入控制器，或接受不够理想的放置决策。

在 Kubernetes v1.35 中，我们以 Alpha 形式引入 扩展容忍度运算符（Extended Toleration Operators）。该增强为 spec.tolerations 增加 Gt（Greater Than）与 Lt（Less Than）运算符，使调度器能够进行基于阈值的调度决策，从而为基于 SLA 的放置、成本优化以及面向性能的工作负载分发打开新可能。

容忍度的演进

从历史上看，Kubernetes 主要支持两种容忍度运算符：

Equal：当 key 与 value 完全相等时，容忍度匹配该污点
Exists：只要 key 存在（无论 value 是什么），容忍度就匹配该污点

这两者对“类别型”场景很好用，但在数值比较方面就显得力不从心。从 v1.35 开始，我们在补齐这一缺口。

请看一些真实世界的场景：

SLA 要求：只把高可用工作负载调度到失败概率低于某个阈值的节点上
成本优化：允许对成本敏感的批处理作业运行在更便宜、且“每小时成本”超过某个特定值的节点上
性能保障：确保对延迟敏感的应用只运行在磁盘 IOPS 或网络带宽高于最低阈值的节点上

在缺少数值比较运算符的情况下，集群运维人员不得不采用一些变通方案，例如创建多个离散的污点值，或使用外部准入控制器。但这些方案既难以规模化，也无法提供“动态阈值调度”所需的灵活性。

为什么要扩展容忍度，而不是用节点亲和性（NodeAffinity）？

你可能会问：NodeAffinity 已经支持数值比较运算符，为什么还要扩展容忍度？ NodeAffinity 虽然很适合表达 Pod 的偏好，但污点与容忍度提供了一些关键的运维收益：

策略导向：NodeAffinity 是按 Pod 配置的，需要每个工作负载显式选择“避开”风险节点。污点则把控制反转：由节点声明风险等级，只有带有匹配容忍度的 Pod 才能落到这些节点上。这提供了更安全的默认值：大多数 Pod 会默认避开 spot/可抢占节点，除非它们显式选择接受。
驱逐语义：NodeAffinity 不具备驱逐能力。污点支持 NoExecute 效果以及 tolerationSeconds，使运维人员可以在节点 SLA 降级或 spot 实例收到终止通知时，排空（drain）并驱逐 Pod。
运维易用性：集中式、节点侧的策略与磁盘压力、内存压力等其他安全污点一致，让集群管理更直观。

该增强在保留污点与容忍度这一成熟安全模型的基础上，为 SLA 感知调度提供了基于阈值的放置能力。

引入 Gt 与 Lt 运算符

Kubernetes v1.35 为容忍度引入两个新运算符：

Gt（Greater Than）：当污点的数值小于容忍度的数值时，容忍度匹配
Lt（Less Than）：当污点的数值大于容忍度的数值时，容忍度匹配

当一个 Pod 使用 Lt 来容忍某个污点时，它表达的是：“我可以容忍该指标小于我的阈值的节点”。由于“容忍度”本质上允许调度，因此该 Pod 也可以运行在污点值大于容忍度值的节点上。你可以把它理解为：“我容忍满足我最低要求之上的节点”。

这些运算符适用于数值型污点值，使调度器能基于连续指标（continuous metrics）而不是离散类别做出更精细的放置决策。

说明：

Gt 与 Lt 运算符的数值必须是正的 64 位整数，且不能有前导零。例如，"100" 是合法的，但 "0100"（带前导零）与 "0"（零值）不被允许。

Gt 与 Lt 运算符适用于所有污点效果（effect）：NoSchedule、NoExecute、PreferNoSchedule。

使用场景与示例

下面我们通过几个例子看看扩展容忍度运算符如何解决真实调度挑战。

示例 1：用 SLA 阈值限制 spot 实例的使用

许多集群会混合按需与 spot/可抢占节点以优化成本。Spot 节点能显著节省费用，但失败率更高。你希望大多数工作负载默认避开 spot 节点，同时允许某些工作负载在清晰的 SLA 边界内显式选择接受。

首先，用“失败概率”给 spot 节点打上污点（例如：年化失败率 15%）：

apiVersion: v1
kind: Node
metadata:
  name: spot-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "15"
    effect: "NoExecute"

按需节点的失败率要低得多：

apiVersion: v1
kind: Node
metadata:
  name: ondemand-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "2"
    effect: "NoExecute"

关键工作负载可以指定严格的 SLA 要求：

apiVersion: v1
kind: Pod
metadata:
  name: payment-processor
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "5"
    effect: "NoExecute"
    tolerationSeconds: 30
  containers:
  - name: app
    image: payment-app:v1

这个 Pod 将只会被调度到 failure-probability 小于 5 的节点上（也就是 2% 的 ondemand-node-1，而不是 15% 的 spot-node-1）。带有 tolerationSeconds: 30 的 NoExecute 效果意味着：如果节点 SLA 降级（例如云厂商改变了污点值），该 Pod 会获得 30 秒的时间用于优雅终止，然后才会被强制驱逐。

与此同时，一个具备容错能力的批处理作业可以显式选择接受 spot 实例：

apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "20"
    effect: "NoExecute"
  containers:
  - name: worker
    image: batch-worker:v1

该批处理作业可容忍失败概率最高 20% 的节点，因此既能运行在按需节点上，也能运行在 spot 节点上，在接受更高风险的同时最大化节省成本。

示例 2：基于 GPU 分层的 AI 工作负载放置

AI 与机器学习工作负载通常对硬件有明确要求。通过扩展容忍度运算符，你可以建立 GPU 节点分层，并确保工作负载落到性能匹配的硬件上。

用“算力评分”给 GPU 节点打上污点：

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-a100
spec:
  taints:
  - key: "gpu-compute-score"
    value: "1000"
    effect: "NoSchedule"
---
apiVersion: v1
kind: Node
metadata:
  name: gpu-node-t4
spec:
  taints:
  - key: "gpu-compute-score"
    value: "500"
    effect: "NoSchedule"

重训练（heavy training）工作负载可以要求更高性能的 GPU：

apiVersion: v1
kind: Pod
metadata:
  name: model-training
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "800"
    effect: "NoSchedule"
  containers:
  - name: trainer
    image: ml-trainer:v1
    resources:
      limits:
        nvidia.com/gpu: 1

这将确保训练 Pod 只会被调度到算力评分大于 800 的节点上（如 A100 节点），避免落到低档 GPU 上而拖慢训练。

而对性能要求没那么高的推理工作负载则可以使用任何可用 GPU：

apiVersion: v1
kind: Pod
metadata:
  name: model-inference
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "400"
    effect: "NoSchedule"
  containers:
  - name: inference
    image: ml-inference:v1
    resources:
      limits:
        nvidia.com/gpu: 1

示例 3：面向成本优化的工作负载放置

对于批处理或非关键工作负载，你可能希望即使牺牲一些性能特征，也通过运行在更便宜的节点上来尽量降低成本。

节点可以用成本评级来打污点：

spec:
  taints:
  - key: "cost-per-hour"
    value: "50"
    effect: "NoSchedule"

对成本敏感的批处理作业可以表达它对昂贵节点的容忍度：

tolerations:
- key: "cost-per-hour"
  operator: "Lt"
  value: "100"
  effect: "NoSchedule"

该批处理作业会被调度到成本低于 100 美元/小时的节点上，并避开更昂贵的节点。结合 Kubernetes 的调度优先级能力，你可以实现更精细的成本分层策略：关键工作负载使用高配节点，而批处理作业高效利用更经济的资源。

示例 4：基于性能的放置

存储密集型应用通常需要最低磁盘性能保障。通过扩展容忍度运算符，你可以在调度层面强制执行这些要求。

tolerations:
- key: "disk-iops"
  operator: "Gt"
  value: "3000"
  effect: "NoSchedule"

该容忍度确保 Pod 只会被调度到 disk-iops 超过 3000 的节点上。 Gt 运算符表达的是：“我需要指标高于这个最低值的节点”。

如何使用该特性

扩展容忍度运算符是 Kubernetes v1.35 中的 Alpha 特性。要试用它：

在 API server 与 scheduler 上启用特性门控：

--feature-gates=TaintTolerationComparisonOperators=true

用数值型污点给节点打标，其值代表你调度所关心的指标：

kubectl taint nodes node-1 failure-probability=5:NoSchedule
kubectl taint nodes node-2 disk-iops=5000:NoSchedule

在 Pod 规约中使用新运算符：

  spec:
    tolerations:
    - key: "failure-probability"
      operator: "Lt"
      value: "1"
      effect: "NoSchedule"

说明：

作为 Alpha 特性，扩展容忍度运算符可能会在未来版本中发生变化，应谨慎用于生产环境。请务必先在非生产集群中充分测试。

下一步计划是什么？

这次 Alpha 发布只是开始。随着我们收集社区反馈，我们计划：

在容忍度与节点亲和性（node affinity）中增加对 CEL（Common Expression Language）表达式的支持，以提供更灵活的调度逻辑（包括语义化版本比较）
改进与集群自动扩缩容（cluster autoscaling）的集成，以支持“阈值感知”的容量规划
将该特性升级为 Beta，并最终达到具备生产级稳定性的 GA

我们尤其希望听到你的使用场景！你是否有一些问题可以通过“基于阈值的调度”来解决？你还希望看到哪些额外运算符或能力？

参与其中

该特性由 SIG Scheduling 社区推动。欢迎加入我们，与社区交流并分享你对该特性及其他相关议题的想法与反馈。

你可以通过以下方式联系该特性的维护者：

Slack：Kubernetes Slack 上的 #sig-scheduling
邮件列表：kubernetes-sig-scheduling@googlegroups.com

如果你对扩展容忍度运算符有疑问或具体咨询，请联系 SIG Scheduling 社区。我们期待你的反馈！

如何了解更多？

阅读基础概念：污点与容忍度（Taints and Tolerations）
了解 Gt / Lt 用法细节：数值比较运算符（Numeric comparison operators）
阅读提案：KEP-5471：用于基于阈值放置的扩展容忍度运算符

Kubernetes 1.35：版本化 z-pages API 带来更强大的调试能力

Wed, 31 Dec 2025 10:30:00 -0800

调试 Kubernetes 控制平面组件可能很具挑战性，尤其是在需要快速理解组件运行时状态或验证配置时。在 Kubernetes 1.35 中，我们为 z-pages 调试端点带来结构化、可被机器解析的响应，让构建工具和自动化排障流程变得更加轻松。

什么是 z-pages？

z-pages 是 Kubernetes 控制平面组件所公开的特殊调试端点。它们在 Kubernetes 1.32 中以 Alpha 特性引入，为 kube-apiserver、kube-controller-manager、 kube-scheduler、kubelet 与 kube-proxy 等组件提供运行时诊断。 "z-pages" 这一名称源自使用 /*z 路径来公开调试端点的惯例。

目前，Kubernetes 支持两个主要的 z-page 端点：

/statusz: 显示组件的高级信息，包括版本、启动时间、运行时长以及可用调试路径
/flagz: 展示用于启动组件的全部命令行参数及其取值（敏感值会出于安全考虑被屏蔽）

这些端点对于需要快速检查组件状态的人工运维人员非常有价值，但在此之前它们只返回难以通过程序解析的纯文本输出。

Kubernetes 1.35 有哪些新内容？

Kubernetes 1.35 为 /statusz 与 /flagz 两个端点都引入了结构化、具备版本控制的响应。这一增强在保留现有纯文本格式向后兼容性的同时，新增了对机器可读 JSON 响应的支持。

向后兼容的设计

新的结构化响应是按需启用的。如果未指定 Accept 头，端点仍会返回熟悉的纯文本格式：

$ curl --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
  --cacert /etc/kubernetes/pki/ca.crt \
  https://localhost:6443/statusz

kube-apiserver statusz
Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only.

Started: Wed Oct 16 21:03:43 UTC 2024
Up: 0 hr 00 min 16 sec
Go version: go1.23.2
Binary version: 1.35.0-alpha.0.1595
Emulation version: 1.35
Paths: /healthz /livez /metrics /readyz /statusz /version

结构化 JSON 响应

若要获得结构化响应，需要提供合适的 Accept 头：

Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Statusz

这样即可返回具备版本号的 JSON 响应：

{
  "kind": "Statusz",
  "apiVersion": "config.k8s.io/v1alpha1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "startTime": "2025-10-29T00:30:01Z",
  "uptimeSeconds": 856,
  "goVersion": "go1.23.2",
  "binaryVersion": "1.35.0",
  "emulationVersion": "1.35",
  "paths": [
    "/healthz",
    "/livez",
    "/metrics",
    "/readyz",
    "/statusz",
    "/version"
  ]
}

类似地，/flagz 也支持结构化响应，只需设置以下头部：

Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Flagz

响应示例如下：

{
  "kind": "Flagz",
  "apiVersion": "config.k8s.io/v1alpha1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "flags": {
    "advertise-address": "192.168.8.4",
    "allow-privileged": "true",
    "authorization-mode": "[Node,RBAC]",
    "enable-priority-and-fairness": "true",
    "profiling": "true"
  }
}

结构化响应为什么很重要

引入结构化响应使得一系列新的用例成为可能：

1. 自动化健康检查与监控

相比解析纯文本，监控工具现在可以轻松提取特定字段。例如，你可以通过程序检查组件是否以异常的模拟版本运行，或确认关键参数是否配置正确。

2. 更好的调试工具

开发者能够构建更加智能的调试工具，用于跨组件比较配置或随时间追踪配置漂移。结构化格式让对配置执行 diff 或验证组件是否按预期设置运行变得轻而易举。

3. API 版本化与稳定性

通过引入带版本的 API（从 v1alpha1 开始），我们为稳定性提供了明确路径。随着特性不断成熟，我们会发布 v1beta1 甚至 v1，让你更有信心确保这些工具在未来的 Kubernetes 版本中依然能够正常工作。

如何使用结构化 z-pages

前提条件

两个端点都需要启用相应的特性门控：

/statusz：启用 ComponentStatusz 特性门控
/flagz：启用 ComponentFlagz 特性门控

示例：获取结构化响应

下面示例展示如何使用 curl 从 kube-apiserver 中获取结构化 JSON 响应：

# 获取结构化状态响应
curl \
  --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
  --cacert /etc/kubernetes/pki/ca.crt \
  -H "Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Statusz" \
  https://localhost:6443/statusz | jq .

# 获取结构化标记响应
curl \
  --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
  --cacert /etc/kubernetes/pki/ca.crt \
  -H "Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Flagz" \
  https://localhost:6443/flagz | jq .

说明：

上述示例使用客户端证书认证，并通过 --cacert 验证服务器证书。如果在测试环境中需要跳过证书验证，可以使用 --insecure（或 -k），但在生产环境切勿这样做，否则会暴露在中间人攻击风险之下。

重要注意事项

Alpha 特性状态

结构化 z-page 响应在 Kubernetes 1.35 中仍是 Alpha 特性，这意味着：

API 格式可能会在未来版本中发生变化
这些端点用于调试，而非生产自动化
在其达到 Beta 或稳定版之前，不应把它们作为关键监控工作流的依赖

安全与访问控制

z-pages 会公开组件内部信息，因此必须设置恰当的访问控制，重点注意以下安全事项：

鉴权：访问 z-page 端点仅限 system:monitoring 组成员，遵循与 /healthz、/livez、/readyz 等调试端点相同的鉴权模型。这样可确保只有获授权的用户和服务账号才能获取调试信息。如果集群使用 RBAC，可以通过赋予该组适当权限来管理访问。

身份认证：这些端点的身份认证要求取决于集群配置。除非集群启用了匿名身份认证，否则通常需要使用身份认证机制（如客户端证书）来访问这些端点。

信息披露：这些端点会泄露集群组件的配置细节，包括：

组件版本与构建信息
所有命令行参数及其取值（敏感值会被屏蔽）
可用的调试端点

务必仅向受信任的运维人员和调试工具授予访问权限，避免对无关用户或不需要该访问级别的自动化系统开放这些端点。

未来演进

随着特性愈发成熟，Kubernetes SIG Instrumentation 计划：

引入 v1beta1 并最终提供 v1 版本的 API
收集社区对响应模式的反馈
根据用户需求，潜在新增更多 z-page 端点

动手试试

我们鼓励你在测试环境体验结构化 z-pages：

在控制平面组件上启用 ComponentStatusz 与 ComponentFlagz 特性门控
使用纯文本与结构化两种格式查询端点
构建一个使用结构化数据的简单工具或脚本
向社区分享你的反馈

了解更多

z-pages 文档
KEP-4827：Component Statusz
KEP-4828：Component Flagz
加入 Kubernetes Slack 中的 #sig-instrumentation 频道参与讨论

参与其中

我们非常期待你的反馈！结构化 z-pages 旨在让 Kubernetes 调试和监控更轻松。无论你是在构建内部工具、为开源项目做贡献，还是只是探索该特性，你的意见都将帮助塑造 Kubernetes 可观测性的未来。

如果你有问题、建议或遇到问题，请联系 SIG Instrumentation。你可以在 Slack 中找到我们，或参加常规的社区会议。

祝你调试愉快！

Kubernetes v1.35：云控制器管理器中的基于监视的路由协调

Tue, 30 Dec 2025 10:30:00 -0800

在 Kubernetes v1.34 及更早版本中，使用 k8s.io/cloud-provider 库构建的云控制器管理器（CCM）实现中的路由控制器会以固定的时间间隔进行路由协调。这会导致在路由没有变化的情况下，向云提供商发出不必要的 API 请求。其他使用同一库实现的控制器已经使用基于监听的机制，利用 informer 来避免不必要的 API 调用。 v1.35 版本引入了一个新的特性门控，允许更改路由控制器的行为，使其使用基于监听的 informer。

新特性

SIG Cloud Provider 已在 k8s.io/cloud-provider 引入了 Alpha 阶段的 CloudControllerManagerWatchBasedRoutesReconciliation 特性门控。要启用此特性，你可以在使用的 CCM 实现中使用 --feature-gate=CloudControllerManagerWatchBasedRoutesReconciliation=true 参数。

关于此特性门控

此特性门控会在节点添加、删除 .spec.podCIDRs 或 .status.addresses 字段更新时触发路由协调循环。

此外，还会以 12 小时到 24 小时之间的随机间隔执行一次额外的协调，该间隔在控制器启动时确定。

此特性门控不会修改协调循环内的逻辑。因此，CCM 实现的用户不应遇到现有路由配置的重大变化。

如何了解更多？

更多详情请参阅 KEP-5237。

Kubernetes v1.35：引入工作负载感知调度

Mon, 29 Dec 2025 10:30:00 -0800

调度大型工作负载比调度单个 Pod 更复杂、也更脆弱，因为它通常需要把所有 Pod 作为整体来考虑，而不是逐个独立调度。例如，在调度一个机器学习批处理任务时，你往往需要有策略地放置每个 worker（例如放在同一个机架上），才能让整体执行效率更高。同时，这类工作负载中的 Pod 在调度视角下往往非常相似，这从根本上改变了调度过程应有的形态。

虽然已经有很多定制调度器可以高效处理工作负载调度，但考虑到工作负载调度对 Kubernetes 用户的普遍性和重要性，尤其是在 AI 时代用例快速增长的背景下，现在正是让工作负载成为 kube-scheduler 一等公民、并提供原生支持的时候。

工作负载感知调度

Kubernetes 1.35 最近发布了首批工作负载感知调度能力改进。这些改进属于一个更广泛的长期计划，目标是提升工作负载的调度与管理能力。该计划将跨越多个 SIG 和多个发布周期，逐步扩展系统能力，向其“北极星目标”推进：在 Kubernetes 中实现无缝的工作负载调度与管理，包括但不限于抢占和自动伸缩。

Kubernetes v1.35 引入了 Workload API，你可以用它描述工作负载的目标形态以及面向调度的要求。它还带来了 编组调度（Gang Scheduling） 的初始实现，可指示 kube-scheduler 以 全有或全无（all-or-nothing） 方式调度编组 Pod。最后，我们通过 机会式批处理（Opportunistic batching） 特性提升了相同 Pod（通常构成一个编组）的调度效率，从而加速整个调度过程。

Workload API

新的 Workload API 资源属于 scheduling.k8s.io/v1alpha1 API 组。该资源以结构化、机器可读的形式定义多 Pod 应用的调度需求。像 Job 这类面向用户的工作负载定义“运行什么”，而 Workload 资源定义“一组 Pod 应如何被调度”，以及它们在整个生命周期内的放置如何被管理。

Workload 允许你定义一组 Pod，并对其应用调度策略。下面是一个编组调度配置示例：你可以定义一个名为 workers 的 podGroup，并应用 gang 策略，minCount 设置为 4。

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  podGroups:
  - name: workers
    policy:
      gang:
        # 仅当 4 个 Pod 能同时运行时，该编组才可调度
        minCount: 4

创建 Pod 时，你可以通过新的 workloadRef 字段把它们关联到这个 Workload：

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  workloadRef:
    name: training-job-workload
    podGroup: workers
  ...

编组调度如何工作

gang 策略会强制执行全有或全无放置。没有编组调度时，一个 Job 可能只被部分调度，占用资源却无法真正运行，从而导致资源浪费甚至潜在死锁。

当你创建属于某个编组调度 Pod 组的 Pod 时，调度器的 GangScheduling 插件会按每个 Pod 组（或副本键）独立管理其生命周期：

当你创建 Pod（或由控制器代你创建）时，调度器会先阻止它们被调度，直到：
- 被引用的 Workload 对象已创建；
- 被引用的 Pod 组在某个 Workload 中存在；
- 该组中待调度 Pod 数量满足你的 minCount。
当到达足够数量的 Pod 后，调度器会尝试放置它们。但这些 Pod 不会立即绑定到节点，而是先在 Permit 门控处等待。
调度器会检查是否已为整个组（至少达到 minCount）找到有效分配。
- 如果组有足够空间，门控打开，所有 Pod 绑定到节点。
- 如果在超时（默认 5 分钟）内仅有子集 Pod 调度成功，调度器会拒绝该组中的所有 Pod。它们会返回队列，释放已保留资源给其他工作负载。

需要说明的是，虽然这只是第一版实现， Kubernetes 项目已经明确计划在后续版本持续改进并扩展编组调度算法。我们希望带来的收益包括：针对整个编组的单周期调度阶段、工作负载级抢占等，并持续向北极星目标推进。

Opportunistic batching

除了显式的编组调度，v1.35 还引入了机会式批处理。这是一个 Beta 特性，可降低相同 Pod 的调度延迟。

与编组调度不同，这个特性不要求启用 Workload API，也不需要用户显式选择加入。它在调度器内部以“机会式”方式工作：识别调度要求相同的 Pod （例如容器镜像、资源请求、亲和性等）。当调度器处理一个 Pod 时，可以复用该 Pod 的可行性计算结果给队列中后续相同 Pod，从而显著加速调度。

只要 Pod 满足相应条件，多数用户无需额外操作就能自动受益于这项优化。

限制条件

机会式批处理仅在特定条件下生效。 kube-scheduler 用于寻找放置位置的相关字段，必须在 Pod 之间保持一致。此外，某些特性的使用会为这些 Pod 禁用批处理机制，以确保正确性。

请注意，你可能需要检查 kube-scheduler 配置，确保它没有在你不知情的情况下为工作负载隐式禁用批处理。

关于限制条件的更多细节，请参考文档。

北极星愿景

该项目有着广泛目标：实现工作负载感知调度。这些新 API 与调度增强只是第一步。在近期，工作将重点攻关：

引入工作负载调度阶段
增强多节点 DRA 与拓扑感知调度支持
工作负载级抢占
增强调度与自动伸缩的集成
增强与外部工作负载调度器的交互
覆盖工作负载全生命周期的放置管理
多工作负载调度模拟

以及更多方向。上述重点的优先级和实现顺序可能会调整，敬请关注后续更新。

快速开始

要体验工作负载感知调度改进：

Workload API：在 kube-apiserver 和 kube-scheduler 上启用 GenericWorkload 特性门控，并确保启用 scheduling.k8s.io/v1alpha1 API 组。
编组调度：在 kube-scheduler 上启用 GangScheduling 特性门控（要求 Workload API 已启用）。
机会式批处理：该 Beta 特性在 v1.35 默认启用。如有需要，可在 kube-scheduler 上通过 OpportunisticBatching 特性门控将其关闭。

我们鼓励你在测试集群中试用工作负载感知调度，并分享使用体验，帮助塑造 Kubernetes 调度的未来。你可以通过以下方式反馈：

在 Slack (#sig-scheduling) 联系我们。
在工作负载感知调度跟踪 issue 下评论。
在 Kubernetes 仓库提交新的 Issue。

了解更多

阅读以下 KEP： Workload API 与编组调度和机会式批处理。
关注工作负载感知调度 issue 获取最新进展。

避免升级到 etcd v3.6 时出现僵尸集群成员

Sun, 21 Dec 2025 00:00:00 +0000

本文是对近期发布在官方 etcd 博客原文的镜像转载。

关键信息：升级到 v3.6 之前，务必先升级到 etcd v3.5.26 或更高版本。这样能自动修复集群，避免僵尸成员问题。

问题概述

最近，etcd 社区解决了一个升级时可能出现的问题：当用户从 v3.5 升级到 v3.6 时，集群可能会出现“僵尸成员”。这些僵尸成员是之前从数据库集群中移除的 etcd 节点，却又重新出现并加入数据库共识。集群会因此无法正常工作，直到这些僵尸成员被再次移除。

在 etcd v3.5 及以前版本，尽管 v3store 已存在，但集群成员数据的权威来源仍是 v2store。作为 v2store 废弃计划的一部分，从 v3.6 开始，集群成员数据的权威来源变为 v3store。通过一次 bug 报告，我们发现部分老集群中 v2store 和 v3store 可能不一致。这种不一致在升级后会表现为旧的、已移除的“僵尸”成员重新出现在集群中。

解决方案和升级路径

etcd v3.5.26 已引入自动同步机制，会将 v2store 中的成员信息同步到 v3store，确保受影响的集群在升级到 3.6.x 之前得到修复。

为了支持大量正在升级到 3.6 的用户，我们建议采用以下安全升级路径：

先将集群升级到 v3.5.26 或更高版本。
等待并确认升级后所有成员状态健康。
再升级到 v3.6。

如果你由于某些限制无法升级到 v3.5.26，我们目前无法提供同等安全的替代路径。因此，如果你的包源或供应商尚未提供 v3.5.26，建议暂缓升级到 v3.6。

额外技术细节

以下信息仅供参考。即使不了解这些技术细节，也可以按前述安全路径完成升级。

该问题主要出现在长期运行 etcd v3.5.25 或更早版本的生产集群中。它是集群增删成员或故障恢复过程中的副作用。这意味着集群越老，出现问题的概率通常越高；但无论集群新旧，都不能完全排除风险。

etcd 维护者与问题报告者在分析症状、代码和日志后，总结了三个可能触发条件：

etcdctl snapshot restore 的 bug（v3.4 及更早版本）：使用 etcdctl snapshot restore 恢复快照时，etcdctl 本应先移除旧成员再添加新成员。v3.4 中由于 bug，旧成员未被移除，从而产生僵尸成员。详见 etcdctl 相关评论。

v3.5 及更早版本中使用 --force-new-cluster：在极少数情况下，强制创建新的单成员集群时未能彻底移除旧成员，导致僵尸成员残留。该问题已在 v3.5.22 修复。更多技术细节可参考 Raft 项目的 PR。

启用 --unsafe-no-sync：启用该参数时，在极少数情况下 etcd 可能已将成员变更写入 v3store，但在写入 WAL 之前崩溃，从而导致 v2store 与 v3store 不一致。这对单成员集群影响更大；多成员集群若从崩溃节点数据强制创建单成员集群，也可能引入僵尸成员。

Note

--unsafe-no-sync 一般不推荐使用，因为它可能破坏共识协议所提供的保证。

需要强调的是，除了以上三种情况外，可能还存在我们尚未发现的其他触发因素，导致 v2store 与 v3store 成员数据不一致。因此，不能因为“没有执行上述三种操作”就认为一定安全。升级到 etcd v3.6 后，v3store 成为成员数据唯一权威来源，这类不一致问题将不再发生。

想要验证 v2store 和 v3store 一致性的高级用户，可以参考这条评论中的步骤。该检测不是修复问题的必要条件，且无论检测结果如何，SIG etcd 都不建议跳过 v3.5.26 这一步升级。

关键要点

升级到 v3.6 之前，务必先升级到 v3.5.26 或更高版本。这样可以自动修复集群并避免僵尸成员问题。

致谢

感谢 Christian Baumann 报告了这一长期存在的升级问题。他的反馈和后续工作帮助我们及时定位并在上游完成修复。

参考资料

升级指南（v3.5 -> v3.6）：https://etcd.io/docs/v3.6/upgrades/upgrade_3_6/
v2store 废弃计划：https://github.com/etcd-io/etcd/issues/12913
Bug 报告：https://github.com/etcd-io/etcd/issues/20967
v3.5.26 自动同步机制：https://github.com/etcd-io/etcd/pull/20995
v3.5.26 版本发布：https://github.com/etcd-io/etcd/releases/tag/v3.5.26
etcdctl 相关评论：[1] https://github.com/etcd-io/etcd/issues/20967#issuecomment-3618010356
Raft 项目 PR：[2] https://github.com/etcd-io/raft/pull/300
一致性检查评论：[3] https://github.com/etcd-io/etcd/issues/20967#issuecomment-3590609775
Christian Baumann：https://github.com/thechristschn

Kubernetes v1.35：Job Managed By 特性正式发布（GA）

Thu, 18 Dec 2025 10:30:00 -0800

在 Kubernetes v1.35 中，通过 .spec.managedBy 指定外部 Job 控制器的能力升级为正式可用（GA）。

该特性允许外部控制器对 Job 的调谐（reconciliation）承担完全责任，从而解锁更强大的调度模式，例如借助 MultiKueue 进行跨多集群派发。

为何要委派 Job 调谐？

该特性的主要动机是支持多集群批处理调度架构，例如 MultiKueue。

MultiKueue 架构区分“管理集群（Management Cluster）”与一组“工作集群（Worker Clusters）”：

管理集群负责派发 Job，但不负责执行。它需要接收 Job 对象以跟踪状态，但会跳过 Pod 的创建与执行。

工作集群接收被派发的 Job，并执行实际的 Pod。

用户通常与管理集群交互。由于状态会自动回传，用户无需访问工作集群也能“实时”观察 Job 的进度。

在工作集群中，被派发的 Job 会作为常规 Job 运行，由内置 Job 控制器管理，且不会设置 .spec.managedBy。

通过使用 .spec.managedBy，管理集群上的 MultiKueue 控制器可以接管某个 Job 的调谐。它会将工作集群中运行的“镜像（mirror）Job”的状态复制回管理集群。

为什么不直接禁用 Job 控制器？理论上可以通过完全禁用内置 Job 控制器来实现，但这通常不可行或不现实，原因主要有两点：

托管控制平面：在许多云环境中，Kubernetes 控制平面是锁定的，用户无法修改控制器管理器的参数。

混合集群角色：用户常常需要一种“混合”模式：管理集群将部分重型工作负载派发到远端集群，但仍在管理集群中执行较小的、或与控制平面相关的 Job。 .spec.managedBy 让这种粒度可以按 Job 逐个控制。

`.spec.managedBy` 的工作机制

.spec.managedBy 字段用于指示由哪个控制器负责该 Job。具体而言，它有两种工作模式：

标准（Standard）：如果未设置，或设置为保留值 kubernetes.io/job-controller，内置 Job 控制器会像往常一样调谐该 Job（标准行为）。

委派（Delegation）：如果设置为任何其他值，内置 Job 控制器将完全跳过对该 Job 的调谐。

为防止出现孤儿 Pod 或资源泄漏，该字段是不可变的（immutable）。你不能将一个正在运行的 Job 从一个控制器转移到另一个控制器。

如果你计划实现一个外部控制器，请注意你的控制器需要符合 Job API 的定义。

为确保这种一致性，这项工作的一个重要部分是引入了一套完善且严格的 Job 状态校验规则。

更多细节请参阅如何进一步了解？一节。

生态采纳情况

.spec.managedBy 字段正在快速成为 Kubernetes 批处理生态中委派控制的标准接口。

多种自定义工作负载控制器正在加入该字段（或等效字段），以便让 MultiKueue 接管它们的调谐并在多集群之间进行编排：

虽然理论上可以用 .spec.managedBy 从零实现一个自定义 Job 控制器，但我们尚未观察到这种用法。该特性更明确地面向委派模式（例如 MultiKueue）而设计，以避免重复造轮子。

如何进一步了解？

如果你想进一步深入了解：

阅读面向用户的文档：

将 Job 对象的管理委派给外部控制器

MultiKueue

深入了解设计历程：

Kubernetes 增强提案（KEP）Job's managed-by mechanism，其中包括引入了更全面的 Job status validation rules。

Kueue 的 KEP：MultiKueue。

也可以通过任务指南了解 MultiKueue 在实践中如何使用 .spec.managedBy：跨集群运行 Job。

致谢

与任何 Kubernetes 特性一样，这项特性也由许多人一起塑造：他们参与设计讨论、评审、试运行与缺陷报告等工作。

我们特别感谢：

Maciej Szulik——提供指导、辅导与评审。

Filip Křepinský——提供指导、辅导与评审。

参与其中

这项工作由 Kubernetes 的 Batch Working Group 发起，并与 SIG Apps 紧密协作，同时也得到了 SIG Scheduling 社区的强力支持与投入。

如果你对批处理调度、多集群解决方案或进一步改进 Job API 感兴趣：

欢迎加入 Batch WG 与 SIG Apps 会议。

订阅 WG Batch Slack 频道。

Kubernetes v1.35：Timbernetes（世界树版本）

Wed, 17 Dec 2025 10:30:00 -0800

编辑：Aakanksha Bhende、Arujjwal Negi、Chad M. Crowell、Graziano Casto、Swathi Rao

与之前版本类似，Kubernetes v1.35 的发布引入了新的稳定（GA）、Beta 和 Alpha 特性。持续交付高质量版本，体现了我们开发周期的韧性，也离不开社区的热情支持。

此版本包含 60 个增强项，其中包括 17 个稳定（GA）特性、19 个 Beta 特性和 22 个 Alpha 特性。

本次发布还包含一些弃用与移除内容，请务必阅读相关说明。

发布主题与徽标

2025 年在 Octarine：The Color of Magic（v1.33）的微光中启程，又乘着 Of Wind & Will（v1.34）的疾风前行。我们在年末将双手搭在世界树上，灵感来自 Yggdrasil——那棵连接诸多世界的生命之树。如同所有伟大的树木，Kubernetes 也在全球社区的悉心呵护下，以年轮为记、以版本为序，不断成长。

在这棵树的中心，是环抱地球的 Kubernetes 方向盘标。它之所以稳固，源于那些始终如一的维护者、贡献者与用户。在本职工作与生活变迁之间，在持续的开源维护之中，他们修剪旧 API、嫁接新特性，让这个全球最大开源项目之一保持健康。

三只松鼠守护着这棵树：为评阅者举起 LGTM 卷轴的法师；为发布团队挥斧开枝、并举起 Kubernetes 盾牌的战士；以及为分诊者照亮幽深 Issue 队列的提灯游侠。

它们共同象征着一支规模更大的冒险队伍。 Kubernetes v1.35 为世界树再添一圈年轮——这一道新切面由无数双手、无数条路径与一个根系更深、枝叶更高的社区共同塑造。

重点更新速览

Kubernetes v1.35 带来了大量新特性与改进。下面是发布团队希望重点介绍的几个更新！

稳定（GA）阶段：Pod 资源原地更新

Kubernetes 已将 Pod 资源的原地更新特性升级为正式发布（GA）。

该特性允许用户在不重启 Pod 或容器的情况下，调整 CPU 与内存资源。此前，这类修改需要重建 Pod，可能会干扰工作负载，尤其是有状态或批处理应用。更早的 Kubernetes 版本仅允许你为现有 Pod 修改基础设施资源设置（requests 与 limits）。新的原地更新能力支持更平滑、不中断的纵向扩缩容，提高效率，也能简化开发流程。

此项工作是 KEP #1287 的一部分，由 SIG Node 牵头完成。

Beta：用于工作负载身份与安全的 Pod 证书

此前，要向 Pod 下发证书，往往需要外部控制器（cert-manager、SPIFFE/SPIRE）、 CRD 编排以及 Secret 管理，并由边车或 Init 容器负责证书轮换。 Kubernetes v1.35 通过自动化证书轮换，实现原生工作负载身份，大幅简化服务网格与零信任架构。

现在，kubelet 会生成密钥，通过 PodCertificateRequest 请求证书，并将凭据包直接写入 Pod 的文件系统。 kube-apiserver 会在准入阶段强制执行节点限制，消除第三方签名者最常见的陷阱：无意间突破节点隔离边界。这使得签发路径中无需持有者令牌即可实现纯双向 TLS 流程。

此项工作是 KEP #4317 的一部分，由 SIG Auth 牵头完成。

Alpha：调度前节点声明式特性

当控制平面启用新特性、但节点侧进度滞后时（Kubernetes 版本偏差策略允许这种情况），调度器可能会将需要这些特性的 Pod 调度到不兼容的旧节点上。

节点声明式特性框架允许节点声明其所支持的 Kubernetes 特性。启用这一 Alpha 特性后，Node 会通过新的 .status.declaredFeatures 字段上报其支持的特性，并将信息发布到控制平面。随后，kube-scheduler、准入控制器以及第三方组件都可以使用这些声明。例如，你可以强制执行调度与 API 校验约束，确保 Pod 只运行在兼容的节点上。

此项工作是 KEP #5328 的一部分，由 SIG Node 牵头完成。

进入稳定（GA）阶段的特性

以下列出 v1.35 发布后进入稳定（GA）阶段的一些改进。

PreferSameNode 流量分配

Service 的 trafficDistribution 字段已更新，以便更明确地控制流量路由。新增选项 PreferSameNode：在可用时严格优先选择本节点上的端点，否则再回退到远端端点。

同时，现有的 PreferClose 选项已重命名为 PreferSameZone。这一变更让 API 更加直观、自解释：它明确表示优先在当前可用区内选择流量路径。虽然为了向后兼容仍保留 PreferClose，但 PreferSameZone 现在是可用区级别路由的标准选项，确保“节点级”与“可用区级”的偏好能够清晰区分。

此项工作是 KEP #3015 的一部分，由 SIG Network 牵头完成。

Job API 的 managed-by 机制

Job API 新增 managedBy 字段，允许外部控制器接管 Job 状态同步。该特性在 Kubernetes v1.35 中进入稳定（GA）阶段，主要由 MultiKueue 推动。 MultiKueue 是一种多集群分发系统，在管理集群创建的 Job 会被镜像到工作集群执行，并将状态更新回传。为实现这一工作流，需要让内置 Job 控制器不要处理某个特定 Job 资源，从而由 Kueue 控制器接管状态更新。

其目标是让 Job 同步能够清晰地委派给另一个控制器。它并不意图向该控制器传递自定义参数，也不打算修改 CronJob 的并发策略。

此项工作是 KEP #4368 的一部分，由 SIG Apps 牵头完成。

使用 `.metadata.generation` 可靠跟踪 Pod 更新

在历史上，Pod API 缺少 metadata.generation 字段（其他对象例如 Deployment 具备该字段）。因此，控制器与用户无法可靠地确认 kubelet 是否已经处理了 Pod 规约的最新变更。这种不确定性在诸如Pod 资源原地纵向扩缩容等特性中尤为突出，因为很难精确判断资源调整请求何时真正生效。

Kubernetes v1.33 以 Alpha 形式为 Pod 增加了 .metadata.generation 字段。在 v1.35 的 Pod API 中，该字段已进入稳定（GA）阶段。每当更新 Pod 的 spec 时，.metadata.generation 的值都会递增。作为这一改进的一部分，Pod API 还新增了 .status.observedGeneration 字段，用于报告 kubelet 已经成功看到并处理的 generation。 Pod 的各类状况（conditions）也各自包含独立的 observedGeneration 字段，客户端可以上报和/或观测这些字段。

由于该特性在 v1.35 进入稳定（GA）阶段，它对所有工作负载可用。

此项工作是 KEP #5067 的一部分，由 SIG Node 牵头完成。

为拓扑管理器提供可配置 NUMA 节点上限

拓扑管理器过去使用硬编码上限 8，作为其可支持的 NUMA 节点最大数量，以避免在亲和性计算期间出现状态爆炸。这里有个重要细节：NUMA 节点（NUMA node）与 Kubernetes API 中的 Node 并不是同一概念。这一 NUMA 节点数量上限，限制了 Kubernetes 对现代高端服务器的充分利用，因为这类服务器越来越常见地采用拥有超过 8 个 NUMA 节点的 CPU 架构。

Kubernetes v1.31 为拓扑管理器策略配置引入了新的 Beta 选项max-allowable-numa-nodes。在 Kubernetes v1.35 中，该选项已进入稳定（GA）阶段。启用该选项的集群管理员可以使用拥有超过 8 个 NUMA 节点的服务器。

尽管这一配置选项已进入稳定（GA）阶段，Kubernetes 社区仍注意到在大型 NUMA 主机上性能欠佳，并提出了旨在改进该问题的增强提案（KEP-5726）。要了解更多信息，请阅读在节点上控制拓扑管理策略。

此项工作是 KEP #4622 的一部分，由 SIG Node 牵头完成。

Beta 中的新特性

以下列出 v1.35 发布后进入 Beta 阶段的一些改进。

通过 Downward API 暴露节点拓扑标签

过去，要在 Pod 内访问节点拓扑信息（例如区域与可用区），通常需要查询 Kubernetes API 服务器。这种做法虽然可行，但为了获取基础设施元数据，往往需要授予较宽泛的 RBAC 权限，或引入边车容器，从而带来复杂度与安全风险。 Kubernetes v1.35 将“通过 Downward API 直接暴露节点拓扑标签”的能力提升为 Beta。

现在，kubelet 可以将标准拓扑标签（例如 topology.kubernetes.io/zone 与 topology.kubernetes.io/region）注入到 Pod 中，以环境变量或投射卷文件（projected volume files）的形式呈现。其主要收益是让工作负载以更安全、更高效的方式具备拓扑感知能力。应用可以在不依赖 API 服务器的情况下原生适配其所在可用区或区域，通过坚持最小特权原则来增强安全性，并简化集群配置。

说明： Kubernetes 现在会为每个 Pod 注入可用的拓扑标签，使其可以作为 Downward API 的输入。升级到 v1.35 后，大多数集群管理员会看到每个 Pod 新增了若干标签；这是设计的一部分，属于预期行为。

此项工作是 KEP #4742 的一部分，由 SIG Node 牵头完成。

存储版本迁移的原生支持

在 Kubernetes v1.35 中，存储版本迁移的原生支持升级为 Beta 并默认启用。这一改动将迁移逻辑直接集成到 Kubernetes 核心控制平面（in-tree）中，从而消除对外部工具的依赖。

在过去，管理员依赖手工的“读/写循环”（read/write loops），常见做法是把 kubectl get 的输出通过管道传给 kubectl replace，用来更新资源的模式（Schema）或重新加密静态数据。这种方式效率低且容易产生冲突，尤其是对 Secret 这类较大的资源更是如此。在本次发布中，内置控制器会自动处理更新冲突与一致性令牌，以更安全、简化且可靠的方式确保存储数据保持最新，并将运维开销降到最低。

此项工作是 KEP #4192 的一部分，由 SIG API Machinery 牵头完成。

可变更的卷挂接上限

CSI（Container Storage Interface）驱动是 Kubernetes 插件，为存储系统向容器化工作负载暴露能力提供一致的方式。 CSINode 对象会记录节点上安装的所有 CSI 驱动的详细信息。不过，节点上报告的挂接容量与实际挂接容量可能出现不一致：当 CSI 驱动启动后卷槽位被消耗时，kube-scheduler 可能把有状态 Pod 调度到挂接容量不足的节点上，最终卡在 ContainerCreating 状态。

Kubernetes v1.35 使 CSINode.spec.drivers[*].allocatable.count 可变更，以便动态更新节点可用的卷挂接容量。它还通过 CSIDriver 对象引入可配置的刷新间隔，允许 CSI 驱动控制在所有节点上更新 allocatable.count 值的频率。此外，当检测到因容量不足导致的卷挂接失败时，它会自动更新 CSINode.spec.drivers[*].allocatable.count。尽管该特性在 v1.34 中已升级为 Beta，但当时特性门控 MutableCSINodeAllocatableCount 默认关闭；在 v1.35 中它仍处于 Beta，以便留出反馈时间，同时该特性门控默认启用。

此项工作是 KEP #4876 的一部分，由 SIG Storage 牵头完成。

机会式批处理

在过去，Kubernetes 调度器按顺序处理 Pod，其时间复杂度为 O(Pod 个数 × 节点个数)，这会导致对“可兼容 Pod”执行重复计算。此 KEP 引入一种机会式批处理机制，旨在通过 Pod scheduling signature 识别这类可兼容 Pod 并将它们批量处理，从而在这些 Pod 之间共享过滤与打分结果以提升性能。

**Pod 调度签名（Pod Scheduling Signature）**机制确保从调度视角看，具有相同签名的两个 Pod 是“相同的”。它不仅会考虑 Pod 与节点属性，还会纳入系统中的其他 Pod 以及有关放置的全局数据。这意味着：具有给定签名的任意 Pod，在任意一组节点上都会得到相同的打分/可行性判断结果。

该批处理机制包含两个可按需调用的操作：create 与 nominate。 create 会基于具有有效签名的 Pod 的调度结果，创建一组新的批处理信息。 nominate 会使用 create 生成的批处理信息，为一个新 Pod（其签名与规范 Pod 的签名一致）设置提名的节点名称。

此项工作是 KEP #5598 的一部分，由 SIG Scheduling 牵头完成。

StatefulSet 的 `maxUnavailable`

StatefulSet 运行一组 Pod，并为其中每个 Pod 维护粘性身份（Sticky Identity）。这对需要稳定网络标识符或持久存储的有状态工作负载至关重要。当 StatefulSet 的 .spec.updateStrategy.<type> 设置为 RollingUpdate 时， StatefulSet 控制器会删除并重建 StatefulSet 中的每个 Pod。它会按 Pod 终止的顺序（从最大序号到最小序号）推进，一次只更新一个 Pod。

Kubernetes v1.24 在 StatefulSet 的 rollingUpdate 配置中新增了一个 Alpha 字段 maxUnavailable，除非你的集群管理员显式选择启用，否则该字段不会出现在 Kubernetes API 中。在 Kubernetes v1.35 中，该字段升级为 Beta 且默认可用。你可以用它定义更新期间最多允许不可用的 Pod 数量。该设置与将 .spec.podManagementPolicy 设为 Parallel 组合使用时最有效。你可以把 maxUnavailable 设置为一个正整数（例如：2），或设置为期望 Pod 数量的百分比（例如：10%）。如果未指定该字段，它默认为 1，以保持此前“一次只更新一个 Pod”的行为。这一改进使有状态应用（可容忍多个 Pod 同时不可用）能够更快完成更新。

此项工作是 KEP #961 的一部分，由 SIG Apps 牵头完成。

`kuberc` 中可配置的凭据插件策略

可选的 kuberc 文件用于将服务器配置与集群凭据和用户偏好相分离，而不会因意外输出而打断已经在运行的 CI 流水线。

作为 v1.35 发布的一部分，kuberc 增加了允许用户配置凭据插件策略的能力。此变更引入两个字段：credentialPluginPolicy（允许或拒绝所有插件），以及 credentialPluginAllowlist（允许指定允许插件的列表）。

此项工作是 KEP #3104 的一部分，由 SIG Auth 与 SIG CLI 协作完成。

KYAML

YAML 是一种便于人类阅读的数据序列化格式。在 Kubernetes 中，YAML 文件用于定义与配置资源，例如 Pod、Service 与 Deployment。不过，复杂 YAML 很难阅读：YAML 对缩进与嵌套要求严格；同时，其可选的字符串引用也可能导致意外的类型强制转换（参见：The Norway Bug）。虽然 JSON 可以作为一种替代方案，但它不支持注释，并对尾随逗号与键的引号有严格要求。

KYAML 是专为 Kubernetes 设计的、更安全且更少歧义的 YAML 子集。它在 v1.34 作为可选的 Alpha 特性引入，并在 Kubernetes v1.35 升级为 Beta 且默认启用。你可以通过设置环境变量 KUBECTL_KYAML=false 来禁用它。

KYAML 旨在解决 YAML 与 JSON 的一些共性挑战。所有 KYAML 文件也都是合法的 YAML 文件，这意味着你可以编写 KYAML 并将其作为输入提供给任意版本的 kubectl。这也意味着，即使输入并非严格 KYAML，也仍然可以被解析。

此项工作是 KEP #5295 的一部分，由 SIG CLI 牵头完成。

可配置的 HorizontalPodAutoscalers 容忍度

水平 Pod 自动扩缩容器（Horizontal Pod Autoscaler，HPA）长期依赖固定的全局 10% 容忍度来执行扩缩容。这一硬编码值的缺点是：对需要高灵敏度的工作负载（例如希望在负载增加 5% 时就扩容）不够友好，这些工作负载常常无法触发扩缩容；而另一些工作负载则可能产生不必要的振荡。

在 Kubernetes v1.35 中，“可配置容忍度”特性升级为 Beta 并默认启用。该增强允许用户在 HPA 的 behavior 字段中，按资源粒度定义自定义容忍窗口。通过设置特定容忍度（例如将其降低到 0.05 来表示 5%），运维人员可以更精确地控制自动扩缩容灵敏度，确保关键工作负载能对小幅指标变化快速响应，而无需进行集群范围的配置调整。

此项工作是 KEP #4951 的一部分，由 SIG Autoscaling 牵头完成。

Pod 中的用户命名空间支持

Kubernetes 增加了对用户命名空间（user namespaces）的支持，使 Pod 可以使用相互隔离的用户/组 ID 映射运行，而不是共享主机上的 ID。这意味着容器在内部可以以 root 身份运行，但在主机上实际映射为一个非特权用户，从而在发生入侵时降低提权风险。该特性提升了 Pod 级别的安全性，使需要在容器内使用 root 的工作负载更安全。随着时间推移，该能力也通过 ID 映射挂载（id-mapped mounts）扩展到无状态与有状态 Pod。

此项工作是 KEP #127 的一部分，由 SIG Node 牵头完成。

VolumeSource：OCI 工件和/或镜像

在创建 Pod 时，你常常需要为容器提供数据、二进制文件或配置文件。这通常意味着要么把内容打进主容器镜像，要么使用自定义 Init 容器下载并解包到 emptyDir 中。这两种方式仍然有效。Kubernetes v1.31 增加了对 image 卷类型的支持，允许 Pod 以声明的方式拉取并将 OCI 容器镜像工件解包到卷中。这使你可以使用标准 OCI 镜像库工具来打包与分发纯数据工件，例如配置、二进制文件或机器学习模型。

借助该特性，你可以将数据与容器镜像彻底分离，并去除额外 Init 容器或启动脚本的需求。 image 卷类型自 v1.33 起处于 Beta，并在 v1.35 中默认启用。请注意，使用该特性需要兼容的容器运行时，例如 containerd v2.1 或更高版本。

此项工作是 KEP #4639 的一部分，由 SIG Node 牵头完成。

对缓存镜像强制执行 `kubelet` 凭据校验

当前，imagePullPolicy: IfNotPresent 允许 Pod 使用节点上已经缓存的容器镜像，即使 Pod 本身并不具备拉取该镜像所需的凭据。这种行为在多租户集群中会带来安全漏洞：如果某个具备有效凭据的 Pod 把敏感的私有镜像拉取到某节点上，同一节点上后续的未授权 Pod 只需依赖本地缓存就能访问该镜像。

此 KEP 引入一种机制：由 kubelet 对缓存镜像强制执行凭据校验。在允许 Pod 使用本地缓存镜像之前，kubelet 会检查 Pod 是否具备拉取该镜像的有效凭据。这确保只有经授权的工作负载才能使用私有镜像，无论该镜像是否已经存在于节点上，从而显著增强共享集群的安全性。

在 Kubernetes v1.35 中，该特性升级为 Beta 并默认启用。用户仍可将 KubeletEnsureSecretPulledImages 特性门控设为 false 来禁用它。此外，imagePullCredentialsVerificationPolicy 参数允许运维人员配置期望的安全级别，从优先保证向后兼容的模式到提供最高安全性的严格强制模式不等。

此项工作是 KEP #2535 的一部分，由 SIG Node 牵头完成。

细粒度的容器重启规则

在过去，restartPolicy 字段只能在 Pod 级别定义，从而强制 Pod 内所有容器采用相同行为。这一全局设置对复杂工作负载（例如 AI/ML 训练作业）缺乏足够的粒度。这类作业往往需要 Pod 使用 restartPolicy: Never 以管理作业完成，但某些容器仍希望能针对可重试的特定错误（如网络抖动或 GPU 初始化失败）执行原地重启。

Kubernetes v1.35 通过在容器 API 本身中启用 restartPolicy 与 restartPolicyRules 来解决这一问题。这允许用户为单个普通容器与 Init 容器定义重启策略，并使其与 Pod 的整体策略相互独立。例如，你可以将容器配置为仅在以特定错误码退出时才自动重启，从而避免因短暂故障而重调度整个 Pod 的昂贵开销。

在本次发布中，该特性升级为 Beta 并默认启用。用户可以立即在容器规约中使用 restartPolicyRules，为长时间运行的工作负载优化恢复时间与资源利用率，而无需改变 Pod 更宏观的生命周期逻辑。

此项工作是 KEP #5307 的一部分，由 SIG Node 牵头完成。

CSI 驱动可选择通过 secrets 字段获取 ServiceAccount 令牌

在向 CSI（Container Storage Interface）驱动提供 ServiceAccount 令牌时，传统上依赖把令牌注入到 volume_context 字段中。这种方式存在显著安全风险：volume_context 主要用于非敏感配置数据，并且常被驱动与调试工具以明文形式记录到日志中，从而可能泄露凭据。

Kubernetes v1.35 引入一套可选择启用的机制，让 CSI 驱动通过 NodePublishVolume 请求中的专用 secrets 字段获取 ServiceAccount 令牌。驱动现在可以在其 CSIDriver 对象中将 serviceAccountTokenInSecrets 设为 true 来启用此行为，从而指示 kubelet 以更安全的方式填充该令牌。

其主要收益是防止凭据在日志与错误信息中被意外暴露。这一变更确保敏感的工作负载身份通过合适的安全通道处理，在保持对既有驱动向后兼容的同时，也更符合密文管理最佳实践。

此项工作是 KEP #5538 的一部分，由 SIG Auth 牵头并与 SIG Storage 协作完成。

Deployment 状态：正在终止的副本计数

在过去，Deployment 状态会提供可用副本与已更新副本的详细信息，但缺少对“正在关闭过程中的 Pod”的明确可见性。这一缺失使用户与控制器难以区分“稳定的 Deployment”与“仍有 Pod 正在执行清理任务或处于较长优雅终止期”的 Deployment。

Kubernetes v1.35 将 Deployment 状态中的 terminatingReplicas 字段提升为 Beta。该字段提供已设置删除时间戳但尚未从系统移除的 Pod 数量。该特性是一个更大计划中的基础一步，旨在改进 Deployment 如何处理 Pod 替换，并为未来制定“在滚动发布期间何时创建新 Pod”的策略奠定基础。

其主要收益是提升生命周期管理工具与运维人员的可观测性。通过公开正在终止的 Pod 数量，可以让外部系统做出更明智的决策，例如在继续后续任务之前等待完全关闭，而无需手工查询并筛选各个 Pod 的列表。

此项工作是 KEP #3973 的一部分，由 SIG Apps 牵头完成。

Alpha 阶段的新特性

以下列出 v1.35 发布后进入 Alpha 阶段的一些改进。

Kubernetes 中的 Gang 调度支持

对相互依赖的工作负载（例如 AI/ML 训练作业或 HPC 仿真）进行调度，传统上一直很有挑战性，因为默认的 Kubernetes 调度器会逐个调度 Pod。这常导致“部分调度”：部分 Pod 已启动，而其他 Pod 由于资源不足无限期等待，从而引发死锁并浪费集群容量。

Kubernetes v1.35 通过新的 Workload API 与 PodGroup 概念，引入对所谓成组调度（Gang Scheduling）的原生支持。该特性实现“全有或全无”的调度策略：只有当集群有足够资源同时容纳整个 Pod 组时，才会对该组进行调度。

其主要收益是提升批处理与并行工作负载的可靠性与效率。通过避免部分部署，它消除了资源死锁，并确保昂贵的集群容量只在能够运行完整作业时才会被使用，从而显著优化大规模数据处理任务的编排。

此项工作是 KEP #4671 的一部分，由 SIG Scheduling 牵头完成。

受限的身份扮演（Impersonation）

在过去，Kubernetes RBAC 中的 impersonate 动词按“全有或全无”运作：一旦用户被授权可以扮演某个目标身份，就会获得该身份所关联的全部权限。这种宽泛授权的缺点是违背最小特权原则，使管理员难以将模拟者的权限限制到特定动作或特定资源上。

Kubernetes v1.35 引入一个新的 Alpha 特性：受限的身份扮演（Constrained Impersonation），它在身份扮演流程中增加一次二次鉴权检查。当 ConstrainedImpersonation 特性门控被启用后， API 服务器不仅会校验基础的 impersonate 权限，还会使用新的动词前缀（例如 impersonate-on:<mode>:<verb>）检查身份扮演者是否被授权执行特定动作。这使管理员可以定义细粒度策略——例如允许支持工程师模拟集群管理员仅用于查看日志，而不授予完整的管理员访问权限。

此项工作是 KEP #5284 的一部分，由 SIG Auth 牵头完成。

Kubernetes 组件的 Flagz

在过去，要验证 Kubernetes 组件（例如 API 服务器或 kubelet）的运行时配置，通常需要对宿主机节点或进程参数具有特权访问权限。为解决这一问题，引入了 /flagz 端点，通过 HTTP 公开其命令行选项。但其最初输出仅为纯文本，使自动化工具难以可靠地解析并校验配置。

在 Kubernetes v1.35 中，/flagz 端点增强为支持结构化、机器可读的 JSON 输出。经授权的用户现在可以通过标准 HTTP 内容协商请求版本化的 JSON 响应，同时原先的纯文本格式仍保留，便于人工查看。此更新显著改进可观测性与合规工作流，让外部系统无需脆弱的文本解析或直接基础设施访问，即可通过编程方式审计组件配置。

此项工作是 KEP #4828 的一部分，由 SIG Instrumentation 牵头完成。

Kubernetes 组件的 Statusz

传统上，排查 kube-apiserver 或 kubelet 等 Kubernetes 组件问题，往往需要解析非结构化日志或文本输出，这种方式脆弱且难以自动化。此前虽然存在基础的 /statusz 端点，但缺乏标准化、机器可读的格式，从而限制了外部监控系统的可用性。

在 Kubernetes v1.35 中，/statusz 端点增强为支持结构化、机器可读的 JSON 输出。经授权的用户现在可以通过标准 HTTP 内容协商请求这一格式，以获取精确的状态数据——例如版本信息与健康指标——而无需依赖脆弱的文本解析。该改进为所有核心组件的自动化调试与可观测性工具提供了可靠且一致的接口。

此项工作是 KEP #4827 的一部分，由 SIG Instrumentation 牵头完成。

CCM：基于 Informer 的 Watch 式路由控制器调谐

在云环境中管理网络路由，传统上依赖云控制器管理器（CCM）定期轮询云提供商 API 来校验并更新路由表。这种固定间隔的调谐方式可能效率不高，常会产生大量不必要的 API 调用，并在节点状态变化与路由更新之间引入延迟。

在 Kubernetes v1.35 中，cloud-controller-manager 库为路由控制器引入基于 watch 的调谐策略。控制器不再依赖定时器，而是利用 Informer 监听特定的 Node 事件，例如新增、删除或相关字段更新，仅在确有变更发生时触发路由同步。

其主要收益是显著减少对云提供商 API 的使用，从而降低触发速率限制的风险并减少运维开销。此外，这种事件驱动模型通过确保路由表在集群拓扑变化后立即更新，提升了集群网络层的响应速度。

此项工作是 KEP #5237 的一部分，由 SIG Cloud Provider 牵头完成。

用于基于阈值放置的扩展容忍度运算符

Kubernetes v1.35 通过允许工作负载表达可靠性要求，引入 SLA 感知调度（SLA-aware scheduling）。该特性为容忍度增加数值比较运算符，让 Pod 可以依据与 SLA 相关的污点（例如服务保障或故障域质量）来匹配或避开节点。

其主要收益是让调度器具备更精确的放置能力。关键工作负载可要求更高 SLA 的节点，而低优先级工作负载则可选择使用较低 SLA 的节点。这在不牺牲可靠性的前提下提升了利用率并降低成本。

此项工作是 KEP #5471 的一部分，由 SIG Scheduling 牵头完成。

Job 挂起时可变更的容器资源

运行批处理工作负载时，经常需要对资源限制进行反复试错。目前 Job 规约是不可变的，这意味着当 Job 因内存不足（OOM）或 CPU 不足而失败时，用户无法直接调整资源；他们必须删除 Job 并重新创建，从而丢失执行历史与状态信息。

Kubernetes v1.35 引入一种能力：对处于挂起状态的 Job 更新资源请求与限制。通过 MutablePodResourcesForSuspendedJobs 特性门控启用后，用户可以暂停一个失败的 Job，修改其 Pod 模板中的资源值，然后在修正配置后恢复执行。

其主要收益是让配置错误的 Job 具备更平滑的恢复流程。通过允许在挂起期间进行原地修正，用户可以消除资源瓶颈，而不会破坏 Job 的生命周期标识，也不会丢失完成状态追踪，从而显著改善批处理场景下的开发体验。

此项工作是 KEP #5440 的一部分，由 SIG Apps 牵头完成。

其他值得关注的变更

动态资源分配（DRA）的持续创新

核心能力在 v1.34 中进阶至稳定（GA）阶段，并允许关闭。在 v1.35 中，此特性将始终被启用。此外，若干 Alpha 特性也得到了显著改进，已准备好进行测试。我们鼓励用户就这些能力提供反馈，以帮助它们在后续版本中更顺利地走向 Beta。

通过 DRA 扩展资源请求

相较于通过设备插件（Device Plugins）实现的扩展资源请求，当前版本补齐了若干特性差距，例如对 Init 容器中设备的打分与复用能力。

设备污点与容忍度

新的 “None” 效果可用于报告问题，而不会立刻影响调度或正在运行的 Pod。 DeviceTaintRule 现在还会提供正在进行驱逐的状态信息。在真正开始驱逐 Pod 之前，可以先用 “None” 效果进行一次“演练”（dry run）：

使用 effect: None 创建 DeviceTaintRule。
检查状态，了解将会驱逐多少个 Pod。
将 effect: None 替换为 effect: NoExecute。

可切分设备

属于同一类可切分设备（Partitionable Devices）的设备，现在可以定义在不同的 ResourceSlice 中。

更多信息请参阅官方文档。

可消耗容量与设备绑定条件

该版本修复了若干缺陷并添加了更多测试。

你可以在官方文档中进一步了解可消耗容量与绑定条件。

可比较的资源版本语义

Kubernetes v1.35 改变了客户端被允许解释资源版本（resource versions）的方式。

在 v1.35 之前，客户端唯一受支持的比较方式是字符串相等性检查：如果两个资源版本相等，它们就是同一个版本。客户端也可以向 API 服务器提供资源版本，并请求控制平面执行内部比较，例如流式获取自某个资源版本以来的所有事件。

在 v1.35 中，所有 in-tree 的资源版本都满足更严格的新定义：它们的取值是一种特殊形式的十进制数。由于这些值可比较，客户端也可以自行比较两个不同的资源版本。

例如，这意味着客户端在崩溃后重新连接时，可以检测自己是否丢失了更新，而不仅仅是判断“期间是否有更新但没有丢失变更”的情况。

这一语义变更还支撑了其他重要用例，例如存储版本迁移、对 informers （一种客户端辅助概念）的性能改进，以及控制器可靠性提升。这些用例都需要能够判断一个资源版本是否比另一个更新。

此项工作是 KEP #5504 的一部分，由 SIG API Machinery 牵头完成。

v1.35 的升级、弃用与移除

进入稳定（GA）阶段的特性

这里列出所有进入稳定（也称为 正式发布（GA））阶段的特性。要获取包含新增特性与从 Alpha 升级到 Beta 等在内的完整更新列表，请参阅发布说明。

本次发布共有 15 个增强项进入稳定（GA）阶段：

为 CPUManager 策略增加选项，将 reservedSystemCPUs 限定用于系统守护进程与中断处理

Pod Generation

Invariant Testing

Pod 资源原地更新

更细粒度的 SupplementalGroups 控制

支持 drop-in kubelet 配置目录

移除 Kubernetes API 类型对 gogo protobuf 的依赖

kubelet 镜像垃圾回收：基于最大镜像年龄

kubelet 并行拉取镜像的上限

为 TopologyManager 策略增加 MaxAllowableNUMANodes 选项

在 HTTP 请求头中包含 kubectl 命令元数据

PreferSameNode 流量分配（原 PreferLocal 流量策略/节点级拓扑）

Job API 的 managed-by 机制

从 SPDY 迁移到 WebSockets

弃用、移除与社区更新

随着 Kubernetes 的发展与成熟，为提升项目整体健康度，一些特性可能会被弃用、移除，或被更好的方案替代。关于这一过程的更多信息，请参阅 Kubernetes 的弃用与移除策略。 Kubernetes v1.35 包含了若干项弃用内容。

Ingress NGINX 退役

多年来，Ingress NGINX 控制器一直是将流量路由到 Kubernetes 集群的热门选择。它灵活、被广泛采用，并长期作为无数应用的标准入口。

然而，项目维护已经变得难以为继。由于维护者严重短缺且技术债不断累积，社区近期做出了艰难决定：让该项目退役。这虽然并非严格意义上的 v1.35 发布内容，但它影响重大，我们希望在这里特别强调。

因此，Kubernetes 项目宣布 Ingress NGINX 将仅提供尽力而为的维护，直至 2026 年 3 月。此日期之后，该项目将归档并不再更新。推荐的后续路径是迁移到 Gateway API，它提供了更现代、更安全且更可扩展的流量管理标准。

更多信息请参阅官方博客文章。

移除对 cgroup v1 的支持

在 Linux 节点的资源管理方面，Kubernetes 历史上依赖 cgroups（control groups）。尽管最初的 cgroup v1 可以工作，但它常常不一致且存在局限。因此，Kubernetes 在 v1.25 引入对 cgroup v2 的支持，提供了更干净的统一层级结构与更好的资源隔离能力。

由于 cgroup v2 现已成为现代标准， Kubernetes 准备在 v1.35 中退役遗留的 cgroup v1 支持。这对集群管理员而言是一项重要提醒：如果你仍在运行不支持 cgroup v2 的旧 Linux 发行版节点，你的 kubelet 将无法启动。为避免停机，你需要将这些节点迁移到启用了 cgroup v2 的系统上。

要了解更多信息，请阅读关于 cgroup v2；
你也可以通过 KEP-5573：移除 cgroup v1 支持跟踪切换工作。

kube-proxy 中 ipvs 模式的弃用

多年前，Kubernetes 在 kube-proxy 中采用ipvs 模式，以提供比标准iptables 更快的负载均衡。虽然它带来了性能提升，但为了跟上不断演进的网络需求，维护其一致性所带来的技术债与复杂度已过高。

由于这一维护负担，Kubernetes v1.35 弃用 ipvs 模式。尽管该模式在本次发布中仍可用，但当 kube-proxy 被配置为使用该模式时，将在启动时发出警告。该弃用的目标是精简代码库并聚焦于现代标准。对于 Linux 节点，你应开始迁移到nftables，它现在是推荐的替代方案。

更多信息请参阅 KEP-5495：弃用 kube-proxy 的 ipvs 模式。

containerd v1.X 的最后通告

尽管 Kubernetes v1.35 仍支持 containerd 1.7 与其他 LTS 版本，但这是最后一个提供此类支持的版本。 SIG Node 社区已将 v1.35 指定为最后一个支持 containerd v1.X 系列的版本。

这是一条重要提醒：在升级到下一个 Kubernetes 版本之前，你必须切换到 containerd 2.0 或更高版本。为帮助识别哪些节点需要关注，你可以在集群中监控 kubelet_cri_losing_support 指标。

更多信息可参阅官方博客文章，或阅读 KEP-4033：从 CRI 发现 cgroup driver。

`kubelet` 重启期间的 Pod 稳定性改进

此前，重启 kubelet 服务往往会造成 Pod 状态的短暂波动。在重启期间，kubelet 会重置容器状态，导致健康的 Pod 被标记为 NotReady 并从负载均衡器中移除，即便应用本身仍在正常运行。

为解决这一可靠性问题，该行为已被修正，以确保节点维护更平滑。 kubelet 现在会在启动时从运行时中正确恢复现有容器状态，确保你的工作负载保持 Ready，并使流量在 kubelet 重启或升级期间持续不中断。

发布说明

请在我们的发布说明中查看 Kubernetes v1.35 发布的完整细节。

可用性

Kubernetes v1.35 可通过GitHub 或 Kubernetes 下载页面获取。

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

发布团队

Kubernetes 之所以成为可能，离不开社区的支持、承诺与辛勤付出。每个发布团队由一群投入的社区志愿者组成，他们一起构建你所依赖的 Kubernetes 发布版本的诸多部分。这需要来自社区各个角落的专业能力：从代码本身到文档与项目管理。

我们在此缅怀Han Kang ——一位长期贡献者与备受尊敬的工程师，他的技术卓越与感染力十足的热情，为 Kubernetes 社区留下了深远影响。Han 是 SIG Instrumentation 与 SIG API Machinery 中的重要力量，并因其关键工作与对项目核心稳定性的持续投入，获得了2021 Kubernetes Contributor Award。除技术贡献之外，Han 也因其作为导师的慷慨与联结人们的热情而广受敬重。他以“为他人打开大门”而闻名——无论是带领新贡献者完成第一次 PR，还是以耐心与善意支持同事。Han 的遗产将通过他所激励的工程师、他参与构建的健壮系统，以及他在云原生生态中所塑造的温暖协作精神延续下去。

我们感谢整个发布团队为向社区交付 Kubernetes v1.35 所付出的辛勤时间。发布团队成员既有第一次参与的 shadow，也有历经多轮发布周期、经验丰富的回归 team lead。我们尤其感谢发布负责人Drew Hagen：他既以务实指导带我们穿越复杂挑战，也以充沛能量点燃了这次成功发布背后的社区精神。

项目活跃度

CNCF K8s 的DevStats 项目汇总了与 Kubernetes 及其各子项目活跃度相关的一系列有趣数据点。这些数据涵盖从个人贡献到参与贡献公司的数量等多个方面，体现了推动该生态演进所投入努力的深度与广度。

在 v1.35 发布周期（从 2025 年 9 月 15 日到 2025 年 12 月 17 日，共 14 周）期间， Kubernetes 收到了来自多达 85 家公司与 419 名个人的贡献。在更广泛的云原生生态中，这一数字上升到 281 家公司，共计 1769 名贡献者。

请注意，这里的“贡献”统计包括：提交 commit、进行代码评审、发表评论、创建 Issue 或 PR、评审 PR（包括博客与文档）以及对 Issue 与 PR 的评论等。
如果你有兴趣参与贡献，请访问贡献者网站上的Getting Started。

数据来源：

贡献 Kubernetes 的公司

整体生态的贡献

活动更新

了解即将到来的 Kubernetes 与云原生活动，包括 KubeCon + CloudNativeCon、KCD 与全球其他重要会议。保持关注并参与 Kubernetes 社区！

2026 年 2 月

KCD - Kubernetes Community Days: New Delhi：2026 年 2 月 21 日｜印度 New Delhi

KCD：Guadalajara：2026 年 2 月 23 日｜墨西哥 Guadalajara

2026 年 3 月

KubeCon + CloudNativeCon Europe 2026：2026 年 3 月 23-26 日｜荷兰 Amsterdam

2026 年 5 月

KCD - Kubernetes Community Days: Toronto：2026 年 5 月 13 日｜加拿大 Toronto

KCD - Kubernetes Community Days: Helsinki：2026 年 5 月 20 日｜芬兰 Helsinki

2026 年 6 月

KubeCon + CloudNativeCon India 2026：2026 年 6 月 18-19 日｜印度 Mumbai

KCD：Kuala Lumpur：2026 年 6 月 27 日｜马来西亚 Kuala Lumpur

2026 年 7 月

KubeCon + CloudNativeCon Japan 2026：2026 年 7 月 29-30 日｜日本 Yokohama

你可以在此处查看最新活动详情。

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

欢迎在 2026 年 1 月 14 日（星期三）17:00（UTC） 与 Kubernetes v1.35 发布团队成员一起，了解本次发布的重点亮点。有关更多信息与注册方式，请访问 CNCF Online Programs 网站上的活动页面。

参与其中

在 Bluesky 关注我们：@Kubernetesio，获取最新动态

在 Discuss 加入社区讨论

在 Slack 加入社区

在 Stack Overflow 提问（或解答问题）

分享你的 Kubernetes 故事

在博客阅读 Kubernetes 的更多动态

了解更多关于 Kubernetes 发布团队的信息

Kubernetes v1.35 抢先一览

Wed, 26 Nov 2025 00:00:00 +0000

随着 Kubernetes v1.35 发布的临近，Kubernetes 项目持续演进。为了改善项目的整体健康状况，某些功能可能会被弃用、移除或替换。本博客文章概述了 v1.35 版本的计划变更，发布团队认为你应该了解这些变更，以确保 Kubernetes 集群的持续平稳运行，并让你了解最新进展。以下信息基于 v1.35 版本的当前状态，在最终发布日期之前可能会发生变化。

Kubernetes v1.35 的弃用和移除

cgroup v1 支持

在 Linux 节点上，容器运行时通常依赖于 cgroups（"control groups" 的缩写）。自 v1.25 以来，Kubernetes 中对 cgroup v2 的支持已经稳定，为原有的 v1 cgroup 支持提供了替代方案。虽然 cgroup v1 提供了初始的资源控制机制，但它存在众所周知的不一致性和局限性。添加对 cgroup v2 的支持允许使用统一的控制组层次结构，改善了资源隔离，并为现代功能奠定了基础，使得传统的 cgroup v1 支持可以准备移除。移除 cgroup v1 支持只会影响在不支持 cgroup v2 的旧版 Linux 发行版上运行节点的集群管理员；在这些节点上，kubelet 将无法启动。管理员必须将其节点迁移到启用了 cgroup v2 的系统。关于兼容性要求的更多详细信息将在 v1.35 发布后不久在博客文章中提供。

要了解更多信息，请阅读关于 cgroup v2；你也可以通过 KEP-5573：移除 cgroup v1 支持跟踪切换工作。

kube-proxy 中 ipvs 模式的弃用

许多版本之前，Kubernetes 项目在 kube-proxy 中实现了 ipvs 模式。它被采用作为一种提供高性能服务负载均衡的方式，性能优于现有的 iptables 模式。然而，由于技术复杂性和需求分歧，在 ipvs 和其他 kube-proxy 模式之间保持功能对等变得困难。这造成了重大的技术债务，并使 ipvs 后端难以与更新的网络功能一起支持。

Kubernetes 项目计划在 v1.35 版本中弃用 kube-proxy ipvs 模式，以简化 kube-proxy 代码库。对于 Linux 节点，推荐的 kube-proxy 模式已经是 nftables。

你可以在 KEP-5495：弃用 kube-proxy 中的 ipvs 模式中找到更多信息。

Kubernetes 正在弃用 containerd v1.y 支持

虽然 Kubernetes v1.35 仍然支持 containerd 1.7 和其他 containerd LTS 版本，但由于自动化的 cgroup 驱动程序检测， Kubernetes SIG Node 社区已正式商定了 containerd v1.X 的最终支持时间表。 Kubernetes v1.35 是提供此支持的最后一个版本（与 containerd 1.7 EOL 对齐）。

这是最终警告：如果你正在使用 containerd 1.X，必须在将 Kubernetes 升级到下一个版本之前切换到 2.0 或更高版本。你可以监控 kubelet_cri_losing_support 指标来确定集群中的任何节点是否正在使用即将不受支持的 containerd 版本。

你可以在官方博客文章或 KEP-4033：从 CRI 发现 cgroup 驱动程序中找到更多信息。

Kubernetes v1.35 的重点增强功能

以下增强功能是可能包含在 v1.35 版本中的部分功能。这不是承诺，发布内容可能会发生变化。

节点声明式特性

在调度 Pod 时，Kubernetes 使用节点标签、污点和容忍度来匹配工作负载需求与节点能力。然而，由于控制平面和节点之间的版本偏移，在集群升级期间管理功能兼容性变得具有挑战性。这可能导致 Pod 被调度到缺少所需功能的节点上，从而导致运行时失败。

**节点声明式特性（Node Declared Features）**框架将引入一种标准机制，让节点声明其所支持的 Kubernetes 特性。启用这一新的 Alpha 特性后，节点会报告其可以支持的特性，通过新的 .status.declaredFeatures 字段将此信息发布到控制平面。然后，kube-scheduler、准入控制器和第三方组件可以使用这些声明。例如，你可以强制执行调度和 API 验证约束，确保 Pod 仅在兼容的节点上运行。

这种方法可以减少手动为节点打标签的操作，提高调度准确性，并主动防止不兼容的 Pod 放置。它还与集群自动扩缩器（Cluster Autoscaler）集成，以便做出明智的扩容决策。特性声明是临时性的，并与 Kubernetes 特性门控绑定，从而实现安全的推出和清理。

目标是在 v1.35 中达到 Alpha 阶段，节点声明式特性旨在通过明确节点能力来解决版本偏移调度问题，在异构版本环境中增强可靠性和集群稳定性。

在官方文档发布之前了解更多信息，你可以阅读 KEP-5328。

Pod 资源的原地更新

Kubernetes 正在将 Pod 资源的原地更新提升到正式发布（GA）状态。此特性允许用户在不重启 Pod 或容器的情况下调整 cpu 和 memory 资源。以前，此类修改需要重新创建 Pod，这可能会中断工作负载，特别是对于有状态或批处理应用程序。

之前的 Kubernetes 版本已经允许你更改现有 Pod 的基础设施资源设置（requests 和 limits）。这允许更平滑的垂直扩缩容，提高效率，还可以简化解决方案开发。

容器运行时接口（CRI）也得到了改进，为 Windows 和未来的运行时扩展了 UpdateContainerResources API，同时允许 ContainerStatus 报告实时的资源配置情况。这些更改一起使 Kubernetes 中的扩缩容更快、更灵活且无中断。此特性在 v1.27 中作为 Alpha 特性引入，在 v1.33 中升级到 Beta，并且计划在 v1.35 中升级到稳定状态。

你可以在 KEP-1287：Pod 资源的原地更新中找到更多信息。

Pod 证书

在运行微服务时，Pod 通常需要强加密身份，以便使用双向 TLS（mTLS）相互进行身份认证。虽然 Kubernetes 提供服务账号令牌，但这些令牌设计用于向 API 服务器进行身份认证，而不是用于通用工作负载身份。

在此增强之前，操作员必须依赖复杂的外部项目（如 SPIFFE/SPIRE 或 cert-manager）来为其工作负载提供和轮换证书。但是，如果你可以原生且自动地为 Pod 颁发唯一的短期证书呢？ KEP-4317 旨在启用这种原生工作负载身份。它通过允许 kubelet 通过投影卷为 Pod 请求和挂载证书，为保护 Pod 到 Pod 的通信开辟了多种可能性。

Pod 证书为工作负载身份提供了一种内置的机制，包括自动证书轮换，显著简化了服务网格和其他零信任网络策略的设置。该特性在 v1.34 中作为 Alpha 特性引入，目标是在 v1.35 中达到 Beta 阶段。

你可以在 KEP-4317：Pod 证书中找到更多信息。

数值形式的污点

Kubernetes 正在通过添加数值比较运算符（如 Gt（大于）和 Lt（小于））来增强污点和容忍度。

以前，容忍度仅支持精确（Equal）或存在（Exists）匹配，这不适用于可靠性 SLA 等数值属性。

通过此更改，Pod 可以使用容忍度来"选择"满足特定数值阈值的节点。例如，Pod 可以要求 SLA 污点值大于 950 的节点（operator: Gt，value: "950"）。

这种方法比节点亲和性更强大，因为它支持 NoExecute 效果，如果节点的数值降至容忍阈值以下，允许自动驱逐 Pod。

你可以在 KEP-5471：启用基于 SLA 的调度中找到更多信息。

用户名字空间

在运行 Pod 时，你可以使用 securityContext 来去除特权，但 Pod 内的容器通常仍以 root（UID 0）运行。这种简单性带来了重大挑战，因为容器 UID 0 直接映射到主机的 root 用户。

在此增强之前，容器逃逸漏洞可能授予攻击者对节点的完全 root 访问权限。但是，如果你可以将容器的 root 用户动态重新映射到主机上的安全、无特权用户呢？ KEP-127 专门为 Linux 用户名字空间提供原生支持。它通过隔离容器和主机用户/组 ID 为 Pod 安全开辟了各种可能性。这允许进程在其名字空间内拥有 root 权限（UID 0），同时在主机上以非特权的高编号 UID 运行。

该特性在 v1.25 中作为 Alpha 特性发布，并在 v1.30 中进阶到 Beta 阶段，在 Beta 成熟度级别，此特性仍在进一步演化，为真正的"无 root"容器铺平道路，这些改进大大减少了一整类安全漏洞的攻击面。

你可以在 KEP-127：用户名字空间中找到更多信息。

支持将 OCI 镜像挂载为卷

在配置 Pod 时，你经常需要为容器打包数据、二进制文件或配置文件。在此增强之前，人们通常将此类数据直接包含在主容器镜像中，或需要自定义 Init 容器将文件下载并解压到 emptyDir 中。当然，你仍然可以采用这两种方法中的任何一种。

但是，如果你可以直接使用 OCI 镜像库中的纯数据工件填充卷，就像拉取容器镜像一样呢？ Kubernetes v1.31 添加了对 image 卷类型的支持，允许 Pod 以声明的方式将 OCI 容器镜像工件拉取并解压到卷中。

这一特性使我们能够使用标准镜像库工具无缝分发数据、二进制文件或 ML 模型，完全将数据与容器镜像解耦，并消除对复杂 Init 容器或启动脚本的需求。此卷类型自 v1.33 以来一直处于 Beta 状态，并可能在 v1.35 中默认启用。

你可以试用 image 卷的 Beta 版本，或者你可以从 KEP-4639：OCI 卷源了解更多计划。

想了解更多？

新特性和弃用也在 Kubernetes 发布说明中宣布。我们将正式宣布 Kubernetes v1.35 的新内容，作为该版本 CHANGELOG 的一部分。

Kubernetes v1.35 版本计划于 2025 年 12 月 17 日发布。请关注更新！

你还可以在以下版本的发布说明中查看变更公告：

参与进来

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

在 Bluesky 上关注我们 @kubernetes.io 获取最新动态
在 Discuss 上加入社区讨论
在 Slack 上加入社区
在 Server Fault 或 Stack Overflow 上发布问题（或回答问题）
分享你的 Kubernetes 故事
在博客上阅读更多关于 Kubernetes 正在发生的事情
了解更多关于 Kubernetes 发布团队的信息

Kubernetes 配置最佳实践

Tue, 25 Nov 2025 00:00:00 +0000

配置是 Kubernetes 中看似微不足道，实则关键的事情之一。配置是每个 Kubernetes 工作负载的核心。一个缺失的引号、错误的 API 版本或错位的 YAML 缩进都可能毁掉你的整个部署。

本博客汇集了经过验证的配置最佳实践。这些小的习惯让你的 Kubernetes 设置更干净、一致且更易于管理。无论你是刚刚开始还是已经在每天部署应用，这些都是让你的集群保持稳定、让未来的你保持理智的小细节。

本博客的灵感源自最初的 Configuration Best Practices（配置最佳实践）页面，该页面由 Kubernetes 社区众多成员的贡献不断演进而来。

通用配置实践

使用最新的稳定 API 版本

Kubernetes 发展很快。旧版 API 最终会被弃用并停止工作。因此，在定义资源时，请确保使用最新的稳定 API 版本。你可以随时使用以下命令检查：

kubectl api-resources

这个简单的步骤可以让你避免未来的兼容性问题。

将配置存储在版本控制中

永远不要直接从桌面应用清单文件。始终将它们保存在像 Git 这样的版本控制系统中，这是你的安全网。如果出现问题，你可以立即回滚到之前的提交、比较更改或重新创建集群设置，而不会惊慌。

使用 YAML 而不是 JSON 编写配置

使用 YAML 而不是 JSON 编写配置文件。两者在技术上都可以工作，但 YAML 对人类来说更容易。它更易读、更简洁，并在社区中广泛使用。

YAML 在布尔值方面有一些隐藏的陷阱：只使用 true 或 false。不要写 yes、no、on 或 off。它们可能在同一个 YAML 版本中工作，但在另一个版本中会失败。为了安全起见，请给任何看起来像布尔值的内容加引号（例如 "yes"）。

保持配置简单和最小化

避免设置 Kubernetes 已经处理的默认值。最小化的清单更容易调试、更易于审查，并且以后不太可能破坏东西。

如果你的 Deployment、Service 和 ConfigMap 都属于一个应用，请将它们放在一个清单文件中。这样更容易跟踪更改并将它们作为一个单元应用。有关此语法的示例，请参阅 Guestbook all-in-one.yaml 文件。

你甚至可以使用以下命令应用整个目录：

kubectl apply -f configs/

只需一个命令，该文件夹中的所有内容都会被部署。

添加有用的注解

清单文件不仅是为机器准备的，也是为人类准备的。使用注解来描述某些内容存在的原因或它的作用。快速的一行注释可以在以后调试时节省数小时，并且还可以实现更好的协作。

最有用的注解是 kubernetes.io/description。这就像使用注释一样，只是它会被复制到 API 中，这样其他人在你部署后也能看到它。

管理工作负载：Pod、Deployment 和 Job

在 Kubernetes 中，一个常见的早期错误是直接创建 Pod。 Pod 可以工作，但如果出现问题，它们不会重新调度自己。

裸 Pod（不受控制器管理的 Pod，例如 Deployment 或 StatefulSet）用于测试是可以的，但在实际设置中，它们是有风险的。

为什么？因为如果托管该 Pod 的节点死亡，Pod 也会随之死亡， Kubernetes 不会自动将其恢复。

对应该始终运行的应用使用 Deployment

Deployment 既创建 ReplicaSet 以确保所需数量的 Pod 始终可用，又指定替换 Pod 的策略（例如滚动更新），几乎总是比直接创建 Pod 更可取。你可以推出新版本，如果出现问题，可以立即回滚。

对应该完成的任务使用 Job

当你需要某些东西运行一次然后停止时（如数据库迁移或批处理任务）， Job 是完美的选择。如果 Pod 失败，它会重试，并在完成时报告成功。

Service 配置和网络

Service 是你的工作负载在集群内部（有时是外部）相互通信的方式。没有它们，你的 Pod 存在但无法被任何人访问。让我们确保这种情况不会发生。

在使用它们的工作负载之前创建 Service

当 Kubernetes 启动 Pod 时，它会自动为现有 Service 注入环境变量。因此，如果 Pod 依赖于 Service，请在其相应的后端工作负载（Deployment 或 StatefulSet）以及任何需要访问它的工作负载之前创建 Service。

例如，如果存在名为 foo 的 Service，所有容器将在其初始环境中获得以下变量：

FOO_SERVICE_HOST=<the host the Service runs on>
FOO_SERVICE_PORT=<the port the Service runs on>

基于 DNS 的发现没有这个问题，但无论如何遵循它是一个好习惯。

使用 DNS 进行 Service 发现

如果你的集群有 DNS 安装扩展（Addon）（大多数都有），每个 Service 都会自动获得一个 DNS 条目。这意味着你可以通过名称而不是 IP 访问它：

curl http://my-service.default.svc.cluster.local

这是让 Kubernetes 网络感觉神奇的特性之一。

除非绝对必要，否则避免使用 `hostPort` 和 `hostNetwork`

你有时会在清单中看到这些选项：

hostPort: 8080
hostNetwork: true

但问题是：它们将你的 Pod 绑定到特定节点，使它们更难调度和扩缩容。因为每个 <hostIP、hostPort、protocol> 组合必须是唯一的。如果你没有明确指定 hostIP 和 protocol， Kubernetes 将使用 0.0.0.0 作为默认 hostIP，使用 TCP 作为默认 protocol。除非你在调试或构建网络插件之类的东西，否则请避免使用它们。

如果你只需要本地访问进行测试，请尝试 kubectl port-forward：

kubectl port-forward deployment/web 8080:80

有关更多信息，请参阅使用端口转发访问集群中的应用程序。或者如果你真的需要外部访问，请使用 type: NodePort Service。这是更安全、更符合 Kubernetes 原生方式的做法。

使用无头 Service 进行内部服务发现

有时，你不想让 Kubernetes 负载均衡流量。你想直接与每个 Pod 通信。这就是无头 Service 的用武之地。

你通过设置 clusterIP: None 来创建一个。 DNS 不是给你一个 IP，而是给你所有 Pod IP 的列表，这非常适合自己管理连接的应用程序。

有效使用标签

标签是附加到 Pod 等对象的键/值对。标签帮助你组织、查询和分组资源。它们本身不做任何事情，但它们使从 Service 到 Deployment 的所有其他内容都能顺利协同工作。

使用语义标签

好的标签可以帮助你理解什么是什么，即使在几个月后也是如此。定义并使用标签来标识应用程序或 Deployment 的语义属性。例如：

labels:
  app.kubernetes.io/name: myapp
  app.kubernetes.io/component: web
  tier: frontend
  phase: test

app.kubernetes.io/name：应用是什么
tier：它属于哪一层（前端/后端）
phase：它处于哪个阶段（测试/生产）

然后你可以使用这些标签来创建强大的选择算符。例如：

kubectl get pods -l tier=frontend

这将列出集群中所有前端 Pod，无论它们来自哪个 Deployment。基本上，你不需要手动列出 Pod 名称；你只是在描述你想要什么。有关此方法的示例，请参阅 guestbook 应用。

使用常见的 Kubernetes 标签

Kubernetes 实际上推荐一组常见标签。这是在你的不同工作负载或项目中命名事物的一种标准方式。遵循此约定使你的清单更清晰，这意味着诸如 Headlamp、 dashboard 或第三方监控系统等工具都可以自动理解正在运行的内容。

操作标签进行调试

由于控制器（如 ReplicaSet 或 Deployment）使用标签来管理 Pod，你可以删除标签以临时 "分离" Pod。

示例：

kubectl label pod mypod app-

app- 部分会删除标签键 app。一旦发生这种情况，控制器将不再管理该 Pod。这就像将其隔离以进行检查，一种用于调试的"隔离模式"。要交互式地删除或添加标签，请使用 kubectl label。

然后你可以检查 Pod 日志、exec 进入 Pod，完成后手动删除 Pod。这是每个 Kubernetes 工程师都应该知道的超级被低估的技巧。

实用的 kubectl 技巧

这些小技巧使你在处理多个清单文件或集群时生活变得更加轻松。

应用整个目录

不要一次应用一个文件，而是应用整个文件夹：

# Using server-side apply is also a good practice
kubectl apply -f configs/ --server-side

此命令在该文件夹中查找 .yaml、.yml 和 .json 文件并将它们一起应用。它更快、更清晰，并有助于按应用分组。

使用标签选择算符获取或删除资源

你不需要总是逐个输入资源名称。相反，使用标签选择算符一次对整个组进行操作：

kubectl get pods -l app=myapp
kubectl delete pod -l phase=test

这在 CI/CD 流水线中特别有用，你可以在其中动态清理测试资源。

快速创建 Deployment 和 Service

对于快速实验，你不需要总是编写清单。你可以直接从 CLI 启动 Deployment：

kubectl create deployment webapp --image=nginx

然后将其公开为 Service：

kubectl expose deployment webapp --port=80

当你想在编写完整清单之前测试某些内容时，这非常有用。另外，有关示例，请参阅使用 Service 访问集群中的应用程序。

结论

更清晰的配置可以让集群管理员更为泰然自若。如果你坚持几个简单的习惯：保持配置简单和最小化、对所有内容进行版本控制、使用一致的标签，并避免依赖裸 Pod，你将为自己节省数小时的调试时间。

最好的部分是什么？清晰的配置保持可读性。即使在几个月后，你或团队中的任何人都可以瞥一眼它们并确切知道发生了什么。

Ingress NGINX 退役：你需要了解的内容

Tue, 11 Nov 2025 10:30:00 -0800

为了优先考虑生态系统的安全，Kubernetes SIG Network 和安全响应委员会宣布 Ingress NGINX 即将退役，并将尽力将其维护期持续到 2026 年 3 月。之后，将不再有进一步的版本发布、错误修复和更新来解决可能发现的任何安全漏洞。 现有的 Ingress NGINX Deployment 将继续运行，并且安装工件仍将可用。

我们建议迁移到替代方案之一。考虑迁移到 Gateway API，这是 Ingress 的现代替代品。如果你必须继续使用 Ingress，许多替代的 Ingress 控制器已在 Kubernetes 文档中列出。下文介绍有关 Ingress NGINX 的历史和当前状态以及后续步骤的更多信息。

关于 Ingress NGINX

Ingress 是将网络流量导向运行在 Kubernetes 上的工作负载的原生的、用户友好的方式。（Gateway API 是实现许多相同目标的新方法。）为了使 Ingress 在集群中工作，你必须运行一个 Ingress 控制器。有多种 Ingress 控制器可供选择，可以满足不同用户和使用场景的需求。有些是特定于云提供商的，而其他的则具有更广泛的应用性。

Ingress NGINX 是一个 Ingress 控制器，作为 API 的示例实现，在 Kubernetes 项目早期开发。由于其极大的灵活性、丰富的特性以及不依赖于任何特定的云或基础设施提供商，它变得非常流行。自那时以来，许多其他的 Ingress 控制器已经在 Kubernetes 项目中由社区小组和云原生供应商创建。 Ingress NGINX 一直是其中最受欢迎的选择之一，被部署在许多托管的 Kubernetes 平台上以及无数独立用户的集群中。

历史与挑战

Ingress NGINX 的广度和灵活性导致了维护上的挑战，对于云原生软件不断变化的期望也增加了复杂性。其中曾经被认为是有帮助的选项，有时却被视为严重的安全缺陷，例如通过“片段”注解添加任意 NGINX 配置指令的能力。昨天的灵活性已成为今天的难以克服的技术债务。

尽管该项目在用户中非常受欢迎，但 Ingress NGINX 一直存在一个问题，就是维护者很少、勉强应付。多年来，项目仅有的一到两个人在其业余时间、下班后和周末进行开发工作。去年，Ingress NGINX 维护者宣布他们的计划是逐步停止 Ingress NGINX，并与 Gateway API 社区一起开发替代控制器。不幸的是，即使是这样的公告也未能激起更多兴趣来帮助维护 Ingress NGINX 或开发 InGate 以取代它。（InGate 的开发从未进展到足以创建一个成熟的替代品；它也将被退役。）

当前状态与下一步

目前，Ingress NGINX 的维护模式是尽力而为的。 SIG Network 和安全响应委员会已经用尽全力寻找额外的支持来使 Ingress NGINX 可持续发展。为了优先考虑用户的安全，我们必须停止该项目。

2026 年 3 月，Ingress NGINX 的维护将被停止，项目将被退役。之后，将不再有进一步的版本发布、错误修复或更新来解决可能发现的任何安全漏洞。 GitHub 仓库将变为只读，并留作参考。

现有的 Ingress NGINX 部署不会受到影响。现有的项目制品，如 Helm 图表和容器镜像，仍将保持可用。

在大多数情况下，你可以通过运行 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 来检查是否使用了 Ingress NGINX，这需要集群管理员权限。

我们想感谢 Ingress NGINX 的维护者们在创建和维护此项目中所做的工作——他们的奉献精神令人印象深刻。这个 Ingress 控制器在全球的数据中心和家庭实验室中处理了数十亿次请求。在很多方面，如果没有 Ingress NGINX，Kubernetes 不会取得如今的成就，我们对如此多年的杰出努力表示感激。

**SIG Network 和安全响应委员会建议所有 Ingress NGINX 用户立即开始迁移到 Gateway API 或其他 Ingress 控制器。 ** Kubernetes 文档中列出了许多选项：Gateway API、 Ingress。与你合作的供应商可能还提供其他选项。

公布 2025 年指导委员会选举结果

Sun, 09 Nov 2025 15:10:00 -0500

2025 指导委员会选举现已结束。 Kubernetes 指导委员会由 7 个席位组成，其中 4 个席位在 2025 年进行了选举。新当选的委员会成员将任职 2 年，所有成员均由 Kubernetes 社区选举产生。

指导委员会负责监督整个 Kubernetes 项目的治理。权力越大责任越大，你可以通过他们的章程了解指导委员会的角色。

感谢每位参与投票的人；你的参与有助于支持社区的持续健康和成功。

结果

祝贺当选的委员会成员，其两年任期立即开始（按 GitHub 名称字母顺序列出）：

Kat Cosgrove (@katcosgrove), Minimus
Paco Xu 徐俊杰 (@pacoxu), DaoCloud
Rita Zhang (@ritazh), Microsoft
Maciej Szulik (@soltysh), Defense Unicorns

他们将与以下连任成员一起工作：

Antonio Ojea (@aojea), Google
Benjamin Elder (@BenTheElder), Google
Sascha Grunert (@saschagrunert), Red Hat

Maciej Szulik 和徐俊杰（Paco Xu）是回归的指导委员会成员。

十分感谢！

感谢并祝贺本轮选举官员成功完成选举工作：

Christoph Blecker (@cblecker)
Nina Polshakova (@npolshakova)
Sreeram Venkitesh (@sreeram-venkitesh)

感谢名誉指导委员会成员，你们的服务受到社区的赞赏：

Stephen Augustus (@justaugustus), Bloomberg
Patrick Ohly (@pohly), Intel

感谢所有参加竞选的候选人。

参与指导委员会

这个管理机构与所有 Kubernetes 一样，向所有人开放。你可以关注指导委员会会议记录，并通过提交 Issue 或针对其 repo 创建 PR 来参与。他们在太平洋时间每月第一个周三上午 8:00 举行开放的会议。你还可以通过其公共邮件列表 steering@kubernetes.io 与他们联系。

你可以通过在 YouTube 播放列表上观看过去的会议来了解指导委员会会议的全部内容。

这篇文章是由贡献者通信子项目撰写的。如果你想撰写有关 Kubernetes 社区的故事，请了解有关我们的更多信息。

7 个常见的 Kubernetes 坑（以及我是如何避开的）

Mon, 20 Oct 2025 08:30:00 -0700

Kubernetes 功能强大，但有时也会令人沮丧，这已不是什么秘密。当我刚开始接触容器编排时，我犯了不少错误，足以列出一整张误区清单。在这篇文章中，我想分享我遇到的（或看到其他人遇到的）七个常见误区，以及如何避免它们的建议。无论你只是刚开始尝试 Kubernetes，还是已经在管理生产集群，我希望这些见解能帮助你避免一些额外的麻烦。

1. 忽略资源 requests 和 limits

常见误区：在 Pod 规约中未指定 CPU 和内存需求。这种情况经常发生，原因是 Kubernetes 不要求这些字段必须设置，工作负载通常可以在没有这些字段的情况下启动和运行—— 这使得在早期配置或快速部署周期中很容易忽略这些设置。

背景：在 Kubernetes 中，资源请求和限制对于高效的集群管理至关重要。资源请求确保调度器为每个 Pod 预留适当数量的 CPU 和内存，保证它有必要的资源来运行。资源限制限制了 Pod 可以使用的 CPU 和内存数量，防止任何单个 Pod 消耗过多资源而可能导致其他 Pod 资源不足。当未设置资源请求和限制时：

资源不足：Pod 可能未获得足够的资源，导致性能下降或运行失败。这是因为 Kubernetes 根据这些请求来调度 Pod。没有这些请求，调度器可能会在单个节点上放置过多的 Pod，导致资源竞争和性能瓶颈。
资源囤积：相反，没有设置限制值时，一个 Pod 可能会消耗过多的资源，影响同一节点上其他 Pod 的性能和稳定性。这可能导致其他 Pod 因内存不足而被驱逐或被 OOM（Out-Of-Memory）强制终止。

如何避免：

从适度的 requests 开始（例如 100m CPU、128Mi 内存），观察应用的行为。
监控实际使用情况并优化你的值；Pod 水平自动扩缩可以帮助基于指标自动扩缩容。
关注 kubectl top pods 或你的日志/监控工具，确认你没有过多或过少地配置资源。

我的经验教训：早期，我从未考虑过内存限制。在我的本地集群上一切看起来都很好。后来，在更大的环境中，Pod 被 OOMKilled（内存不足终止）的情况比比皆是。教训深刻。有关为容器配置资源请求和限制的详细说明，请参阅为容器和 Pod 分配内存资源（Kubernetes 官方文档的一部分）。

2. 低估了存活探针和就绪态探针的重要性

常见误区：部署容器时未明确定义 Kubernetes 应如何检查其健康状态或就绪状态。这通常发生在 Kubernetes 只要容器内的进程未退出就认为容器“正在运行”的情况下。在没有额外的信号的情况下，Kubernetes 会假设工作负载正在运行—— 即使内部的应用无响应、正在初始化或卡住。

背景：存活态、就绪态和启动探针是 Kubernetes 用来监控容器健康状态和可用性的机制。

存活态探针确定应用是否仍然存活。如果存活态检查失败，容器会被重启。
就绪态探针控制容器是否准备好接收流量。在就绪态探针通过之前，容器会从 Service 端点中移除。
启动探针帮助区分长时间启动和实际故障。

如何避免：

添加一个简单的 HTTP livenessProbe 来检查健康端点（例如 /healthz），以便 Kubernetes 可以重启挂起的容器。
使用 readinessProbe 确保在应用预热完成之前流量不会到达应用。
保持探针简单。过于复杂的检查可能会产生误报和不必要的重启。

我的经验教训：我曾经忘记为一个需要一段时间才能加载的 Web 服务设置就绪态探针。用户过早访问了它，遇到了奇怪的超时，我花了几个小时才找到问题。一个 3 行的就绪态探针就能解决这个问题。

有关为容器配置存活态、就绪态和启动探针的全面说明，请参阅 Kubernetes 官方文档中的配置存活、就绪和启动探针。

3. "我们只需要查看容器日志"（著名的遗言）

常见误区：仅依赖通过 kubectl logs 检索的容器日志。这种想法背后的原因通常是因为查看日志的命令既快速又便捷，在许多集群环境中，日志在开发或早期故障排除时似乎可以访问。然而，kubectl logs 只能从当前正在运行或最近终止的容器中检索日志，这些日志存储在节点的本地磁盘上。一旦容器被删除、驱逐或节点重启，日志文件可能会被轮换掉或永久丢失。

如何避免：

集中化日志：使用 CNCF 工具如 Fluentd 或 Fluent Bit 来聚合所有 Pod 的输出。
采用 OpenTelemetry：用于构造日志、指标和（如果需要）追踪的统一视图。这让你能够发现基础设施事件和应用级行为之间的关联。
将日志与 Prometheus 指标对应起来：与应用日志同时跟踪集群级数据。如果你需要分布式追踪，可以考虑 Jaeger 这类 CNCF 项目。

我的经验教训：第一次因为快速重启而丢失 Pod 日志时，我意识到仅依赖 "kubectl logs" 是多么不可靠。从那时起，我为每个集群都搭建了完整的日志采集管道，以避免错过任何关键线索。

4. 将开发环境和生产环境视为完全相同

常见误区：在开发、预发布和生产环境中使用相同的 Kubernetes 清单和相同的设置进行部署。在团队追求一致性和复用，但忽略了环境特定的因素——如流量模式、资源可用性、扩缩容需求或访问控制—— 可能显著不同时，常会发生这种情况。如果略过定制这一步骤，针对一个环境优化的配置可能会导致负载在另一个环境下不稳定、性能差或暴露安全漏洞。

如何避免：

使用环境覆盖层或 kustomize 来维护共享基础，同时为每个环境定制资源请求、副本数或配置。
将环境特定的配置提取到 ConfigMap 和/或 Secret 中。你可以使用专门的工具如 Sealed Secrets 来管理机密数据。
为生产环境中的扩缩需求做规划。你的开发集群可能只需要最少的 CPU/内存，但生产环境可能需要显著更多。

我的经验教训：有一次，我在一个很小的开发环境中将 replicaCount 从 2 扩展到 10，只是为了"测试"。我立即耗尽了资源，花了半天时间清理后果。

5. 遗留未清理的旧资源

常见误区：在集群中遗留未使用或过时的资源——例如 Deployment、Service、ConfigMap 或 PersistentVolumeClaim。这种情况经常发生，因为 Kubernetes 不会自动删除资源，除非明确指示；同时系统也没有内建机制来追踪资源的归属或过期时间。随着时间推移，这些被遗忘的对象可能不断累积，占用集群资源、增加云成本，并造成运维上的混乱，尤其是在陈旧的 Service 或 LoadBalancer 仍持续转发流量的情况下。

如何避免：

为所有资源添加标签：使用用途或所有者标签。这样，你可以轻松查询不再需要的资源。
定期审计集群：运行 kubectl get all -n <namespace> 查看实际运行的内容，并确认它们都是合法的。
采用 Kubernetes 的垃圾收集：K8s 文档展示了如何自动删除依赖对象。
利用策略自动化：像 Kyverno 这样的工具可以在一定时间后自动删除或阻止过期的资源，或强制执行生命周期策略，这样你就不必记住每个清理步骤。

我的经验教训：在一次黑客松活动结束后，我忘记删除一个绑定到外部负载均衡器的 "test-svc"。三周后我才意识到，这段时间我一直在为那个负载均衡器付费。

6. 过早深入复杂的网络配置

常见误区：在完全理解 Kubernetes 原生网络原语之前引入高级网络解决方案—— 如服务网格、自定义 CNI 插件或多集群通信。这通常发生在团队使用外部工具实现流量路由、可观测性或 mTLS 等功能，而没有首先掌握核心 Kubernetes 网络的工作原理：包括 Pod 到 Pod 通信、ClusterIP Services、DNS 解析和基本 Ingress 流量处理。因此，网络相关问题变得更难排查，特别是当覆盖层引入额外的抽象和故障点时。

如何避免：

从简单开始：部署一个 Deployment、一个 Service，以及一个基础的 Ingress 控制器（例如基于 NGINX 的 Ingress-NGINX）。
确保理解集群内的流量流向、服务发现机制以及 DNS 的配置方式。
仅在确实需要时再引入完整的服务网格或高级 CNI 功能，因为复杂的网络架构会带来额外开销。

我的经验教训：我曾经在一个小的内部应用上尝试 Istio，然后花在调试 Istio 本身上的时间比调试实际应用还多。最终，我退了一步，移除了 Istio，一切运行正常。

7. 对安全性和基于角色的访问控制 (RBAC) 重视不足

常见误区：以不安全的方式配置部署工作负载，例如以 root 用户运行容器、使用 latest 镜像标签、禁用安全上下文（security context），或分配过于宽泛的 RBAC 角色（如 cluster-admin）。这些做法之所以普遍存在，是因为 Kubernetes 默认并不会强制实施严格的安全策略—— 该平台在设计上追求灵活性而非强约束性。如果未显式配置安全策略，集群可能面临容器逃逸、未经授权的权限提升或由于未固定镜像导致的意外生产变更等风险。

如何避免：

使用 RBAC 定义在 Kubernetes 中的角色和权限。虽然 RBAC 是默认且最广泛支持的鉴权机制，Kubernetes 也允许使用替代性的鉴权组件。对于更高级或外部策略需求，可以考虑 OPA Gatekeeper（基于 Rego）、 Kyverno 或使用 CEL 或 Cedar 等策略语言的自定义 Webhook 等解决方案。
将镜像固定到特定版本（不要再使用 :latest！）。这有助于你了解实际部署的内容。
查看 Pod 安全准入（或 Kyverno 等其他解决方案）以强制执行非 root 容器、只读文件系统等。

我的经验教训：我从未遇到过巨大的安全漏洞，但我听过很多警示故事。如果你不加强安全措施，出问题只是时间问题。

最后的话

Kubernetes 非常强大，但它并非全知全能——如果你不明确告知它你的需求，它不会"神奇地"自动做出正确的决策。牢记这些常见误区，你就能避免许多麻烦和时间浪费。错误在所难免（相信我，我也犯过不少），但每一次失误，都是深入理解 Kubernetes 内部工作机制的机会。如果你希望进一步探索，可以查阅官方文档或加入社区 Slack。当然，也欢迎你分享自己的"踩坑经历"或成功经验——毕竟，在云原生这场旅程中，我们都在同行。

祝你部署顺利！

Kubernetes v1.34：从存储卷扩展失效中恢复（GA）

Fri, 19 Sep 2025 10:30:00 -0800

你是否曾经在扩展 Kubernetes 中的持久卷时犯过拼写错误？本来想指定 2TB 却写成了 20TiB？这个看似无害的问题实际上很难修复——项目花了将近 5 年时间才解决。存储扩展的自动恢复此特性在一段时间内一直处于 Beta 状态；不过，随着 v1.34 版本的发布，我们已经将其提升到正式发布状态。

虽然手动从失败的卷扩展中恢复总是可能的，但这通常需要集群管理员权限，而且操作繁琐（更多信息请参见上述链接）。

如果你在申请存储时不小心填错了大小，并且立刻发现了这个错误怎么办？在 Kubernetes v1.34 中，你可以降低 PersistentVolumeClaim（PVC）请求的存储大小，只要上一次扩容操作还未完成，就可以修改为新的大小。 Kubernetes 会自动进行修正，归还因扩容失败而暂时占用的配额，并将关联的 PersistentVolume 调整为你最新指定的大小。

我将通过一个示例来演示这一切是如何工作的。

通过降低 PVC 尺寸完成从失败的扩展操作中恢复

想象一下，你的某个数据库服务器磁盘空间不足，你想将 PVC 从之前指定的 10TB 扩展到 100TB——但你犯了一个拼写错误，指定了 1000TB。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1000TB # 新的大小配置，但不正确！

现在，你的磁盘阵列可能空间不足，或者云平台所分配的配额已用完。不管怎样，我们先来假设扩展到 1000TB 的操作永远不会成功。

在 Kubernetes v1.34 中，你可以轻松地修正错误，重新请求一个新的 PVC 尺寸，令该尺寸比之前错误请求的更小，但前提是它仍需大于最初 PersistentVolume 的实际尺寸。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100TB # 更正后的大小；必须大于 10TB。
                     # 你不能将卷缩小到其实际大小以下。

这不需要管理员干预。更好的是，你临时消耗的任何多余 Kubernetes 配额都将自动返回。

这个故障恢复机制有一点很值得注意：无论你为 PVC 所指定的新尺寸是多少，它必须仍然高于 .status.capacity 中的原始大小。由于 Kubernetes 不支持缩小你的 PV 对象，你一定不能给出低于你的 PVC 请求的最初分配尺寸。

卷扩展操作的错误处理和可观测性提升

即便看似相对较小的更改，也需要我们几乎完全重新实现 Kubernetes 中卷扩展操作的底层工作方式。 PVC 对象中有新的 API 字段可供你监控以观察卷扩展的进度。

对进行中扩展的可观测性改进

你可以查询 PVC 的 .status.allocatedResourceStatus['storage'] 来监控卷扩展操作的进度。对于典型的块卷，字段值应该在 ControllerResizeInProgress、NodeResizePending 和 NodeResizeInProgress 之间转换，并在卷扩展完成时变为 nil（空）。

如果由于某种原因，无法将卷扩展到请求的尺寸，这一字段应该处于对应的 ControllerResizeInfeasible 或 NodeResizeInfeasible 等状态。

你还可以通过观察 pvc.status.allocatedResources 来观察 Kubernetes 正在处理的大小。

改进的错误处理和报告

Kubernetes 现在应该以较慢的速率重试你已经失败的卷扩展操作，它应该向存储系统和 Kubernetes apiserver 发出更少的请求。

卷扩展期间观察到的错误现在作为 PVC 对象上的状况报告，并且应该持久化，不像事件。当卷扩展失败时， Kubernetes 现在将用错误键 ControllerResizeError 或 NodeResizeError 填充 pvc.status.conditions。

修复调整大小工作流中的长期错误

此功能还允许我们修复调整大小工作流中的长期存在的若干错误，例如 Kubernetes issue #115294。如果你观察到任何问题，请将你所发现的错误及如何重新问题的详细信息报告到 https://github.com/kubernetes/kubernetes/issues。

此功能的整个开发周期中充满挑战，如果没有 @msau42、@jsafrane 和 @xing-yang 的反馈，就不可能达到正式发布状态。

感谢所有参与此功能开发的贡献者，同时也感谢 @thockin 和 @liggitt 在各种 Kubernetes 贡献者峰会上提供的意见。

Kubernetes v1.34: 将卷组快照推进至 v1beta2 阶段

Tue, 16 Sep 2025 10:30:00 -0800

卷组快照在 Kubernetes 1.27 版本中作为 Alpha 特性被引入，并在 Kubernetes 1.32 版本中移至 Beta 阶段。 Kubernetes v1.34 的最近一次发布将该支持移至第二个 Beta 阶段。对卷组快照的支持依赖于一组用于组快照的扩展 API。这些 API 允许用户为一组卷获取崩溃一致性快照。在后台，Kubernetes 根据标签选择器对多个 PersistentVolumeClaim 分组，并进行快照操作。关键目标是允许你将这组快照恢复到新卷上，并基于崩溃一致性恢复点恢复工作负载。

此新特性仅支持 CSI 卷驱动。

Beta 2 的新内容

在测试 Beta 版本时，我们遇到了一个问题：如果 CSI 驱动未实现 ListSnapshots RPC 调用，则对于单独的 VolumeSnapshotContent 和 VolumeSnapshot 来说，restoreSize 字段不会被设置。我们在这里评估了不同的选项此处，并决定为此发布一个新的 Beta 版本 API。

具体来说，在 v1beta2 中添加了一个 VolumeSnapshotInfo 结构，它包含了属于卷组快照成员的单个卷快照的信息。

VolumeSnapshotInfoList，即 VolumeSnapshotInfo 的列表，被添加到 VolumeGroupSnapshotContentStatus 中，取代了 VolumeSnapshotHandlePairList。

VolumeSnapshotInfoList 是 CSI 驱动通过 ListSnapshots 调用返回的快照信息列表，用于识别存储系统上的快照。

VolumeSnapshotInfoList 由 csi-snapshotter 边车根据 CSI 驱动的 CreateVolumeGroupSnapshot 调用返回的 CSI CreateVolumeGroupSnapshotResponse 填充。

现有的 v1beta1 API 对象将通过转换 Webhook 转换为新的 v1beta2 API 对象。

接下来？

根据反馈和采用情况，Kubernetes 项目计划在未来的版本中将卷组快照实现推进到正式发布版本（GA）。

如何了解更多？

卷组快照特性的设计规范。
卷组快照 API 和控制器的代码仓库。
CSI 关于组快照特性的文档。

如何参与？

这个项目，如同所有的 Kubernetes 项目一样，是许多来自不同背景的贡献者共同努力的结果。代表 SIG Storage，我想对过去几个季度中挺身而出帮助项目达到 Beta 阶段的贡献者们表示巨大的感谢：

Ben Swartzlander (bswartz)
Hemant Kumar (gnufied)
Jan Šafránek (jsafrane)
Madhu Rajanna (Madhu-1)
Michelle Au (msau42)
Niels de Vos (nixpanic)
Leonardo Cecchi (leonardoce)
Saad Ali (saad-ali)
Xing Yang (xing-yang)
Yati Padia (yati1998)

对于那些有兴趣参与 CSI 或 Kubernetes 存储系统任何部分的设计和开发的人，可以加入 Kubernetes 存储特别兴趣小组（SIG）。我们始终欢迎新的贡献者。

我们还定期举行数据保护工作组会议。新参会者可以加入我们的讨论。

Kubernetes v1.34：可变 CSI 节点可分配数进阶至 Beta

Thu, 11 Sep 2025 10:30:00 -0800

CSI 驱动更新节点上可挂接卷数量信息的这一功能在 Kubernetes v1.33 中首次以 Alpha 引入，如今在 Kubernetes v1.34 中进阶为 Beta！这是提升有状态 Pod 调度准确性的重要里程碑，可减少因可挂接卷容量信息过时所导致的调度失败问题。

背景

传统上，Kubernetes 的 CSI 驱动在初始化时会报告一个静态的最大卷挂接限制。然而，在节点的生命周期中，实际的挂接数量可能因各种原因发生变化，例如：

在 Kubernetes 控制之外的手动或外部卷挂接/解除挂接操作。
动态挂接的网络接口或专用硬件（GPU、NIC 等）消耗可用的插槽。
在多驱动场景中，一个 CSI 驱动的操作影响另一个驱动所报告的可用容量。

静态报告可能导致 Kubernetes 将 Pod 调度到看似有容量但实际上没有容量的节点上，从而导致 Pod 卡在 ContainerCreating 状态。

动态调整 CSI 卷限制

借助这一新特性，Kubernetes 允许 CSI 驱动在运行时动态调整并报告节点的卷挂接数量。这一特性可确保调度器以及依赖此信息的其他组件能够获得最准确、最新的节点容量信息。

工作原理

Kubernetes 支持两种机制来更新所报告的节点卷限制：

周期性更新： CSI 驱动指定一个时间间隔，定期刷新节点的可分配容量。
触发式更新： 当卷挂接因资源耗尽（ResourceExhausted 错误）而失败时触发立即更新。

启用特性

要使用此 Beta 特性，必须在以下组件中启用 MutableCSINodeAllocatableCount 特性门控：

kube-apiserver
kubelet

示例 CSI 驱动配置

以下是配置 CSI 驱动以启用每 60 秒周期性更新一次的示例：

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example.csi.k8s.io
spec:
  nodeAllocatableUpdatePeriodSeconds: 60

此配置指示 kubelet 每隔 60 秒调用一次 CSI 驱动的 NodeGetInfo 方法，以更新节点的可分配卷数。 Kubernetes 强制要求更新时间间隔最小为 10 秒，目的是在准确性与资源消耗间达成平衡。

挂接失败时立即更新

当卷挂接操作因 ResourceExhausted 错误（gRPC 代码 8）而失败时，Kubernetes 会立即更新可分配数量，而不是等待下一次周期性更新。随后 kubelet 会将受影响的 Pod 标记为 Failed，使其控制器能够重新创建这些 Pod。这样可以防止 Pod 永久卡在 ContainerCreating 状态。

快速入门

要在 Kubernetes v1.34 集群中启用此特性：

在 kube-apiserver 和 kubelet 组件上启用特性门控 MutableCSINodeAllocatableCount。
通过设置 nodeAllocatableUpdatePeriodSeconds，更新你的 CSI 驱动配置。
监控并观察调度准确性和 Pod 调度可靠性的提升。

下一步

此特性目前处于 Beta，Kubernetes 社区欢迎你的反馈。请测试、分享你的经验，并帮助推动其发展至 GA（正式发布）稳定版。

欢迎加入 Kubernetes SIG-Storage 参与讨论，共同塑造 Kubernetes 存储能力的未来。

Kubernetes v1.34: 使用 Init 容器定义应用环境变量

Wed, 10 Sep 2025 10:30:00 -0800

Kubernetes 通常使用 ConfigMap 和 Secret 来设置环境变量，这会引入额外的 API 调用和复杂性。例如，你需要分别管理工作负载的 Pod 和它们的配置，同时还要确保配置和工作负载 Pod 的有序更新。

另外，你可能在使用一个供应商提供的、需要环境变量（例如许可证密钥或一次性令牌）的容器，但你又不想对这些变量进行硬编码，或者仅仅为了完成工作而挂载卷。

如果你正面对这种情况，现在有一种新的（Alpha）方式来实现。只要你在集群中启用了 EnvFiles 特性门控，你就可以告诉 kubelet 从一个卷中加载容器的环境变量（此卷必须是容器所属的 Pod）。这个特性门控允许你直接从 emptyDir 卷中的文件加载环境变量，而不需要将该文件实际挂载到容器中。这是一个简单而优雅的解决方案，可以应对一些出乎意料的常见问题。

特性概述

从核心上来说，这个特性允许你将容器指向一个文件，该文件由 initContainer 生成，然后让 Kubernetes 解析该文件以设置你的环境变量。此文件位于一个 emptyDir 卷中（这是一种临时存储空间，只要 Pod 存在就会保留），你的主容器不需要挂载此卷。 kubelet 会在容器启动时读取文件并注入这些变量。

工作原理

这里有一个简单的例子：

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: generate-config
    image: busybox
    command: ['sh', '-c', 'echo "CONFIG_VAR=HELLO" > /config/config.env']
    volumeMounts:
    - name: config-volume
      mountPath: /config
  containers:
  - name: app-container
    image: gcr.io/distroless/static
    env:
    - name: CONFIG_VAR
      valueFrom:
        fileKeyRef:
          path: config.env
          volumeName: config-volume
          key: CONFIG_VAR
  volumes:
  - name: config-volume
    emptyDir: {}

使用这种方法非常简单。你在 Pod 规约中使用 fileKeyRef 字段定义环境变量，此字段告诉 Kubernetes 去哪里找到文件以及要提取哪个键。此文件本身类似于 .env 语法的标准格式（即 KEY=VALUE），并且（至少在这个 Alpha 阶段）你必须确保它被写入到一个 emptyDir 卷中。其他类型的卷在此特性中不受支持。至少有一个 Init 容器必须挂载该 emptyDir 卷（以写入文件），但主容器不需要挂载它——它在启动时就能直接获取这些变量。

关于安全性

虽然此特性支持处理密钥或令牌等敏感数据，但需要注意它的实现依赖于挂载到 Pod 的 emptyDir 卷。具有节点文件系统访问权限的操作人员因此可以通过 Pod 目录路径轻易获取这些敏感数据。

如果使用此特性存储密钥或令牌等敏感数据，确保你的集群安全策略能够有效保护节点免受未经授权的访问，以防止机密信息泄露。

总结

此特性将消除如今使用的许多复杂变通方法，简化应用编写，并为更多使用场景打开大门。 Kubernetes 保持灵活性，欢迎反馈。请告诉我们你是如何使用这个特性的，或者此特性还缺少什么。

Kubernetes v1.34: Kubernetes 中的 PSI 指标进入 Beta 阶段

Thu, 04 Sep 2025 10:30:00 -0800

随着 Kubernetes 集群规模和复杂性的增长，了解各个节点的健康状况和性能变得越来越关键。我们很高兴地宣布，从 Kubernetes v1.34 开始，压力停滞信息 (PSI) 指标已升级到 Beta 版本。

什么是压力停滞信息 (PSI)？

压力停滞信息 (PSI) 是 Linux 内核（4.20 及更高版本）的一项功能，它提供了一种规范化的方式来量化基础设施资源的压力，即资源需求是否超过当前供应。它超越了简单的资源利用率指标，而是测量任务因资源竞争而停滞的时间。这是识别和诊断可能影响应用程序性能的资源瓶颈的强大方法。

PSI 暴露了 CPU、内存和 I/O 的指标，分为 some 或 full 压力：

some: 至少一个任务在资源上停滞的时间百分比。这表明存在某种程度的资源竞争。

full: 所有非空闲任务同时在资源上停滞的时间百分比。这表明存在更严重的资源瓶颈。

PSI：'Some' 与 'Full' 压力对比

这些指标在 10 秒、1 分钟和 5 分钟的滚动窗口上进行聚合，提供了随时间变化的资源压力的全面视图。

Kubernetes 中的 PSI 指标

启用 KubeletPSI 特性门控后，kubelet 现在可以从 Linux 内核收集 PSI 指标，并通过两个渠道暴露它们：Summary API 和 /metrics/cadvisor Prometheus 端点。这允许你在节点、Pod 和容器级别监控和告警资源压力。

以下新指标可通过 /metrics/cadvisor 以 Prometheus 暴露格式获得：

container_pressure_cpu_stalled_seconds_total
container_pressure_cpu_waiting_seconds_total
container_pressure_memory_stalled_seconds_total
container_pressure_memory_waiting_seconds_total
container_pressure_io_stalled_seconds_total
container_pressure_io_waiting_seconds_total

这些指标与 Summary API 的数据一起，提供了资源压力的细粒度视图，使你能够精确定位性能问题的根源并采取纠正措施。例如，你可以使用这些指标来：

识别内存泄漏： 内存的 some 压力持续增加可能表明应用程序中存在内存泄漏。

优化资源请求和限制： 通过了解你的工作负载的资源压力，你可以更准确地调整其资源请求和限制。

自动扩缩容工作负载： 你可以使用 PSI 指标触发自动扩缩容事件，确保你的工作负载拥有最佳性能所需的资源。

如何启用 PSI 指标

要在你的 Kubernetes 集群中启用 PSI 指标，你需要：

确保你的节点运行 Linux 内核版本 4.20 或更高版本，并使用 cgroup v2。

在 kubelet 上启用 KubeletPSI 特性门控。

启用后，你可以开始使用 Prometheus 兼容的监控解决方案抓取 /metrics/cadvisor 端点，或查询 Summary API 来收集和可视化新的 PSI 指标。请注意，PSI 是 Linux 内核功能，因此这些指标在 Windows 节点上不可用。你的集群可以包含 Linux 和 Windows 节点的混合，在 Windows 节点上，kubelet 不会暴露 PSI 指标。

接下来是什么？

我们很高兴为 Kubernetes 社区带来 PSI 指标，并期待你的反馈。作为 Beta 功能，我们正在积极改进和扩展此功能，以实现稳定的 GA 发布。我们鼓励你试用并与我们分享你的经验。

要了解有关 PSI 指标的更多信息，请查看官方 Kubernetes 文档。你还可以参与 #sig-node Slack 频道的对话。

Kubernetes Blog

从 Kubernetes Dashboard 到 Headlamp：理解过渡

Kubernetes Dashboard 工作负载映射到 Headlamp

查看工作负载和资源

编辑和与资源交互

理解关系

Headlamp 超越 Kubernetes Dashboard 的地方

从单集群扩展到多集群工作流程

通过 Projects 从资源列表到应用上下文

使用插件扩展 Headlamp UI

构建自己的插件

选择 Headlamp 的运行方式和位置

准备迁移

回顾既往：为未修复的 Kubernetes CVE 纠正记录

为什么我们现在更新这些记录

未修复架构风险的技术分析

CVE-2020-8561：kube-apiserver 中的 Webhook 重定向

CVE-2020-8562：通过 DNS TOCTOU 绕过代理

CVE-2021-25740：通过 Endpoints 的跨名字空间转发

说明：

管理员需要采取的操作

结语：通过透明度走向成熟

Kubernetes v1.36：云控制器管理器中的路由同步新指标

基于监视的路由调谐的 A/B 测试

示例：预期行为

我在哪里可以提供反馈？

我如何了解更多？

Kubernetes v1.36：混合版本代理升级到 Beta

我们正在解决什么问题？

自 1.28 以来的发展

必需的配置

使用 kubeadm 配置

行动号召

Kubernetes v1.36：Service ExternalIPs 的弃用和移除

关于术语的说明，以及未被弃用的内容

externalIPs 的替代方案

使用手动管理的 LoadBalancer Service 代替 externalIPs

使用非云负载均衡器控制器

使用 Gateway API

externalIPs 弃用时间表

Kubernetes v1.36：工作负载感知调度再进一步

Workload 和 PodGroup API 更新

PodGroup 调度周期和编组调度

局限性

拓扑感知调度

工作负载感知抢占

工作负载的 DRA ResourceClaim 支持

与 Job 控制器集成

什么时候会触发集成？

尚未覆盖的内容

后续计划

入门

了解更多

Kubernetes v1.36：Kubernetes PSI 指标升级到 GA

超越利用率：为什么选择 PSI？

证明稳定性：大规模性能测试

场景 1：kubelet 开销

（案例 1）kubelet CPU 使用率对比

（案例 1）系统 CPU 使用率对比

场景 2：内核开销

（案例 2）节点系统 CPU 使用率对比

（案例 2）kubelet CPU 使用率对比

Beta（1.34）到 Stable（1.36）之间的改进

入门指南

进一步阅读

致谢

反馈

Kubernetes v1.36：卷组快照进入正式发布阶段

卷组快照概述

为什么要在 Kubernetes 中添加卷组快照？

Kubernetes 卷组快照 API

正式发布中的新内容

如何使用 Kubernetes 卷组快照

使用 Kubernetes 创建新的组快照

如何使用组快照进行恢复

作为存储供应商，如何添加组快照支持？

如何了解更多信息？

如何参与？

Kubernetes v1.36：更多驱动程序、新特性以及下一代 DRA

特性进阶

使用 `kubeadm` 配置

`externalIPs` 的替代方案

使用手动管理的 LoadBalancer Service 代替 `externalIPs`

`externalIPs` 弃用时间表

引入 `validation-gen`

一套全面的 `+k8s:` 标签

使用 `kube-api-linter` 扩展 API 审查

1. 紧密耦合的数据库（拓扑管理器的 `pod` 作用域）

2. 带基础设施边车的 ML 工作负载（拓扑管理器的 `container` 作用域）

资源继承和 `resizePolicy`

使用 `memoryReservationPolicy` 选择性启用内存预留

动机：`nodes/proxy` 问题