Volcano 是 Kubernetes 的云原生批处理调度器，专为高性能计算、AI/ML 和其他批处理工作负载而构建。 Headlamp 是一个可扩展的 Kubernetes Web UI。 通过其插件系统，Headlamp 可以展示内置 Kubernetes 资源之外的 API 和工作流。 Volcano 插件将核心 Volcano 资源引入 Headlamp，让你可以在一个地方检查工作负载状态、队列行为和组调度详情。 Kubernetes 最初围绕长期运行的服务设计，应用被期望启动后持续保持可用。 批处理、AI/ML 和 HPC 工作负载通常表现不同：作业动态到达，争夺有限资源，可能需要多个工作节点同时启动才能开始有效工作。 Volcano 通过队列、优先级、配额和组调度等概念扩展了 Kubernetes。 Volcano 不再独立对待每个 Pod，而是以感知整个作业及其所需资源的方式来调度工作负载。 为了使这些工作负载更易于操作和故障排查，Volcano 插件将调度上下文直接引入 Headlamp。 观看这段简短的演示视频，了解 Headlamp 中的 Volcano 插件：
AI、边缘计算和电信工作负载在 Kubernetes 上日益普及，对硬件管理提出了新的需求。 我们现在需要的硬件规格已经超出了 CPU 时间和内存分配的范畴。 这包括分配 GPU、TPU、网络接口和其他硬件，有时在 Pod 启动之后分配，有时通过分时共享。 高效管理这些专用硬件是 Device Management 工作组 的使命。他们的核心项目 动态资源分配（DRA） 最近已正式 GA，标志着该项目在大规模处理硬件密集型工作负载方面的根本性转变。 在本期聚焦中，我们与工作组主席 Kevin Klues、Patrick Ohly 和 John Belamaric 坐下来讨论了传统设备模型的局限性、 调度中的 NP 难 挑战，以及他们如何为 Kubernetes 构建一个更可编程、更具硬件感知能力的未来。 介绍 Device Management Natalie Fisher：能否介绍一下你自己、你的角色，以及你是如何参与 Device Management 工作组的？ Kevin Klues： 我叫 Kevin Klues，是 NVIDIA 的杰出工程师。 自 2024 年 KubeC
在持续推出的 SIG 聚焦系列中，我们会介绍推动 Kubernetes 项目不断向前发展的各个团队。 这一次，我们采访了 SIG Storage， 该团队负责持久化数据、卷管理， 以及将 Kubernetes 工作负载与其底层存储系统连接起来的接口。 我们采访了 SIG Storage 联合主席、VMware by Broadcom 软件工程师 Xing Yang，聊了聊这个 SIG 的历史、近期 Kubernetes 版本中发布的功能，以及随着 AI 工作负载成为常态，Kubernetes 中的存储将走向何方。 介绍 你能介绍一下自己，并分享你在 SIG Storage 中承担的角色吗？ 我叫 Xing Yang，是 VMware by Broadcom 的软件工程师。 我是 SIG Storage 的联合主席，另一位联合主席是来自 Google 的 Saad Ali。SIG Storage 还有两位技术负责人： 来自 Google 的 Michelle Au 和来自 Red Hat 的 Jan Šafránek。 最初是什么吸引你关注 Kubernetes 中的存储？你又是如何开始
对许多人来说，Kubernetes Dashboard 是他们了解 Kubernetes 的第一个窗口。 它提供了一种简单的可视化方式来查看集群中运行的内容、检查资源，并在不依赖命令行的情况下建立信心。 多年来，它帮助开发者、学生和运维人员理解 Kubernetes，并作为进入生态系统的重要入口。 Kubernetes Dashboard 项目现已归档。 我们深深尊重该团队所做的工作，以及 Dashboard 在让如此多用户更容易接触 Kubernetes 方面所发挥的作用。 Headlamp 在此基础上构建并向前发展。 它保持了可视化界面的清晰性，同时添加了与当今 Kubernetes 使用方式相匹配的功能。 这包括多集群可见性、以应用为中心的视图、通过插件实现的可扩展性，以及在集群内和桌面上都能工作的灵活部署选项。 本指南旨在帮助你自信地完成这一过渡。 在深入探讨迁移机制之前，我们从熟悉的内容开始， 看看常见的 Kubernetes Dashboard 工作流程如何映射到 Headlamp。 我们还将介绍切换后保持不变的内容和改进的内容。 我们的目标不仅是替换工具，更是为了尊重以用
Kubernetes 项目依赖透明性来赋能集群管理员和安全研究人员。 我们做到这一点的一个重要方式是将 CVE 记录发布到常见漏洞和风险数据库。 作为我们持续完善官方 Kubernetes CVE 信息源 努力的一部分，我们发现了一些差异。一些较旧的、未修复问题的 CVE 记录错误地包含了 fixed version 字段。 Kubernetes 安全响应委员会（SRC）将于 2026 年 6 月 1 日纠正受影响的 CVE 记录。 这可能导致漏洞扫描器在以前未检测到的地方识别这些漏洞。 为帮助减少混淆，本文提供了多年前披露但仍未修复的三个漏洞的技术更新： CVE-2020-8561、CVE-2020-8562 和 CVE-2021-25740。 为什么我们现在更新这些记录 虽然这些漏洞已经公开多年，但最近生成官方开源漏洞（OSV）文件的工作表明， 它们相应的 CVE 记录并未准确反映其状态。 具体来说，一些记录表明存在 fixed 版本，而实际上， 这些问题是架构设计上的权衡，无法在不破坏基本 Kubernetes 功能的情况下通过代码完全修复。 纠正这些记录对社区至关重要，原因如下
SIG-Etcd 宣布 etcd v3.7.0 的第一个 Beta 版本已发布。 这个广受欢迎的分布式数据库和 Kubernetes 关键组件的新版本包含了期待已久的 RangeStream 功能， 以及对多个遗留组件和接口的重构和清理。 v3.7 将提供改进的安全性、更好的操作可靠性以及处理大型结果集的改进体验。 不过，首先项目需要用户测试这个 Beta 版本。你可以在这里找到 v3.7.0-beta.0： 源代码 二进制文件 官方容器镜像 请试用并在 etcd 仓库中报告问题。 此 Beta 版本还确定了 3.4 版本的 EOL（生命周期结束）。 RangeStream 在 etcd v3.6 及更早版本中，处理返回大型结果集的请求具有挑战性。 客户端或请求应用程序被迫等待完整的结果集，导致不可预测的延迟和内存使用。 RangeStream RPC 允许调用应用程序分块接受结果集，减少延迟并使缓冲内存使用更加可预测。 RangeStream 的大部分工作是由 etcd 的一位相对较新的贡献者 Jeffrey Ying（Google 的软件工程师）完成的。 新贡献者可以对 etcd
本文最初发布时日期有误。后来重新发布，日期为 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。 在节点变化不频繁的集群中，开启特性门控后，你应该会看到同步速率
早在 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 版本）， 该服务器会
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 中删除该行为的实现， 并更新 Kube
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
