Kubernetes

2026-09-04 02:30

Kubernetes 1.37 现已发布， 动态资源分配（DRA） 也在不断突破最初的边界！ 此版本中，DRA 扩展资源支持正式进入 GA；这是团队连续三个版本努力达成的重要里程碑。 此外还有多项特性进阶至 Beta 或 GA，以及一批全新的 Alpha 特性，共同构成了本次更新。 下面我们来深入了解 Kubernetes 1.37 中 DRA 的新变化！ v1.37 中的稳定特性 DRA 扩展资源支持已进阶至 GA。 借助此机制，DRA 驱动无需再搭配单独的设备插件， 即可满足通过传统扩展资源 API 发出的请求，例如 Pod 规约中的 example.com/gpu。 集群管理员可以直接在 DeviceClass 上设置扩展资源名称。 请求该扩展资源的 Pod 将通过 DRA 获得设备，工作负载侧无需显式声明或引用 ResourceClaim。 自该 KEP 在 1.34 中获批以来，这项特性一直稳步推进： 1.35 中进入 Alpha，1.36 中进入 Beta，如今已经稳定。 这让集群运维人员可以逐步采用 DRA： 在后端分配逻辑迁移到 DRA 的同时，基于扩展资源编写的现有工

Kubernetes

2026-08-28 02:30

在 Kubernetes v1.37 中，metrics.k8s.io API 正式进入稳定阶段，版本为 v1。 该 API 提供节点和 Pod 的 CPU 和内存用量数据，供 kubectl top 等命令以及基于资源指标的自动扩缩容使用。 对集群运维人员和应用开发者而言，这意味着 Kubernetes 对稳定版 API 的稳定性承诺现在也适用于该 API。v1 与 v1beta1 的资源类型和字段完全相同；此次变更只涉及 API 版本的稳定级别，并未改变所收集或返回的指标。 沿用多年的 API 进入稳定阶段 资源指标 API 在 Kubernetes v1.6 中以 Alpha 状态引入，并在 v1.8 进入 Beta 阶段。 此后，该 API 的定义一直未变，并已在生产环境中使用多年； HorizontalPodAutoscaler（HPA）控制器和 kubectl top 等客户端都依赖该 API。 经过多年生产环境验证后，该 API 在 Kubernetes v1.37 中正式进入稳定阶段（metrics.k8s.io/v1）。 该 API 提供以下两种资源类型： NodeM

Kubernetes

2026-08-26 08:00

编辑：Arsh Sharma、Christopher Tineo、Kirti Goyal、Sophia Ugochukwu、Swathi Rao、Troy Connor 与之前的版本类似，Kubernetes v1.37 的发布引入了新的稳定（GA）、 Beta 和 Alpha 特性。持续交付高质量版本，彰显了我们开发周期的韧性与社区蓬勃的支持。 此版本包含 67 项增强。其中，16 项已进阶至稳定阶段，23 项已进阶至 Beta 阶段， 27 项进入 Alpha 阶段，另有 1 项弃用或移除。 发布主题与徽标 Kubernetes v1.37 的主题是 Garhwal_（गढ़वाल，发音为 gaṛhvāl）， 这是印度北阿坎德邦的一个喜马拉雅山区。 Garhwal 喜马拉雅山脉的雪峰、喜马拉雅雪松林、梯田、河流与溪流，以及山间小径， 共同塑造了这片地区与该徽标。 这些元素一同映照出这样一个社区：每一层、每一条路径和每一份贡献都彼此相连。 该徽标被构想为一扇望向 Garhwal 风光的窗户。1 窗内，层层梯田向雪峰攀升，每一级都由下方的一级承托， 正如每个 Kubernetes 版本

Kubernetes

2026-08-04 00:00

Kubernetes SIG Network 社区欣然宣布 Gateway API v1.6.0 发布！该版本已于今年 6 月 30 日发布。 Gateway API 已成为 Kubernetes 中现代化、面向角色且表达力强的服务网络标准。 在之前的版本中，Gateway API 已为 HTTP 和 TLS 第 7 层流量建立了生产级基础。 在 1.6.0 版本中，Gateway API 通过扩展标准的第 4 层协议路由，并为实验性创新引入更清晰的 API 边界，迈出了重要一步。 以下是 Gateway API v1.6.0 新特性的快速概览： TCPRoute 和 UDPRoute 进阶为标准版：原始 L4 TCP 和 UDP 流量路由在 v1 API 版本中达到 GA 稳定级别。 实验性 API 组分离：实验性资源迁移至独立的 API 组（gateway.networking.x-k8s.io）， 并添加 X 前缀，使实验性与标准 API 的边界一目了然。 下面让我们深入了解详情！ TCPRoute 和 UDPRoute 进阶为标准版 负责人：Nick Young、Ricardo

Kubernetes

2026-08-01 00:00

随着 Kubernetes v1.37 发布日期的临近，项目不断发展和成熟， 为了项目的整体健康，某些特性可能会被弃用、移除或被更好的特性替代。 本文概述了 Kubernetes v1.37 版本中的一些计划内变更， 发布团队认为你应该了解这些变更，以便持续维护你的 Kubernetes 环境， 并跟上最新的变化。以下信息反映了 v1.37 版本的当前状态， 在实际发布日期之前可能会发生变化。 Kubernetes v1.37 的弃用和移除 kubectl：kubectl run --filename/-f 将被弃用 kubectl run 的 --filename（或 -f）参数将被弃用， 因为生成的 Pod 始终纯粹由 NAME 和 --image 等 CLI 参数构建。 原始 Issue 和讨论请参见 kubernetes/kubernetes#138671。 kubelet：静态 Pod 不再能引用 Secret 或 ConfigMap 静态 Pod 从未打算直接读取 API 资源，因为它们不是通过 API 服务器创建的 —— 但一个缺陷曾允许它们通过 configMapRef

Kubernetes

2026-07-15 02:00

Kubernetes 内置了对 CPU 和内存的感知能力，但大多数实际的扩缩容决策所依赖的信号完全超出了这个范围： 队列中有多少消息在等待、上一个批处理作业花费了多长时间、Pod 持有多少个活跃的 WebSocket 连接。 当内置指标不够用时，指标导出器（metrics exporter） 可以填补这一空白。 本文将从头开始编写一个指标导出器，将其打包为容器，并将其接入集群，以便 Prometheus —— 最终是 HorizontalPodAutoscaler —— 能够消费这些指标。 指标导出器实际上做什么 导出器是一个小型 HTTP 服务器，只有一个职责：将应用状态以文本形式暴露在 /metrics 端点上。 Prometheus 定期抓取该端点，存储时间序列数据，并使其可用于查询、告警和自动扩缩容规则。 在某些情况下，你可以直接在应用中添加监控 —— 嵌入 Prometheus 客户端库并从同一进程中暴露 /metrics —— 而不是运行单独的导出器。 当数据源位于应用外部或你无法控制应用代码时，独立的导出器更有意义。 Prometheus 期望的格式是纯文本 —— 每行一

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