Kubernetes

2026-07-14 04:00

Kubernetes 已经悄然成为 AI 和机器学习的默认平台。 无论你是为数据科学家运行 Notebook 服务器、调度分布式训练作业、调优超参数， 还是编排多步骤 ML 流水线，这些工作负载越来越多地运行在 Kubernetes 集群上。 Kubeflow 是组装该堆栈最流行的方式之一，它以 Kubernetes 原生方式实现：每个功能都作为自定义资源定义（CRD）暴露。 这种设计对集群管理员来说是一个礼物，因为这意味着 ML 工作负载可以使用与集群中其他所有东西相同的原语进行观察和管理。 但实际上，这些平台附带的专业 ML 仪表板隐藏了底层的 Kubernetes 层。 当 Notebook 卡住或训练运行失败时，管理员通常不得不回到 kubectl 来找出 Pod 级别实际发生了什么。 本文介绍了 Headlamp Kubeflow 插件，它通过在通用 Kubernetes UI 中直接展示 Kubeflow 的自定义资源来弥合这一问题。 这是任何 CRD 密集型平台都可以遵循的模式的一个实例：在管理员已经工作的地方与他们会面，并向他们展示集群级别的真相。 Headlamp 本

Kubernetes

2026-07-14 02:00

1. 开始之前：了解变化内容 Kubernetes Dashboard 和 Headlamp 都显示集群中运行的内容，但它们的工作方式不同。 当 Headlamp 在桌面上运行时，它使用你现有的 kubeconfig 连接到一个或多个集群， 并可以通过插件进行扩展。当 Headlamp 在集群内运行时，它使用 Kubernetes ServiceAccount 来访问 API 并遵循 RBAC 规则。相比之下，Kubernetes Dashboard 仅在集群内运行， 并且始终依赖服务账号令牌。尽早了解这些模型有助于你选择正确的设置和权限。 1.1 Kubernetes Dashboard 的工作方式 Dashboard 是一个在你的集群内部运行的 Web 应用。 你在集群中安装它，通常使用 Helm。 通常每个集群运行一个 Dashboard。 你通常通过 kubectl port-forward 或 ingress 访问它。 你使用 Bearer 令牌登录，该令牌通常来自服务账号。 它包含帮助你创建资源的表单。 它依靠表格和列表进行导航。 感觉就像这样：一个与集群共存的 UI。 1

Kubernetes

2026-07-08 20:00

本文是原始公告的镜像版本的中文翻译 今天，SIG etcd 发布了 etcd v3.7.0， 这是广受欢迎的分布式键值存储和核心 Kubernetes 组件的最新次要版本。 v3.7 包含了期待已久的 RangeStream 功能，提供了多项其他性能改进， 移除了遗留 v2store 的最后残余，并完成了一次重大的 protobuf 重构。 你可以在这里下载 etcd v3.7.0： 源代码 二进制文件 官方容器镜像 此版本还包括两个核心 etcd 依赖项的新版本： bbolt v1.5.0 和 raft v3.7.0。 有关安装 etcd 的说明，请参阅安装文档。 有关完整的更改列表，请参阅 etcd v3.7 变更日志。 衷心感谢所有促成此次发布的贡献者！ 主要功能 v3.7.0 中的最重要变化包括： RangeStream — 分块流式传输大型结果集，而不是缓冲整个响应。 仅限键（Keys-only）的范围请求，更快、更可靠的租约机制，以及其他多项性能改进。 etcd 现在完全从 v3store 启动，消除了对遗留 v2 store 的长期依赖 已完成的 protobuf 重构，

Kubernetes

2026-06-27 02:00

AI 确实改变了软件开发的格局。 比以往任何时候都更多的人利用 AI 为他们使用的项目贡献补丁。 对我来说，这是一件好事，因为更多人会贡献补丁而不是分叉项目或不修复问题。 主要问题是，AI 使代码生成变得快速，但在维护代码库方面几乎没有改进。 在本文中，我们将重点介绍 Kubernetes 社区如何适应 AI 辅助编码的世界。 这一旅程的第一步是制定 AI 政策。这看似平凡且官僚，但有许多 PR 陷入了关于 AI 使用的讨论。 AI 政策有助于引导围绕项目对 AI 立场的讨论，并为贡献者提供明确的信号，指导他们如何负责任地使用这些工具。 Kubernetes AI 政策 Kubernetes 项目已制定 AI 辅助贡献的明确指南， 在创新与问责之间取得平衡。 这些政策旨在保持代码质量并确保人工监督，同时承认 AI 工具可以成为开发过程中有价值的辅助手段。 透明为先 贡献者必须披露何时使用 AI 工具协助创建 Pull Request。 在 PR 描述中简单声明如 "This PR was written in part with the assistance of generative

Kubernetes

2026-06-26 04:00

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 插件：

Kubernetes

2026-06-25 02:00

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

Kubernetes

2026-06-15 08:00

在持续推出的 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

2026-06-02 02:00

对许多人来说，Kubernetes Dashboard 是他们了解 Kubernetes 的第一个窗口。 它提供了一种简单的可视化方式来查看集群中运行的内容、检查资源，并在不依赖命令行的情况下建立信心。 多年来，它帮助开发者、学生和运维人员理解 Kubernetes，并作为进入生态系统的重要入口。 Kubernetes Dashboard 项目现已归档。 我们深深尊重该团队所做的工作，以及 Dashboard 在让如此多用户更容易接触 Kubernetes 方面所发挥的作用。 Headlamp 在此基础上构建并向前发展。 它保持了可视化界面的清晰性，同时添加了与当今 Kubernetes 使用方式相匹配的功能。 这包括多集群可见性、以应用为中心的视图、通过插件实现的可扩展性，以及在集群内和桌面上都能工作的灵活部署选项。 本指南旨在帮助你自信地完成这一过渡。 在深入探讨迁移机制之前，我们从熟悉的内容开始， 看看常见的 Kubernetes Dashboard 工作流程如何映射到 Headlamp。 我们还将介绍切换后保持不变的内容和改进的内容。 我们的目标不仅是替换工具，更是为了尊重以用

Kubernetes

2026-05-27 01:30

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 功能的情况下通过代码完全修复。 纠正这些记录对社区至关重要，原因如下

Kubernetes

2026-05-20 08:00

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