Kubernetes Blog

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 的未来发展方向。

Kubernetes v1.35：云控制器管理器中的基于监视的路由协调

Thu, 08 Jan 2026 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: 通过就地重启 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 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 网站上的活动页面。

参与其中

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

在 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，你将为自己节省数小时的调试时间。

最好的部分是什么？清晰的配置保持可读性。即使在几个月后，你或团队中的任何人都可以瞥一眼它们并确切知道发生了什么。

Kubernetes 1.35：版本化 z-pages API 带来更强大的调试能力

Thu, 13 Nov 2025 00:00:00 +0000

调试 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 中找到我们，或参加常规的社区会议。

祝你调试愉快！

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 社区的故事，请了解有关我们的更多信息。

Kubernetes v1.35：云控制器管理器中的基于 Watch 的路由协调

Mon, 27 Oct 2025 08:30:00 -0700

截至 Kubernetes v1.34，使用 k8s.io/cloud-provider 库构建的云控制器管理器（CCM）实现中的路由控制器以固定间隔协调路由。这在路由没有变化时导致了不必要的 API 请求。通过相同库实现的其他控制器已经使用基于 Watch 的机制，利用 Informer 来避免不必要的 API 调用。在 v1.35 中，引入了一个新的特性门控，允许更改路由控制器的行为以使用基于 Watch 的 Informer。

新的变化

CloudControllerManagerWatchBasedRoutesReconciliation 特性门控已由 SIG Cloud Provider 在 k8s.io/cloud-provider 中作为 Alpha 级别特性引入。要启用此特性，你可以在使用的 CCM 实现中使用 --feature-gate=CloudControllerManagerWatchBasedRoutesReconciliation=true 标志。

关于特性门控

此特性门控将在节点被添加、删除或字段 .spec.podCIDRs 或 .status.addresses 被更新时，触发路由协调循环。

另外，在控制器启动时会随机选择一个 12 到 24 小时之间的间隔进行额外的协调。

此特性门控不会修改协调循环内的逻辑。因此，CCM 实现的用户不应体验到对其现有路由配置的重大变更。

了解更多

欲获取更多详情，请参阅 KEP-5237。

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 中的 PSI 指标进入 Beta 阶段

Fri, 08 Aug 2025 00:00:00 +0000

随着 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 频道的对话。

Headlamp AI 助手简介

Thu, 07 Aug 2025 20:00:00 +0100

本文是 Headlamp AI 助手介绍这篇博客的中文译稿。

为了简化 Kubernetes 的管理和故障排除，我们非常高兴地推出 Headlamp AI 助手：这是 Headlamp 的一个强大的新插件，可以帮助你更清晰、更轻松地理解和操作你的 Kubernetes 集群和应用程序。

无论你是经验丰富的工程师还是初学者，AI 助手都能提供：

快速实现价值：无需深入了解 Kubernetes 知识即可提出问题，例如 “我的应用程序健康吗？” 或 “我如何修复这个问题？”
深入洞察：从高层次查询开始，并通过提示深入挖掘，如 “列出所有有问题的 Pod” 或者 “我如何修复这个 Pod？”
专注且相关：根据你在 UI 中查看的内容提问，比如 “这里有什么问题？”
面向行动：让 AI 在获得你的许可后为你采取行动，例如 “重启那个部署”。

在这里，我们展示 AI 助手在 Kubernetes 集群中处理应用程序问题时的工作方式：

以下是 AI 助手帮助排查 Kubernetes 集群中运行有问题的应用程序的演示：

搭上 AI 列车

大型语言模型（LLM）不仅改变了我们访问数据的方式，也改变了我们与其交互的方式。像 ChatGPT 这样的工具的兴起开启了一个充满可能性的世界，激发了一波新的应用浪潮。用自然语言提问或给出命令是直观的，特别是对于非技术用户而言。现在每个人都可以快速询问如何做 X 或 Y，而不会感到尴尬，也不必像以前那样遍历一页又一页的文档。

因此，Headlamp AI Assistant 将对话式 UI 带入 Headlamp，由 LLM 驱动，Headlamp 用户可以使用自己的 API 密钥进行配置。它作为一个 Headlamp 插件提供，易于集成到你的现有设置中。用户可以通过安装插件并用自己的 LLM API 密钥进行配置来启用它，这使他们能够控制哪个模型为助手提供动力。一旦启用，助手就会成为 Headlamp UI 的一部分，准备好响应上下文查询，并直接从界面执行操作。

上下文就是一切

正如预期的那样，AI 助手专注于帮助用户理解 Kubernetes 概念。然而，尽管从 Headlamp 的 UI 回答与 Kubernetes 相关的问题有很多价值，但我们认为这种集成的最大好处在于它能够使用用户在应用程序中体验到的上下文信息。因此，Headlamp AI 助手知道你当前在 Headlamp 中查看的内容，这让交互感觉更像是在与人类助手一起工作。

例如，如果一个 Pod 出现故障，用户只需问 “这里出了什么问题？”， AI 助手就会回答根本原因，如缺少环境变量或镜像名称中的拼写错误。后续的问题如 “我该如何修复？” 能让 AI 助手建议一个解决方案，将原本需要多个步骤的过程简化为快速的对话流。

然而，从 Headlamp 共享上下文并非易事，因此这是我们将会继续努力完善的工作。

工具

UI 中的上下文很有帮助，但有时还需要额外的功能。如果用户正在查看 Pod 列表并想要识别有问题的 Deployment，切换视图不应是必要的。为此，AI 助手包含了对 Kubernetes 工具的支持。这允许提出诸如 “获取所有有问题的 Deployment” 的问题，促使助手从当前集群中获取并显示相关数据。同样，如果用户在 AI 指出哪个部署需要重启后请求执行类似 “重启那个 Deployment” 的操作，它也可以做到。对于写操作，AI 助手确实会向用户检查是否获得运行权限。

AI 插件

尽管 AI 助手的初始版本已经对 Kubernetes 用户很有用，但未来的迭代将进一步扩展其功能。目前，助手仅支持 Kubernetes 工具，但与 Headlamp 插件的进一步集成正在进行中。类似于，通过 Flux 插件我们可以获得更丰富的 GitOps 见解、通过 Prometheus 进行监控、使用 Helm 进行包管理等。

随着 MCP 的流行度增长，我们也在研究如何以更即插即用的方式集成它。

试用一下！

我们希望 AI 助手的第一个版本能够帮助用户更有效地管理 Kubernetes 集群，并帮助新用户应对学习曲线。我们邀请你试用这个早期版本，并向我们提供反馈。 AI 助手插件可以从桌面版的 Headlamp 插件目录中安装，或者在部署 Headlamp 时使用容器镜像安装。敬请期待 Headlamp AI 助手的未来版本！

Kubernetes v1.34 抢先一览

Mon, 28 Jul 2025 00:00:00 +0000

Kubernetes v1.34 将于 2025 年 8 月底发布。本次发版不会移除或弃用任何特性，但包含了数量惊人的增强特性。以下列出一些本次发版最令人兴奋的特性！

请注意，以下内容反映的是 v1.34 当前的开发状态，发布前可能会发生变更。

Kubernetes v1.34 的重点增强特性

以下列出了一些可能会包含在 v1.34 版本中的重要增强特性，但这并不是所有计划更改的详尽列表。这并不构成承诺，发布内容可能会发生变更。

DRA 核心功能趋向稳定

动态资源分配（DRA）提供了一种灵活的方式来分类、请求和使用集群中的 GPU 或定制硬件等设备。

自 v1.30 版本起，DRA 已基于结构化参数来申领设备，这些参数对于 Kubernetes 核心是不可见的。相关增强提案 KEP-4381 借鉴了存储卷动态制备的思路。使用结构化参数的 DRA 依赖一组辅助 API 类别：包括 resource.k8s.io 下的 ResourceClaim、DeviceClass、ResourceClaimTemplate 和 ResourceSlice，还在 Pod 的 .spec 中新增了 resourceClaims 字段。 DRA 的核心功能计划在 Kubernetes v1.34 中进阶至稳定阶段。

借助 DRA，设备驱动和集群管理员定义可用的设备类。工作负载可以在设备请求中从设备类申领设备。 Kubernetes 为每个申领分配匹配的设备，并将相关 Pod 安排到可访问所分配设备的节点上。这种框架提供了使用 CEL 的灵活设备筛选、集中式设备分类和简化的 Pod 请求等优点。

一旦此特性进入稳定阶段，resource.k8s.io/v1 API 将默认可用。

使用 ServiceAccount 令牌进行镜像拉取身份认证

ServiceAccount 令牌与 kubelet 凭据提供程序集成的特性预计将在 Kubernetes v1.34 中进入 Beta 阶段并默认启用。这将允许 kubelet 在从需要身份认证的镜像仓库中拉取容器镜像时使用这些令牌。

此特性已作为 Alpha 存在，并由 KEP-4412 跟踪。

现有的 Alpha 集成允许 kubelet 使用生命期短、自动轮换的 ServiceAccount 令牌（符合 OIDC 标准）来向容器镜像仓库进行身份认证。每个令牌与一个 Pod 相关联；整个机制可替代长期存在的镜像拉取 Secret。

采用这一新方式可以降低安全风险、支持工作负载级身份，并减少运维负担。它让镜像拉取认证更加贴合现代、具备身份感知的最佳实践。

Deployment 的 Pod 替换策略

对 Deployment 做出变更后，终止中的 Pod 可能会保留较长时间，并消耗额外资源。作为 KEP-3973 的一部分，.spec.podReplacementPolicy 字段将以 Alpha 形式引入到 Deployment 中。

如果你的集群启用了此特性，你可以选择以下两种策略之一：

TerminationStarted: 一旦旧 Pod 开始终止，立即创建新 Pod，带来更快的上线速度，但资源消耗可能更高。
TerminationComplete: 等待旧 Pod 完全终止后才创建新 Pod，上线速度较慢，但资源消耗控制更好。

此特性通过让你选择更新或扩缩容期间何时创建新 Pod，从而使 Deployment 行为更可控。在资源受限的集群或终止时间较长的工作负载中尤为有用。

预计此特性将作为 Alpha 特性推出，并可通过在 API 服务器和 kube-controller-manager 中启用 DeploymentPodReplacementPolicy 和 DeploymentReplicaSetTerminatingReplicas 特性门控启用。

kubelet 和 API 服务器的生产级追踪特性

为了解决通过日志关联进行节点级调试的长期难题， KEP-2831 为 kubelet 提供了深度上下文可视化能力。

此特性使用供应商中立的 OpenTelemetry 标准，为关键的 kubelet 操作（特别是其对容器运行时接口的 gRPC 调用）做了插桩。它使运维人员能够可视化整个事件生命周期（例如：Pod 启动）以定位延迟或错误来源。其强大之处在于传播链路上下文：kubelet 在向容器运行时发送请求时附带链路 ID，使运行时能够链接自身的 Span。

这一工作得到了另一个增强提案 KEP-647 的配合，后者为 Kubernetes API 服务器引入了相同的链路追踪能力。两者结合提供了从控制面到节点的端到端事件视图，极大简化了定位延迟和错误的过程。这些特性已在 Kubernetes 正式版本发布流程中逐渐成熟：
KEP-2831 在 v1.25 中以 Alpha 发布， KEP-647 在 v1.22 中首次作为 Alpha 发布，这两个特性在 v1.27 中一起进阶至 Beta。展望未来，kubelet 追踪（KEP-2831）和 API 服务器追踪（KEP-647）计划在 v1.34 中进入稳定阶段。

Service 的 `PreferSameZone` 和 `PreferSameNode` 流量分发

Kubernetes Service 的 spec.trafficDistribution 字段允许用户表达服务端点的流量路由偏好。

KEP-3015 弃用了 PreferClose，并引入了两个新值：PreferSameZone 和 PreferSameNode。 PreferSameZone 等价于当前的 PreferClose；
PreferSameNode 优先将流量发送至与客户端位于同一节点的端点。

此特性在 v1.33 中引入，受 PreferSameTrafficDistribution 特性门控控制。 v1.34 中此特性预计将进入 Beta，并默认启用。

支持 KYAML：Kubernetes 的 YAML 方言

KYAML 是为 Kubernetes 设计的更安全、更少歧义的 YAML 子集。无论你使用哪个版本的 Kubernetes，都可以使用 KYAML 编写清单和 Helm 模板。你可以编写 KYAML 并将其作为输入传递给任意版本的 kubectl，因为所有 KYAML 文件都是合法的 YAML。在 kubectl v1.34 中，你还可以请求以 KYAML 格式输出（如：kubectl get -o kyaml …）。当然，如果你愿意，也可以继续使用 JSON 或 YAML 格式输出。

KYAML 解决了 YAML 和 JSON 的一些具体问题：
YAML 对缩进的敏感性需要你注意空格和嵌套，而其可选的字符串引号可能导致意外类型转换（参见 “挪威 bug”）。与此同时，JSON 不支持注释，且对尾逗号和键的引号有严格要求。

KEP-5295 引入了 KYAML，尝试解决这些主要问题：

所有值字符串始终使用英文双引号
键不加英文引号，除非可能产生歧义
所有映射使用 {} 表示（即关联数组）
所有列表使用 [] 表示

这听起来像 JSON？确实如此！但与 JSON 不同的是，KYAML 支持注释、允许尾逗号，且不强制键加引号。

我们希望在 kubectl v1.34 中将 KYAML 引入为一种新的输出格式。如同其他特性一样，这些变更尚未百分百确定，敬请关注！

KYAML 作为一种格式，是 YAML 的严格子集，这确保任何符合规范的 YAML 解析器都能解析 KYAML 文档。 Kubernetes 并不要求你必须提供 KYAML 格式的输入，也没有这方面的计划。

HPA 支持精细化自动扩缩控制容忍度配置

KEP-4951 引入了一项新特性，允许用户在每个 HPA 上配置扩缩容忍度，以覆盖默认的集群级 10% 容忍度设置，这一默认值对多样化的工作负载来说往往过于粗略。本次增强为 HPA 的 spec.behavior.scaleUp 和 spec.behavior.scaleDown 部分新增了可选的 tolerance 字段，使得扩容和缩容操作可以采用不同的容忍值。这非常有用，因为在应对突发流量时，扩容响应通常比缩容速度更为关键。

此特性作为 Alpha 特性，在 Kubernetes v1.33 中引入，并受 HPAConfigurableTolerance 特性门控控制。预计将在 v1.34 中进阶为 Beta。这项改进有助于解决大规模部署中的扩缩容难题，例如在缩容时，10% 的容忍度可能意味着会保留数百个不必要的 Pod。通过这一更灵活的配置方式，用户可以针对不同工作负载优化扩缩容行为的响应性和保守性。

想了解更多？

新特性和弃用项也会在 Kubernetes 发布说明中公布。我们将在 Kubernetes v1.34 变更日志中正式宣布新增内容。

Kubernetes v1.34 的计划发布时间为 2025 年 8 月 27 日（周三）。敬请期待更多更新！

参与其中

参与 Kubernetes 最简单的方式就是加入与你兴趣相关的特别兴趣小组（SIG）。有想要向社区分享的内容？欢迎在每周的社区会议上发声，或通过以下渠道参与讨论。感谢你一如既往的反馈和支持！

在 Bluesky 上关注我们 @kubernetes.io，获取最新动态
在 Discuss 上参与社区讨论
加入 Slack 社区
在 Server Fault 或 Stack Overflow 上提问或回答问题
分享你的 Kubernetes 使用故事
阅读 Kubernetes 官方博客上的更多动态
了解 Kubernetes 发布团队的更多信息

云原生环境中的镜像兼容性

Wed, 25 Jun 2025 00:00:00 +0000

在电信、高性能或 AI 计算等必须高度可靠且满足严格性能标准的行业中，容器化应用通常需要特定的操作系统配置或硬件支持。通常的做法是要求使用特定版本的内核、其配置、设备驱动程序或系统组件。尽管存在开放容器倡议 (OCI) 这样一个定义容器镜像标准和规范的治理社区，但在表达这种兼容性需求方面仍存在空白。为了解决这一问题，业界提出了多个提案，并最终在 Kubernetes 的节点特性发现 (NFD) 项目中实现了相关功能。

NFD 是一个开源的 Kubernetes 项目，能够自动检测并报告集群节点的硬件和系统特性。这些信息帮助用户将工作负载调度到满足特定系统需求的节点上，尤其适用于具有严格硬件或操作系统依赖的应用。

镜像兼容性规范的需求

容器与主机操作系统之间的依赖关系

容器镜像是基于基础镜像构建的，基础镜像提供了最小的运行时环境，通常是一个精简的 Linux 用户态环境，有时甚至是完全空白或无发行版的。当应用需要来自主机操作系统的某些特性时，就会出现兼容性问题。这些依赖可能表现为以下几种形式：

驱动程序：主机上的驱动程序版本必须与容器内的库所支持的版本范围相匹配，以避免兼容性问题，例如 GPU 和网络驱动。
库或软件：容器必须包含某个库或软件的特定版本或版本范围，才能在目标环境中以最优方式运行。高性能计算方面的示例包括 MPI、EFA 或 Infiniband。
内核模块或特性：必须存在特定的内核特性或模块，例如对写入保护巨页错误的支持，或存在对 VFIO 的支持。
以及其他更多形式...

虽然在 Kubernetes 中容器是这些需求最常见的抽象单位，但兼容性的定义可以进一步扩展，包括 Singularity 等其他容器技术以及来自 spack 二进制缓存的二进制文件等 OCI 工件。

多云与混合云的挑战

容器化应用被部署在各种 Kubernetes 发行版和云平台上，而不同的主机操作系统带来了兼容性挑战。这些操作系统通常需要在部署工作负载之前预配置，或者它们是不可变的。例如，不同云平台会使用不同的操作系统，包括：

RHCOS/RHEL
Photon OS
Amazon Linux 2
Container-Optimized OS
Azure Linux OS
等等...

每种操作系统都具有独特的内核版本、配置和驱动程序，对于需要特定特性的应用来说，兼容性问题并不简单。因此必须能够快速评估某个容器镜像是否适合在某个特定环境中运行。

镜像兼容性倡议

OCI 镜像兼容性工作组正在推动引入一个镜像兼容性元数据的标准。此规范允许容器作者声明所需的主机操作系统特性，使兼容性需求可以被发现和编程化处理。目前已在 Kubernetes 的 Node Feature Discovery 中实现了其中一个被讨论的提案，其目标包括：

在 OCI 镜像清单中定义一种结构化的兼容性表达方式。
支持在镜像仓库中将兼容性规范与容器镜像一同存储。
在容器调度之前实现兼容性自动验证。

这个理念目前已在 Kubernetes 的 Node Feature Discovery 项目中落地。

在 Node Feature Discovery 中的实现

这种解决方案通过 NFD 的特性机制和 NodeFeatureGroup API 将兼容性元数据集成到 Kubernetes 中。此接口使用户可以根据硬件和软件暴露的特性将容器与节点进行匹配，从而实现智能调度与工作负载优化。

兼容性规范

兼容性规范是一个结构化的兼容性对象列表，包含 Node Feature Groups。这些对象定义了镜像要求，并支持与主机节点进行验证。特性需求通过 NFD 项目提供的特性列表进行描述。此模式的结构如下：

version（字符串）— 指定 API 版本。
compatibilities（对象数组）— 兼容性集合列表。
- rules（对象）— 指定 NodeFeatureGroup 来定义镜像要求。
- weight（整数，可选）— 节点亲和性权重。
- tag（字符串，可选）— 分类标记。
- description（字符串，可选）— 简短描述。

示例如下：

version: v1alpha1
compatibilities:
- description: "My image requirements"
  rules:
  - name: "kernel and cpu"
    matchFeatures:
    - feature: kernel.loadedmodule
      matchExpressions:
        vfio-pci: {op: Exists}
    - feature: cpu.model
      matchExpressions:
        vendor_id: {op: In, value: ["Intel", "AMD"]}
  - name: "one of available nics"
    matchAny:
    - matchFeatures:
      - feature: pci.device
        matchExpressions:
          vendor: {op: In, value: ["0eee"]}
          class: {op: In, value: ["0200"]}
    - matchFeatures:
      - feature: pci.device
        matchExpressions:
          vendor: {op: In, value: ["0fff"]}
          class: {op: In, value: ["0200"]}

节点验证的客户端实现

为了简化兼容性验证，我们实现了一个客户端工具，可以根据镜像的兼容性工件进行节点验证。在这个流程中，镜像作者会生成一个兼容性工件，并通过引用者（Referrs） API 将其指向镜像所在的仓库。当需要评估某个镜像是否适用于某个主机节点时，此工具可以发现工件并在部署前验证镜像对节点的兼容性。客户端可以验证 Kubernetes 集群内外的节点，扩大了其应用范围。未来，镜像兼容性还可能在基于镜像要求创建特定工作负载配置文件中发挥关键作用，有助于提升调度效率。此外，还可能实现一定程度上的节点自动配置，进一步优化资源分配并确保特种工作负载的顺利部署。

使用示例

定义镜像兼容性元数据

一个容器镜像可以包含元数据，基于节点所发现的特性（如内核模块或 CPU 型号）描述其需求。上文所述的兼容性规范示例即体现了这种用法。

将工件挂接到镜像上

镜像兼容性规范以 OCI 工件的形式存储。你可以使用 oras 工具将元数据挂接到你的容器镜像上。镜像仓库只需支持 OCI 工件，不必支持任意类型。请注意，容器镜像和工件必须存储在同一个镜像仓库中。使用以下命令将工件挂接到镜像上：
```
oras attach \ 
--artifact-type application/vnd.nfd.image-compatibility.v1alpha1 <image-url> \ 
<path-to-spec>.yaml:application/vnd.nfd.image-compatibility.spec.v1alpha1+yaml
```

验证镜像兼容性

在挂接兼容性规范之后，你可以验证某个节点是否满足镜像的运行要求。这种验证可以通过 nfd 客户端来完成：
```
nfd compat validate-node --image <镜像地址>
```

读取客户端的输出

你可以阅读工具生成的报告，也可以使用你自己的工具解析生成的 JSON 报告并做出决策。

总结

通过 Node Feature Discovery 将镜像兼容性引入 Kubernetes，突显了在云原生环境中解决兼容性问题的重要性。这只是一个起点，未来仍需进一步将兼容性深度集成到 Kubernetes 内外的工作负载调度中。然而，借助这一功能，关键任务型工作负载现在可以更高效地定义和验证其对主机操作系统的要求。展望未来，兼容性元数据在 Kubernetes 生态系统中的广泛采用将显著提升专用容器化应用的可靠性与性能，确保其能够满足电信、高性能计算等行业对硬件或主机系统配置的严格要求。

加入我们

如果你有兴趣参与镜像兼容性 API 和工具的设计与开发，欢迎加入 Kubernetes Node Feature Discovery 项目。我们始终欢迎新的贡献者加入。

Kubernetes Slack 变更公告

Mon, 16 Jun 2025 00:00:00 +0000

更新：我们已收到 Salesforce 的通知，我们的 Slack 工作区在 6 月 20 日不会被降级。请等待更多细节更新，目前无需紧急备份私有频道或私信。

~~Kubernetes Slack 将在 6 月 20 日失去原有的专属支持，并转变为标准免费版 Slack~~~。今年晚些时候，我们的社区可能会迁移到新平台。如果你是频道或私有频道的负责人，又或是用户组的成员，你需要尽快采取一些行动。

在过去十年中，Slack 一直通过免费定制企业账户支持我们的项目。他们已告知我们无法继续提供这种支持，特别是因为我们的 Slack 是平台上最大和最活跃的社区之一。因此，在我们决定实施其他选项的同时，他们将把我们的账户降级为标准免费版 Slack。

在 6 月 20 日星期五，我们将受到免费版 Slack 的功能限制。主要影响包括仅保留 90 天的历史记录，以及必须禁用我们当前使用的几个应用程序和工作流。 Slack 管理团队将尽最大努力管理这些限制。

负责的频道所有者、私有频道成员和用户组成员应该采取一些行动，以尽快为升级做准备并保存信息。

CNCF 项目工作人员建议我们的社区考虑迁移到 Discord。由于在拓展 Slack 功能极限的过程中存在一些问题，他们已经探索过 Kubernetes Discord 会是什么样子。 Discord 将允许我们实现新的工具和集成，以帮助社区，例如 GitHub 组成员身份同步。指导委员会将讨论并决定我们的未来平台。

请查看我们的常见问题解答，并关注 kubernetes-dev 邮件列表和 #announcements 频道以获取更多新闻。如果你对我们的 Slack 状态有具体反馈，请加入 GitHub 上的讨论。

通过自定义聚合增强 Kubernetes Event 管理

Tue, 10 Jun 2025 00:00:00 +0000

Kubernetes Event 提供了集群操作的关键洞察信息，但随着集群的增长，管理和分析这些 Event 变得越来越具有挑战性。这篇博客文章探讨了如何构建自定义 Event 聚合系统，以帮助工程团队更好地理解集群行为并更有效地解决问题。

Kubernetes Event 的挑战

在 Kubernetes 集群中，从 Pod 调度、容器启动到卷挂载和网络配置，各种操作都会生成 Event。虽然这些 Event 对于调试和监控非常有价值，但在生产环境中出现了几个挑战：

量：大型集群每分钟可以生成数千个 Event
保留：默认 Event 保留时间限制为一小时
关联：不同组件的相关 Event 不会自动链接
分类：Event 缺乏标准化的严重性或类别分类
聚合：相似的 Event 不会自动分组

要了解更多关于 Kubernetes Event 的信息，请阅读 Event API 参考。

现实世界的价值

考虑一个拥有数十个微服务的生产环境中，用户报告间歇性事务失败的情况：

传统的 Event 聚合过程： 工程师浪费数小时筛选分散在各个命名空间中的成千上万的独立 Event。等到他们查看时，较旧的 Event 早已被清除，将 Pod 重启与节点级别问题关联实际上是不可能的。

在自定义 Event 中使用 Event 聚合器： 系统跨资源分组 Event，即时浮现如卷挂载超时等关联模式，这些模式出现在 Pod 重启之前。历史记录表明，这发生在过去的流量高峰期间，突显了存储扩缩问题，在几分钟内而不是几小时内发现问题。

这种方法的好处是，实施它的组织通常可以显著减少故障排除时间，并通过早期检测模式来提高系统的可靠性。

构建 Event 聚合系统

本文探讨了如何构建一个解决这些问题的自定义 Event 聚合系统，该系统符合 Kubernetes 最佳实践。我选择了 Go 编程语言作为示例。

架构概述

这个 Event 聚合系统由三个主要组件组成：

Event 监视器：监控 Kubernetes API 的新 Event
Event 处理器：处理、分类和关联 Event
存储后端：存储处理过的 Event 以实现更长的保留期

以下是实现 Event 监视器的示例代码：

package main

import (
    "context"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/rest"
    eventsv1 "k8s.io/api/events/v1"
)

type EventWatcher struct {
    clientset *kubernetes.Clientset
}

func NewEventWatcher(config *rest.Config) (*EventWatcher, error) {
    clientset, err := kubernetes.NewForConfig(config)
    if err != nil {
        return nil, err
    }
    return &EventWatcher{clientset: clientset}, nil
}

func (w *EventWatcher) Watch(ctx context.Context) (<-chan *eventsv1.Event, error) {
    events := make(chan *eventsv1.Event)
    
    watcher, err := w.clientset.EventsV1().Events("").Watch(ctx, metav1.ListOptions{})
    if err != nil {
        return nil, err
    }

    go func() {
        defer close(events)
        for {
            select {
            case event := <-watcher.ResultChan():
                if e, ok := event.Object.(*eventsv1.Event); ok {
                    events <- e
                }
            case <-ctx.Done():
                watcher.Stop()
                return
            }
        }
    }()

    return events, nil
}

Event 处理和分类

Event 处理器为 Event 添加额外的上下文和分类：

type EventProcessor struct {
    categoryRules []CategoryRule
    correlationRules []CorrelationRule
}

type ProcessedEvent struct {
    Event     *eventsv1.Event
    Category  string
    Severity  string
    CorrelationID string
    Metadata  map[string]string
}

func (p *EventProcessor) Process(event *eventsv1.Event) *ProcessedEvent {
    processed := &ProcessedEvent{
        Event:    event,
        Metadata: make(map[string]string),
    }
    
    // 应用分类规则
    processed.Category = p.classifyEvent(event)
    processed.Severity = p.determineSeverity(event)
    
    // 为相关 Event 生成关联 ID
    processed.CorrelationID = p.correlateEvent(event)
    
    // 添加有用的元数据
    processed.Metadata = p.extractMetadata(event)
    
    return processed
}

实现 Event 关联

你可以实现的一个关键特性是关联相关 Event 的方法，这里有一个示例关联策略：

func (p *EventProcessor) correlateEvent(event *eventsv1.Event) string {
    // 相关策略：
    // 1. 基于时间的：时间窗口内的事件
    // 2. 基于资源的：影响同一资源的事件
    // 3. 基于因果关系的：具有因果关系的事件

    correlationKey := generateCorrelationKey(event)
    return correlationKey
}

func generateCorrelationKey(event *eventsv1.Event) string {
    // 示例：结合命名空间、资源类型和名称
    return fmt.Sprintf("%s/%s/%s",
        event.InvolvedObject.Namespace,
        event.InvolvedObject.Kind,
        event.InvolvedObject.Name,
    )
}

Event 存储和保留

对于长期存储和分析，你可能需要一个支持以下功能的后端：

大量 Event 的高效查询
灵活的保留策略
支持聚合查询

这里是一个示例存储接口：

type EventStorage interface {
    Store(context.Context, *ProcessedEvent) error
    Query(context.Context, EventQuery) ([]ProcessedEvent, error)
    Aggregate(context.Context, AggregationParams) ([]EventAggregate, error)
}

type EventQuery struct {
    TimeRange     TimeRange
    Categories    []string
    Severity      []string
    CorrelationID string
    Limit         int
}

type AggregationParams struct {
    GroupBy    []string
    TimeWindow string
    Metrics    []string
}

Event 管理的良好实践

资源效率
- 为 Event 处理实现速率限制
- 在 API 服务器级别使用高效的过滤
- 对存储操作批量处理 Event

扩缩性
- 将 Event 处理分派给多个工作线程
- 使用领导者选举进行协调
- 实施 API 速率限制的退避策略
可靠性
- 优雅地处理 API 服务器断开连接
- 在存储后端不可用期间缓冲 Event
- 实施带有指数退避的重试机制

高级特性

模式检测

实现模式检测以识别重复出现的问题：

type PatternDetector struct {
    patterns map[string]*Pattern
    threshold int
}

func (d *PatternDetector) Detect(events []ProcessedEvent) []Pattern {
    // 将类似 Event 分组
    groups := groupSimilarEvents(events)
    
    // Analyze frequency and timing
    patterns := identifyPatterns(groups)
    
    return patterns
}

func groupSimilarEvents(events []ProcessedEvent) map[string][]ProcessedEvent {
    groups := make(map[string][]ProcessedEvent)
    
    for _, event := range events {
        // 根据 Event 特征创建相似性键
        similarityKey := fmt.Sprintf("%s:%s:%s",
            event.Event.Reason,
            event.Event.InvolvedObject.Kind,
            event.Event.InvolvedObject.Namespace,
        )
        
        // 用相同的键对 Event 进行分组
        groups[similarityKey] = append(groups[similarityKey], event)
    }
    
    return groups
}


func identifyPatterns(groups map[string][]ProcessedEvent) []Pattern {
    var patterns []Pattern
    
    for key, events := range groups {
        // 只考虑具有足够 Event 以形成模式的组
        if len(events) < 3 {
            continue
        }
        
        // 按时间对 Event 进行排序
        sort.Slice(events, func(i, j int) bool {
            return events[i].Event.LastTimestamp.Time.Before(events[j].Event.LastTimestamp.Time)
        })
        
        // 计算时间范围和频率
        firstSeen := events[0].Event.FirstTimestamp.Time
        lastSeen := events[len(events)-1].Event.LastTimestamp.Time
        duration := lastSeen.Sub(firstSeen).Minutes()
        
        var frequency float64
        if duration > 0 {
            frequency = float64(len(events)) / duration
        }
        
        // 如果满足阈值标准，则创建模式
        if frequency > 0.5 { // 每 2 分钟发生超过 1 个事件
            pattern := Pattern{
                Type:         key,
                Count:        len(events),
                FirstSeen:    firstSeen,
                LastSeen:     lastSeen,
                Frequency:    frequency,
                EventSamples: events[:min(3, len(events))], // 最多保留 3 个样本
            }
            patterns = append(patterns, pattern)
        }
    }
    
    return patterns
}

通过此实现，系统可以识别诸如节点压力 Event、Pod 调度失败或以特定频率发生的网络问题等重复出现的模式。

实时警报

以下示例提供了一个基于 Event 模式构建警报系统的基础起点。它不是一个完整的解决方案，而是一个用于说明方法的概念性草图。

type AlertManager struct {
    rules []AlertRule
    notifiers []Notifier
}

func (a *AlertManager) EvaluateEvents(events []ProcessedEvent) {
    for _, rule := range a.rules {
        if rule.Matches(events) {
            alert := rule.GenerateAlert(events)
            a.notify(alert)
        }
    }
}

结论

一个设计良好的 Event 聚合系统可以显著提高集群的可观测性和故障排查能力。通过实现自定义的 Event 处理、关联和存储，操作员可以更好地理解集群行为并更有效地响应问题。

这里介绍的解决方案可以根据具体需求进行扩展和定制，同时保持与 Kubernetes API的兼容性，并遵循可扩展性和可靠性方面的最佳实践。

下一步

未来的增强功能可能包括：

用于异常检测的机器学习
与流行的可观测性平台集成
面向应用 Event 的自定义 Event API
增强的可视化和报告能力

有关 Kubernetes Event 和自定义控制器的更多信息，请参阅官方 Kubernetes 文档。

介绍 Gateway API 推理扩展

Thu, 05 Jun 2025 00:00:00 +0000

现代生成式 AI 和大语言模型（LLM）服务在 Kubernetes 上带来独特的流量路由挑战。与典型的短生命期的无状态 Web 请求不同，LLM 推理会话通常是长时间运行的、资源密集型的，并且具有一定的状态性。例如，单个由 GPU 支撑的模型服务器可能会保持多个推理会话处于活跃状态，并保留内存中的令牌缓存。

传统的负载均衡器注重 HTTP 路径或轮询，缺乏处理这类工作负载所需的专业能力。传统的负载均衡器通常无法识别模型身份或请求重要性（例如交互式聊天与批处理任务的区别）。各个组织往往拼凑出临时解决方案，但一直缺乏标准化的做法。

Gateway API 推理扩展

Gateway API 推理扩展正是为了填补这一空白而创建的，它基于已有的 Gateway API 进行构建，添加了特定于推理的路由能力，同时保留了 Gateway 与 HTTPRoute 的熟悉模型。通过为现有 Gateway 添加推理扩展，你就能将其转变为一个推理网关（Inference Gateway），从而以“模型即服务”的理念自托管 GenAI/LLM 应用。

此项目的目标是在整个生态系统中改进并标准化对推理工作负载的路由。关键目标包括实现模型感知路由、支持逐个请求的重要性区分、促进安全的模型发布，以及基于实时模型指标来优化负载均衡。为了实现这些目标，此项目希望降低延迟并提高 AI 负载中的加速器（如 GPU）利用率。

工作原理

功能设计时引入了两个具有不同职责的全新定制资源（CRD），每个 CRD 对应 AI/ML 服务流程中的一个特定用户角色：

InferencePool 定义了一组在共享计算资源（如 GPU 节点）上运行的 Pod（模型服务器）。平台管理员可以配置这些 Pod 的部署、扩缩容和负载均衡策略。 InferencePool 确保资源使用情况的一致性，并执行平台级的策略。 InferencePool 类似于 Service，但专为 AI/ML 推理服务定制，能够感知模型服务协议。
InferenceModel 是面向用户的模型端点，由 AI/ML 拥有者管理。它将一个公共名称（如 "gpt-4-chat"）映射到 InferencePool 内的实际模型。这使得负载拥有者可以指定要服务的模型（及可选的微调版本），并配置流量拆分或优先级策略。

简而言之，InferenceModel API 让 AI/ML 拥有者管理“提供什么服务”，而 InferencePool 则让平台运维人员管理“在哪儿以及如何提供服务”。

请求流程

请求的处理流程基于 Gateway API 模型（Gateway 和 HTTPRoute），在其中插入一个或多个对推理有感知的步骤（扩展）。以下是一个使用端点选择扩展（Endpoint Selection Extension, ESE）的高级请求流程示意图：

Gateway 路由

客户端发送请求（例如向 /completions 发起 HTTP POST）。 Gateway（如 Envoy）会检查 HTTPRoute，并识别出匹配的 InferencePool 后端。
端点选择

Gateway 不会简单地将请求转发到任一可用的 Pod，而是调用一个特定于推理的路由扩展（端点选择扩展）从多个可用 Pod 中选出最优者。此扩展根据实时 Pod 指标（如队列长度、内存使用量、加载的适配器等）来选择最适合请求的 Pod。

推理感知调度

所选 Pod 是基于用户重要性或资源需求下延迟最低或效率最高者。随后 Gateway 将流量转发到这个特定的 Pod。

这一额外步骤提供了一种更为智能的模型感知路由机制，但对于客户端来说感觉就像一个普通的请求。此外，这种设计具有良好的可扩展性，任何推理网关都可以通过添加新的特定于推理的扩展来处理新的路由策略、高级调度逻辑或特定硬件需求。随着此项目的持续发展，欢迎社区贡献者开发与底层 Gateway API 模型完全兼容的新扩展，进一步拓展高效、智能的 GenAI/LLM 路由能力。

基准测试

我们将此扩展与标准 Kubernetes Service 进行了对比测试，基于 vLLM 部署模型服务。测试环境是在 Kubernetes 集群中运行 vLLM（v1）的多个 H100（80 GB）GPU Pod，并部署了 10 个 Llama2 模型副本。本次测试使用了 Latency Profile Generator (LPG) 工具生成流量，测量吞吐量、延迟等指标。采用的工作负载数据集为 ShareGPT，流量从 100 QPS 提升到 1000 QPS。

主要结果

吞吐量相当：在整个测试的 QPS 范围内，ESE 达到的吞吐量基本与标准 Kubernetes Service 持平。

延迟更低：
- 输出令牌层面的延迟：在高负载（QPS 500 以上）时，ESE 显示了 p90 延迟明显更低，这表明随着 GPU 显存达到饱和，其模型感知路由决策可以减少排队等待和资源争用。
- 整体 p90 延迟：出现类似趋势，ESE 相比基线降低了端到端尾部延迟，特别是在 QPS 超过 400–500 时更明显。

这些结果表明，此扩展的模型感知路由显著降低了 GPU 支撑的 LLM 负载的延迟。此扩展通过动态选择负载最轻或性能最优的模型服务器，避免了传统负载均衡方法在处理较大的、长时间运行的推理请求时会出现的热点问题。

路线图

随着 Gateway API 推理扩展迈向 GA（正式发布），计划中的特性包括：

前缀缓存感知负载均衡以支持远程缓存
LoRA 适配器流水线方便自动化上线
同一重要性等级下负载之间的公平性和优先级
HPA 支持基于聚合的模型层面指标扩缩容
支持大规模多模态输入/输出
支持额外的模型类型（如扩散模型）
异构加速器（支持多个加速器类型，并具备延迟和成本感知的负载均衡）
解耦式服务架构，以独立扩缩资源池

总结

通过将模型服务对齐到 Kubernetes 原生工具链，Gateway API 推理扩展致力于简化并标准化 AI/ML 流量的路由方式。此扩展引入模型感知路由、基于重要性的优先级等能力，帮助运维团队平滑高效地将合适的 LLM 服务交付给合适的用户。

想进一步学习？ 参阅项目文档深入学习，只需简单几步试用推理网关扩展。如果你想对此项目作贡献，欢迎参与其中！

先启动边车：如何避免障碍

Tue, 03 Jun 2025 00:00:00 +0000

从 "Kubernetes 多容器 Pod：概述"博客中，你了解了 Pod 的工作方式，Pod 的主要架构模式，以及 Pod 在 Kubernetes 中是如何实现的。本文主要介绍的是如何确保你的边车容器在主应用之前启动。这比你想象的要复杂得多！

简要回顾

我想提醒读者的是，Kubernetes v1.29.0 版本增加了对边车容器的原生支持，现在可以在 .spec.initContainers 字段中定义，但带有 restartPolicy: Always。你可以在下面的示例 Pod 清单片段中看到这一点：

initContainers:
  - name: logshipper
    image: alpine:latest
    restartPolicy: Always # 这就是它成为边车容器的原因
    command: ['sh', '-c', 'tail -F /opt/logs.txt']
    volumeMounts:
    - name: data
        mountPath: /opt

使用 .spec.initContainers 块定义边车与使用多个 .spec.containers 定义传统的多容器 Pod 相比，具体有什么不同？其实，所有 .spec.initContainers 总是在主应用之前启动。如果你定义了 Kubernetes 原生的边车容器，这些边车容器将在主应用之后终止。此外，当与 Job 一起使用时，边车容器仍然保持运行，并且在拥有它的 Job 完成后甚至可能重启； Kubernetes 原生边车容器不会阻止 Pod 的完成。

要了解更多，你也可以阅读官方的 Pod 边车容器教程。

问题

现在你知道使用这种原生方法定义边车总是会在主应用之前启动它。从 kubelet 源代码可以看出，这通常意味着几乎是并行启动的，而这并不总是工程师想要的结果。我们真正感兴趣的是，是否可以延迟主应用的启动，直到边车不仅启动而且完全运行并准备好服务。这可能有点棘手，因为与 Init 容器不同（设计为仅运行指定的时间段），边车没有明显的成功信号。对于一个 Init 容器，退出状态 0 明确表示“我成功了”。而对于边车容器，在很多情况下你可以说“某个东西正在运行”。仅在前一个容器准备好之后才启动另一个容器，这是优雅部署策略的一部分，确保启动期间的正确排序和稳定性。实际上，这也是我希望边车容器工作的方式，以覆盖主应用依赖于边车的场景。例如，如果边车不可用于服务请求（例如，使用 DataDog 进行日志记录），应用程序可能会报错。当然，可以更改应用程序代码（这实际上是“最佳实践”解决方案），但有时他们不能这样做 - 而本文档关注的就是这种情况。

我会解释一些你可能尝试的方法，并告诉你哪些方法真的有效。

就绪性检测

要检查 Kubernetes 原生边车是否会延迟主应用的启动直到边车准备就绪，让我们模拟一个简短的调查。首先，我将通过实现一个永远不会成功的就绪探针来模拟一个永远不会准备就绪的边车容器。提醒一下，就绪性探针检查容器是否准备好开始接受流量，由此判断 Pod 是否可以用于服务的后端。

（与标准的 Init 容器不同，边车容器可以拥有探针，以便 kubelet 可以监督边车，并在出现问题时进行干预。例如，如果边车容器未通过健康检查，则重启它。）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ["sh", "-c", "sleep 3600"]
      initContainers:
        - name: nginx
          image: nginx:latest
          restartPolicy: Always
          ports:
            - containerPort: 80
              protocol: TCP
          readinessProbe:
            exec:
              command:
              - /bin/sh
              - -c
              - exit 1 # 此命令总是失败，导致容器处于"未就绪"状态
            periodSeconds: 5
      volumes:
        - name: data
          emptyDir: {}

结果是：

controlplane $ kubectl get pods -w
NAME                    READY   STATUS    RESTARTS   AGE
myapp-db5474f45-htgw5   1/2     Running   0          9m28s

controlplane $ kubectl describe pod myapp-db5474f45-htgw5 
Name:             myapp-db5474f45-htgw5
Namespace:        default
(...)
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  17s               default-scheduler  Successfully assigned default/myapp-db5474f45-htgw5 to node01
  Normal   Pulling    16s               kubelet            Pulling image "nginx:latest"
  Normal   Pulled     16s               kubelet            Successfully pulled image "nginx:latest" in 163ms (163ms including waiting). Image size: 72080558 bytes.
  Normal   Created    16s               kubelet            Created container nginx
  Normal   Started    16s               kubelet            Started container nginx
  Normal   Pulling    15s               kubelet            Pulling image "alpine:latest"
  Normal   Pulled     15s               kubelet            Successfully pulled image "alpine:latest" in 159ms (160ms including waiting). Image size: 3652536 bytes.
  Normal   Created    15s               kubelet            Created container myapp
  Normal   Started    15s               kubelet            Started container myapp
  Warning  Unhealthy  1s (x6 over 15s)  kubelet            Readiness probe failed:

从这些日志中可以明显看出只有一个容器准备就绪 - 我知道这不可能是边车，因为我将其定义为永远不会准备就绪（你也可以在 kubectl get pod -o json 中检查容器状态）。我还看到 myapp 在边车准备就绪之前已经启动。这不是我希望达到的结果；在这种情况下，主应用容器对它边车有硬依赖。

或许是一个启动探针？

为了确保边车准备就绪后再启动主应用容器，我可以定义一个 startupProbe。这将延迟主容器的启动，直到命令成功执行（返回 0 退出状态）。如果你想知道为什么我将其添加到我的 initContainer 中，让我们分析一下如果我将其添加到 myapp 容器会发生什么。我不能保证探针会在主应用代码之前运行 - 而这可能会导致错误，尤其是在边车尚未启动和运行时。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ["sh", "-c", "sleep 3600"]
      initContainers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
              protocol: TCP
          restartPolicy: Always
          startupProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 30
            failureThreshold: 10
            timeoutSeconds: 20
      volumes:
        - name: data
          emptyDir: {}

这导致 2/2 个容器已就绪并运行，从事件中可以推断主应用仅在 nginx 已启动后才开始启动。但为了确认它是否等待了边车的就绪状态，让我们将 startupProbe 更改为执行类型命令：

startupProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - sleep 15

并运行 kubectl get pods -w 以实时观察两个容器的就绪状态是否仅在 15 秒延迟后更改。再次确认，事件显示主应用在边车之后启动。这意味着使用带有正确 startupProbe.httpGet 请求的 startupProbe 有助于延迟主应用的启动，直到边车准备就绪。这不理想，但它有效。

关于 postStart 生命周期钩子？

趣闻：使用 postStart 生命周期钩子块也可以完成任务，但我要编写自己的迷你 Shell 脚本，这甚至更低效。

initContainers:
  - name: nginx
    image: nginx:latest
    restartPolicy: Always
    ports:
      - containerPort: 80
        protocol: TCP
    lifecycle:
      postStart:
        exec:
          command:
          - /bin/sh
          - -c
          - |
            echo "Waiting for readiness at http://localhost:80"
            until curl -sf http://localhost:80; do
              echo "Still waiting for http://localhost:80..."
              sleep 5
            done
            echo "Service is ready at http://localhost:80"

存活探针

一个有趣的练习是使用存活探针检查边车容器的行为。存活探针的配置和行为与就绪探针相似——唯一的区别是它不会影响容器的就绪状态，而是在探针失败时重启容器。

livenessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - exit 1 # 该命令总是失败，导致容器处于"未就绪"状态
  periodSeconds: 5

在添加了配置与之前的就绪探针相同的存活探针，并通过 kubectl describe pod 检查 Pod 的事件后，可以看到边车的重启次数超过 0。尽管如此，主应用并未受到任何影响或重启，即使我知道（在我们假想的最坏情况下）当边车不处理请求时，主应用可能会出错。如果我在没有生命周期 postStart 的情况下使用 livenessProbe 会怎样？两个容器将立即准备就绪：一开始，这种行为不会与没有任何额外探针的情况有任何不同，因为存活探针完全不影响就绪状态。一段时间后，边车将开始重启自己，但这不会影响主容器。

调研总结

我将在下表中总结启动行为：

探针/钩子	边车在主应用之前启动？	主应用是否等待边车准备就绪？	如果检查不通过会发生什么？
`readinessProbe`	是，但几乎是并行的（实际上为否）	否	边车未就绪；主应用继续运行
`livenessProbe`	是，但几乎是并行的（实际上为否）	否	边车被重启，主应用继续运行
`startupProbe`	是	是	主应用不会启动
postStart	是，主应用容器在 `postStart` 完成后启动	是，但你必须为此提供自定义逻辑	主应用不会启动

总结：由于边车经常是主应用的依赖项，你可能希望延迟后者启动直到边车健康。

理想模式是同时启动两个容器，并让应用容器逻辑在所有层面上延迟，但这并不总是可行。如果你需要这样做，就必须对 Pod 定义使用适当的自定义设置。值得庆幸的是，这既简单又快速，并且你已经有了上面的解决方案。

祝部署顺利！

Gateway API v1.3.0：流量复制、CORS、Gateway 合并和重试预算的改进

Mon, 02 Jun 2025 09:00:00 -0800

加入 Kubernetes SIG Network 社区，共同庆祝 Gateway API v1.3.0 正式发布！我们很高兴地宣布，通过推迟这篇博客的发布，现在已经有了多个符合规范的实现可供试用。 API 1.3.0 版本已于 2025 年 4 月 24 日发布。

Gateway API v1.3.0 为 Standard 渠道（Gateway API 的正式发布渠道）带来了一个新功能：基于百分比的流量复制，并引入了三个新的实验性功能：

跨源资源共享（CORS）过滤器
Listener 和 Gateway 合并的标准化机制
重试预算（Retry Budgets）

另请查看完整的发布说明，下次见到 v1.3.0 发布团队时请为他们鼓掌。

升级至 Standard 渠道

对于 Gateway API 的功能来说，升级到 Standard 渠道是一个重要的里程碑。被纳入 Standard 发布渠道表明我们对该 API 接口的稳定性具有高度信心，并且承诺向后兼容。当然，与任何其他 Kubernetes API 一样， Standard 渠道中的功能仍可通过向后兼容的方式不断演进。我们（SIG Network）也确实预计未来会有进一步的优化和改进。有关这一切如何运作的更多信息，请参阅 Gateway API 版本控制策略。

基于百分比的流量复制

负责人：Lior Lieberman、Jake Bennert GEP-3171：基于百分比的流量复制

基于百分比的流量复制是对现有 HTTP 流量复制支持的增强，它允许使用 RequestMirror 过滤器类型将 HTTP 请求复制到另一个后端。流量复制在蓝绿部署中特别有用。它可用于评估流量波动对应用程序性能的影响，而不会影响对客户端的响应。

之前的流量复制功能适用于对 backendRef 的所有请求。基于百分比的流量复制允许用户指定他们想要复制的请求子集，可以通过百分比或分数来指定。当服务接收大量请求时，这特别有用。这个新功能可以用来复制这些请求中的一小部分，而不是复制所有请求。

以下是一个示例，将发送到 "foo-v1" 的流量的 42% 复制到 "foo-v2"：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-filter-mirror
  labels:
    gateway: mirror-gateway
spec:
  parentRefs:
  - name: mirror-gateway
  hostnames:
  - mirror.example
  rules:
  - backendRefs:
    - name: foo-v1
      port: 8080
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          name: foo-v2
          port: 8080
        percent: 42 # 此值必须为整数。

你也可以通过调整分数来实现部分流量复制。以下是一个示例，在发送到 "foo-v1" 的请求中，将每 1000 个中的 5 个复制到 "foo-v2"。

  rules:
  - backendRefs:
    - name: foo-v1
      port: 8080
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          name: foo-v2
          port: 8080
        fraction:
          numerator: 5
          denominator: 1000

实验渠道的新特性

实验渠道（Experimental channel）是 Gateway API 用于试验新功能的渠道，以便在功能成熟之前积累足够信心，再将其升级为 Standard 渠道功能。请注意：实验渠道可能包含后续会被更改或移除的功能。

从 v1.3.0 版本开始，为了区分实验渠道资源和 Standard 渠道资源，所有新的实验性 API 类型都带有 "X" 前缀。出于同样的原因，实验性资源现在被添加到 API 组 gateway.networking.x-k8s.io，而不是 gateway.networking.k8s.io。请注意，使用新的实验渠道资源意味着它们可以与 Standard 渠道资源共存，若要将这些资源迁移到 Standard 渠道，则需要使用 Standard 渠道的名称和 API 组（两者都不包含 "x-k8s" 标识或 "X" 前缀）来重新创建它们。

v1.3 版本引入了两个新的实验性 API 类型：XBackendTrafficPolicy 和 XListenerSet。要使用实验性 API 类型，你需要从下面列出的位置安装实验渠道 Gateway API YAML 文件。

CORS 过滤

负责人：Liang Li、Eyal Pazz、Rob Scott

GEP-1767：CORS 过滤器

跨源资源共享（CORS）是一种基于 HTTP Header 的机制，允许网页从与提供网页的域不同的源（域名、协议或端口）访问受限资源。此功能添加了一个新的 HTTPRoute filter 类型，称为 "CORS"，用于在响应发送回客户端之前配置跨源请求的处理。

要使用实验性 CORS 过滤，你需要安装实验渠道 Gateway API HTTPRoute yaml。

以下是一个简单的跨源配置示例：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-route-cors
spec:
  parentRefs:
  - name: http-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /resource/foo
    filters:
    - cors:
      - type: CORS
        allowOrigins:
        - *
        allowMethods:
        - GET
        - HEAD
        - POST
        allowHeaders:
        - Accept
        - Accept-Language
        - Content-Language
        - Content-Type
        - Range
    backendRefs:
    - kind: Service
      name: http-route-cors
      port: 80

在这种情况下，Gateway 返回一个 origin header 为 "*"，这意味着请求的资源可以从任何源引用；一个 methods header （Access-Control-Allow-Methods）允许 GET、HEAD 和 POST 方法；此外，还会返回一个 headers header ，允许的字段包括 Accept、Accept-Language、 Content-Language、Content-Type 和 Range。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, HEAD, POST
Access-Control-Allow-Headers: Accept,Accept-Language,Content-Language,Content-Type,Range

新的 CORS 过滤器中的完整字段列表如下：

allowOrigins：允许的请求来源列表。
allowMethods：允许的 HTTP 方法（如 GET、POST 等）。
allowHeaders：允许携带的请求头字段。
allowCredentials：是否允许携带凭据（如 Cookie、Authorization 头等）。
exposeHeaders：允许客户端访问的响应头字段。
maxAge：预检请求的缓存持续时间（单位：秒）。

有关详细信息，请参阅 CORS 协议。

XListenerSets（Listener 和 Gateway 合并的标准化机制）

负责人：Dave Protasowski

GEP-1713：ListenerSets - 合并多个 Gateway 的标准机制

此版本添加了一个新的实验性 API 类型 XListenerSet，它允许将 listeners 的共享列表附加到一个或多个父 Gateway。此外，它还扩展了现有的建议，即 Gateway API 实现可以合并来自多个 Gateway 对象的配置。它还包括：

向 Gateway 的 .spec 添加了一个新字段 allowedListeners。 allowedListeners 字段定义了从哪些命名空间选择允许附加到该 Gateway 的 XListenerSets： Same（同一命名空间）、All（所有命名空间）、None（不允许）、或基于选择器（Selector）的方式。

通过添加 XListenerSets 增加了之前的监听器最大数量（64）。

允许将监听器配置（如 TLS）委托给其他命名空间中的应用程序。

要使用实验性 XListenerSet，你需要安装实验渠道 Gateway API XListenerSet yaml。

以下示例展示了一个带有 HTTP 监听器和两个子 HTTPS XListenerSets 的 Gateway，每个 XListenerSet 都有唯一的主机名和证书。最终附加到该 Gateway 的监听器集合包含这两个附加的 HTTPS XListenerSet 监听器。此示例说明了将监听器 TLS 配置委托给不同命名空间（"store" 和 "app"）中的应用程序所有者。 HTTPRoute 同时将名为 "foo" 的 Gateway 监听器和一个名为 "second" 的 XListenerSet 监听器设置为其 parentRefs。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-external
  namespace: infra
spec:
  gatewayClassName: example
  allowedListeners:
  - from: All
  listeners:
  - name: foo
    hostname: foo.com
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XListenerSet
metadata:
  name: store
  namespace: store
spec:
  parentRef:
    name: prod-external
  listeners:
  - name: first
    hostname: first.foo.com
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        group: ""
        name: first-workload-cert
---
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XListenerSet
metadata:
  name: app
  namespace: app
spec:
  parentRef:
    name: prod-external
  listeners:
  - name: second
    hostname: second.foo.com
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        group: ""
        name: second-workload-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httproute-example
spec:
  parentRefs:
  - name: app
    kind: XListenerSet
    sectionName: second
  - name: parent-gateway
    kind: Gateway
    sectionName: foo
    ...

Gateway 中的每个监听器必须具有唯一的 port、protocol 组合（如果协议支持，还包括 hostname），以便所有监听器都兼容，并且不会在它们应该接收的流量上发生冲突。

此外，如果这些 Gateway 上的所有监听器都兼容，实现可以将单独的 Gateway 合并为单个监听器地址集。在 v1.3.0 之前的版本中，合并监听器的管理规范不足。

通过新功能，合并规范得到了扩展。实现必须将父 Gateway 视为具有来自自身和附加的 XListenerSets 的所有监听器的合并列表，并且对该监听器列表的验证行为应与其作为单个 Gateway 的一部分。在单个 Gateway 内，监听器使用以下优先级排序：

首先是单个监听器（而不是 XListenerSet 的一部分），

其余监听器按以下顺序排序：
- 按对象创建时间排序（最早创建的优先）；
- 如果两个监听器所在的对象具有相同的时间戳，则按照 {namespace}/{监听器名称} 的字母顺序排序

重试预算（Retry budgets）（XBackendTrafficPolicy）

负责人：Eric Bishop、Mike Morris

GEP-3388：重试预算（Retry budgets）

此功能允许你为目标服务的所有端点配置重试预算（Retry budgets）。用于在达到配置的阈值后限制额外的客户端重试。配置预算时，可以指定可能包含重试在内的活动请求的最大百分比，以及在计算重试阈值时考虑请求的时间间隔。此规范的开发将现有的实验性 API 类型 BackendLBPolicy 更改为新的实验性 API 类型 XBackendTrafficPolicy，以减少具有共同点的策略资源的扩散。

要使用实验性重试预算（Retry budgets），你需要安装实验渠道 Gateway API XBackendTrafficPolicy yaml。

以下示例显示了一个 XBackendTrafficPolicy，它应用了一个 retryConstraint （重试约束），表示一个重试预算（Retry budgets），将重试限制为最多 20% 的请求，持续时间为 10 秒，并且在 1 秒内最少重试 3 次。

apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackendTrafficPolicy
metadata:
  name: traffic-policy-example
spec:
  retryConstraint:
    budget:
      percent: 20
      interval: 10s
    minRetryRate:
      count: 3
      interval: 1s
    ...

试用

与其他 Kubernetes API 不同，你不需要升级到最新版本的 Kubernetes 来获取最新版本的 Gateway API。只要你运行的是 Kubernetes 1.26 或更高版本，你就可以使用此版本的 Gateway API 启动和运行。

要试用 API，请按照入门指南操作。截至本文撰写时，已有四个实现符合 Gateway API v1.3 实验渠道功能。按字母顺序排列：

参与其中

想知道何时会添加功能？有很多机会参与并帮助定义 Kubernetes API 路由的未来，包括 Ingress 和服务网格。

查看用户指南了解可以解决哪些用例。
试用现有的 Gateway 控制器之一。
或者加入我们的社区，帮助我们共同构建 Gateway API 的未来！

维护者衷心感谢所有为 Gateway API 做出贡献的人，无论是通过提交代码、讨论、想法还是提供其他支持。没有这个充满热情和活力的社区，我们永远无法取得如此进展。

Gateway API v1.2：WebSockets、超时、重试等（2024 年 11 月）
Gateway API v1.1：服务网格、GRPCRoute 和更多变化（2024 年 5 月）
Gateway API v1.0 中的新实验功能（2023 年 11 月）
Gateway API v1.0：正式发布（GA）（2023 年 10 月）

Kubernetes v1.33：原地调整 Pod 资源特性升级为 Beta

Fri, 16 May 2025 10:30:00 -0800

代表 Kubernetes 项目，我很高兴地宣布，原地 Pod 调整大小特性（也称为原地 Pod 垂直缩放），在 Kubernetes v1.27 中首次引入为 Alpha 版本，现在已升级为 Beta 版本，并将在 Kubernetes v1.33 发行版中默认启用！这标志着 Kubernetes 工作负载的资源管理变得更加灵活和不那么具有干扰性的一个重要里程碑。

什么是原地 Pod 调整大小？

传统上，更改分配给容器的 CPU 或内存资源需要重启 Pod。虽然这对于许多无状态应用来说是可以接受的，但这对于有状态服务、批处理作业或任何对重启敏感的工作负载可能会造成干扰。

原地 Pod 调整大小允许你更改运行中的 Pod 内容器的 CPU 和内存请求及限制，通常无需重启容器。

核心思想如下：

Pod 规约中的 spec.containers[*].resources 字段现在代表期望的资源，并且对于 CPU 和内存是可变更的。
status.containerStatuses[*].resources 字段反映当前运行容器上已配置的实际资源。
你可以通过新的 resize 子资源更新 Pod 规约中的期望资源来触发调整大小。

你可以在 v1.33 的 Kubernetes 集群上使用 kubectl 编辑 Pod 来尝试（需要 v1.32+ 的 kubectl）：

kubectl edit pod <Pod 名称> --subresource resize

有关详细使用说明和示例，请参阅官方 Kubernetes 文档：调整分配给容器的 CPU 和内存资源。

为什么原地 Pod 调整大小很重要？

Kubernetes 在水平扩缩工作负载（添加或移除副本）方面仍然表现出色，但原地 Pod 调整大小为垂直扩缩解锁了几个关键优势：

减少干扰： 有状态应用、长时间运行的批处理作业和敏感工作负载可以在不经历 Pod 重启相关的停机或状态丢失的情况下调整资源。
改进资源利用率： 无需中断即可缩小过度配置的 Pod，从而释放集群中的资源。相反，在重负载下的 Pod 可以在不重启的情况下获得更多的资源。
更快的扩缩： 更快速地解决瞬时资源需求。例如，Java 应用在启动期间通常比在稳定状态下需要更多的 CPU。可以开始时使用更高的 CPU 配置，然后在之后调整减小。

从 Alpha 到 Beta 有哪些变化？

自从 v1.27 的 Alpha 版本发布以来，为了完善此特性、提高其稳定性并根据反馈和进一步开发优化用户体验，已经进行了大量工作。以下是关键变化：

显著的用户可感知的变化

resize 子资源： 修改 Pod 资源现在必须通过 Pod 的 resize 子资源进行（kubectl patch pod <name> --subresource resize ...）。 kubectl 版本 v1.32+ 支持此参数。
通过状况显示调整大小状态： 旧的 status.resize 字段已被弃用。调整大小操作的状态现在通过两个 Pod 状况暴露：
- PodResizePending：表示 kubelet 无法立即批准调整大小（例如，如果暂时不能，则 reason: Deferred；如果在节点上不可能，则 reason: Infeasible）。
- PodResizeInProgress：表示调整大小已被接受并正在应用。在此阶段遇到的错误现在会在此状况的消息中报告为 reason: Error。
支持边车容器： 现在支持对边车容器进行原地调整大小。

稳定性和可靠性增强

改进的已分配资源管理： 对 Kubelet 的分配管理逻辑进行了重大重新设计，使其更加一致和稳健。这些更改消除了很多种错误，并大大提高了原地 Pod 调整大小的可靠性。

改进的检查点操作和状态跟踪操作： 实现了更健壮的系统来跟踪“已分配”和“已执行”的资源，使用新的检查点文件（allocated_pods_state，actuated_pods_state）以可靠地管理 kubelet 重启时的调整大小状态，并处理运行时报告的资源与请求的资源不同的边缘情况。修复了几个与检查点和状态恢复相关的错误。还提高了检查点的效率。

更快的调整大小检测： 对 kubelet 的 Pod 生命周期事件生成器（PLEG）进行了增强，使 kubelet 能够更快地响应并完成大小调整。
增强的 CRI 集成： 添加了新的 UpdatePodSandboxResources CRI 调用，以更好地通知运行时和插件（如 NRI）有关 Pod 级别的资源变化。
众多 Bug 修复： 解决了与 systemd CGroup 驱动程序、未设资源限制的容器的处理、CPU 最小份额计算、容器重启退避、错误传播、测试稳定性等相关的问题。

接下来是什么？

晋升为 Beta 意味着该特性已经准备好被更广泛地采用，但开发工作并不会止步于此！以下是社区接下来的关注重点：

稳定性和产品化： 持续关注增强特性，提升性能，并确保它在生产环境中足够稳健。
解决限制： 致力于解除文档中提到的一些当前限制，例如允许降低内存限制值。

垂直 Pod 自动扩缩（VPA）集成： 此任务正在进行，为的是使 VPA 能够利用原地 Pod 重新调整大小。一个新的 InPlaceOrRecreate 更新模式将允许它首先尝试非干扰性的重新调整大小，或者在需要时回退到重建。这将使用户能够受益于 VPA 的建议，并显著减少干扰。
用户反馈： 收集采用 Beta 版特性的用户反馈，对于优先处理后续的增强特性以及解决发现的任何问题或错误至关重要。

开始使用并提供反馈

随着 InPlacePodVerticalScaling 特性门控在 v1.33 中默认启用，你可以立即开始尝试原地 Pod 资源调整大小！

参考文档获取详细的指南和示例。

随着此特性从 Beta 阶段逐步推进，你的反馈是无价的。请通过 Kubernetes 标准沟通渠道（GitHub Issues、邮件列表、Slack）报告任何问题或分享你的经验。你也可以查看 KEP-1287: In-place Update of Pod Resources 以获取完整的深入设计细节。

我们期待看到社区如何利用原地 Pod 调整大小来构建更高效、弹性更好的 Kubernetes 应用！

Kubernetes 1.33：Job 的 SuccessPolicy 进阶至 GA

Thu, 15 May 2025 10:30:00 -0800

我代表 Kubernetes 项目组，很高兴地宣布在 v1.33 版本中，Job 的成功策略已进阶至 GA（正式发布）。

关于 Job 的成功策略

在批处理工作负载中，你可能希望使用类似 MPI（消息传递接口）的领导者跟随者（leader-follower）模式，其中领导者控制执行过程，包括跟随者的生命周期。

在这种情况下，即使某些索引失败了，你也可能希望将 Job 标记为成功。然而，在没有使用成功策略的情况下，Kubernetes 中的领导者跟随者 Job 通常必须要求所有 Pod 成功完成，整个 Job 才会被视为成功。

对于 Kubernetes Job，API 允许你通过 .spec.successPolicy 字段指定提前退出的条件（你只能将此字段用于带索引的 Job）。此字段通过使用已成功的索引列表或定义成功索引的最小数量来描述一组规则。

这个全新的稳定字段对科学仿真、AI/ML 和高性能计算（HPC）等批处理工作负载特别有价值。这些领域的用户通常会运行大量实验，而他们可能只需要其中一部分成功完成，而不需要全部成功。在这种情况下，领导者索引失败是对应 Job 的唯一重要退出条件，个别跟随者 Pod 的结果仅通过领导者索引的状态间接被处理。此外，跟随者自身并不知道何时可以终止。

一旦 Job 满足任一成功策略，此 Job 就会被标记为成功，并终止所有 Pod，包括正在运行的 Pod。

工作原理

以下是使用 .successPolicy.rules[0].succeededCount 的 Job 清单片段，这是一个自定义成功策略的例子：

  parallelism: 10
  completions: 10
  completionMode: Indexed
  successPolicy:
    rules:
    - succeededCount: 1

在这里，只要有任意一个索引成功，Job 就会被标记为成功，而不管具体是哪个索引。此外，你还可以基于 .successPolicy.rules[0].succeededCount 限制索引编号，如下所示：

parallelism: 10
completions: 10
completionMode: Indexed
successPolicy:
  rules:
  - succeededIndexes: 0 # 领导者 Pod 的索引
    succeededCount: 1

这个例子表示，只要具有特定索引（Pod 索引 0）的 Pod 成功，整个 Job 就会被标记为成功。

一旦 Job 满足任一条 successPolicy 规则，或根据 .spec.completions 达到其 Complete 条件， kube-controller-manager 中的 Job 控制器就会向 Job 状态添加 SuccessCriteriaMet 状况。之后，job-controller 会为具有 SuccessCriteriaMet 状况的 Job 发起 Pod 的清理和终止。当 job-controller 完成清理和终止后，Job 会获得 Complete 状况。

了解更多

阅读关于成功策略的文档
阅读关于 Job 成功/完成策略的 KEP

加入我们

这项工作由 Kubernetes 的 Batch Working Group（批处理工作组）牵头，并与 SIG Apps 社区密切协作。

如果你对此领域的新特性开发感兴趣，推荐你订阅我们的 Slack 频道，并参加定期举行的社区会议。

Kubernetes v1.33：容器生命周期更新

Wed, 14 May 2025 10:30:00 -0800

Kubernetes v1.33 引入了对容器生命周期的一些更新。容器生命周期回调的 Sleep 动作现在支持零睡眠时长（特性默认启用）。同时还为定制发送给终止中的容器的停止信号提供了 Alpha 级别支持。

这篇博客文章深入介绍了容器生命周期的这些新内容，以及如何使用它们。

Sleep 动作的零值

Kubernetes v1.29 引入了容器 PreStop 和 PostStart 生命周期回调的 Sleep 动作。 Sleep 动作允许你的容器在启动后或终止前暂停指定的时长。这为管理优雅关闭提供了一种直接的方法。在 Sleep 动作之前，人们常使用生命周期回调中的 exec 动作运行 sleep 命令。如果你想这样做，则需要在你的容器镜像中包含 sleep 命令的二进制文件。如果你使用第三方镜像，这可能会比较困难。

最初添加 Sleep 动作时，并不支持零秒的睡眠时间。然而，time.Sleep（Sleep 动作底层使用的机制）是支持零秒的持续时间的。使用负值或零值进行睡眠会立即返回，导致无操作。我们希望 Sleep 动作也有相同的行为。后来在 v1.32 中通过特性门控 PodLifecycleSleepActionAllowZero 添加了这种对零持续时间的支持。

PodLifecycleSleepActionAllowZero 特性门控在 v1.33 中已升级到 Beta 阶段，并且现在默认启用。从 Kubernetes v1.30 开始，preStop 和 postStart 回调的原始 Sleep 动作默认情况下已启用。使用运行 Kubernetes v1.33 的集群时，你可以为 Sleep 生命周期钩子设置零持续时间。对于采用默认配置的集群，你无需启用任何特性门控即可实现这一点。

容器停止信号

容器运行时如 containerd 和 CRI-O 支持容器镜像定义中的 StopSignal 指令。这可以用来指定一个自定义的停止信号，运行时将使用该信号来终止基于此镜像的容器。停止信号配置最初并不是 Kubernetes Pod API 的一部分。直到 Kubernetes v1.33，覆盖容器停止信号的唯一方法是通过使用新的自定义停止信号重建容器镜像（例如，在 Containerfile 或 Dockerfile 中指定 STOPSIGNAL）。

ContainerStopSignals 特性门控是 Kubernetes v1.33 新增的，它将停止信号添加到了 Kubernetes API。这允许用户在容器规格中指定自定义的停止信号。停止信号作为新生命周期加入 API，连同现有的 PreStop 和 PostStart 生命周期处理器一起使用。要使用这个特性，Pod 需要用 spec.os.name 指定操作系统。这是为了能对操作系统进行停止信号的交叉验证，确保 Pod 中的容器是以适合其调度操作系统的有效停止信号创建的。对于调度到 Windows 节点上的 Pod，仅允许 SIGTERM 和 SIGKILL 作为有效的停止信号。这里可以找到 Linux 节点支持的完整信号列表。

默认行为

如果容器在其生命周期中定义了自定义停止信号，那么只要容器运行时也支持自定义停止信号，容器运行时就会使用生命周期中定义的信号来终止容器。如果容器生命周期中没有定义自定义停止信号，运行时将回退到容器镜像中定义的停止信号。如果在容器镜像中也没有定义停止信号，将会使用运行时的默认停止信号。对于 containerd 和 CRI-O，默认信号都是 SIGTERM。

版本偏差

为了使该特性按预期工作，Kubernetes 和容器运行时的版本都应支持容器停止信号。对 Kubernetes API 和 kubelet 的更改从 v1.33 开始进入 Alpha 阶段，可以通过启用 ContainerStopSignals 特性门控来使用。 containerd 和 CRI-O 的容器运行时实现仍在进行中，不久将会发布。

使用容器停止信号

要启用此特性，你需要在 kube-apiserver 和 kubelet 中打开 ContainerStopSignals 特性门控。一旦你在节点上启用了特性门控，就可以创建带有 StopSignal 生命周期和有效操作系统名称的 Pod，如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  os:
    name: linux
  containers:
    - name: nginx
      image: nginx:latest
      lifecycle:
        stopSignal: SIGUSR1

请注意，此示例中的 SIGUSR1 信号仅在容器的 Pod 被调度到 Linux 节点时才能使用。因此，我们需要指定 spec.os.name 为 linux 才能使用该信号。如果 Pod 被调度到 Windows 节点，则你只能配置 SIGTERM 和 SIGKILL 信号。此外，如果 spec.os.name 字段为 nil 或未设置，你也不能指定 containers[*].lifecycle.stopSignal。

我如何参与？

此特性由 SIG Node 推动。如果你有兴趣帮助开发此特性、分享反馈或参与任何其他正在进行的 SIG Node 项目，请联系我们！

你可以通过几种方式联系 SIG Node：

你也可以直接联系我：

GitHub：@sreeram-venkitesh
Slack：@sreeram.venkitesh

Kubernetes v1.33：Job 逐索引的回退限制进阶至 GA

Tue, 13 May 2025 10:30:00 -0800

在 Kubernetes v1.33 中，逐索引的回退限制特性进阶至 GA（正式发布）。本文介绍此特性及其优势。

关于逐索引的回退限制

当你在 Kubernetes 上运行工作负载时，必须考虑 Pod 失效可能影响工作负载完成的场景。理想情况下，你的工作负载应该能够容忍短暂的失效并继续运行。

为了在 Kubernetes Job 中容忍失效，你可以设置 spec.backoffLimit 字段。此字段指定容忍的失效总数。

但是，对于每个索引都被视为独立单元的工作负载，比如过易并行的工作负载， spec.backoffLimit 字段通常不够灵活。例如，你可以选择运行多个继承测试套件，将每个套件作为带索引的 Job内的某个索引。在这种情况下，快速失效的索引（测试套件）很可能消耗你全部的 Pod 失效容忍预算，你可能无法运行其他索引的 Pod。

为了解决这一限制，Kubernetes 引入了逐索引的回退限制，允许你控制逐索引的重试次数。

逐索引回退限制的工作原理

要在带索引的 Job 中使用逐索引的回退限制，可以通过 spec.backoffLimitPerIndex 字段指定每个索引允许的 Pod 失效次数。当你设置此字段后，Job 默认将执行所有索引。

另外，你可以通过以下方式微调错误处理：

通过设置 spec.maxFailedIndexes 字段，指定失效索引总数的上限。超过此限制时，整个 Job 会被终止。
通过 Pod 失效策略机制中的 FailIndex 动作定义短路来检测失效的索引。

当超过容忍的失效次数时，Job 会将该索引标记为失效，并在 Job 的 status.failedIndexes 字段中列出该索引。

示例

下面的 Job 规约片段展示了如何将逐索引的回退限制与 Pod 失效策略特性结合使用：

completions: 10
parallelism: 10
completionMode: Indexed
backoffLimitPerIndex: 1
maxFailedIndexes: 5
podFailurePolicy:
  rules:
  - action: Ignore
    onPodConditions:
    - type: DisruptionTarget
  - action: FailIndex
    onExitCodes:
      operator: In
      values: [ 42 ]

在此例中，Job 对 Pod 失效的处理逻辑如下：

忽略具有内置干扰状况（称为 DisruptionTarget）的失效 Pod。这些 Pod 不计入 Job 的回退限制。
如果失效的 Pod 中任何容器的退出码是 42，则基于匹配的 FailIndex 规则，将对应的索引标记为失效。

除非索引因匹配的 FailIndex 规则失效，否则会重试该索引的首次失效。
如果失效索引数量超过 5 个（由 spec.maxFailedIndexes 设置），则整个 Job 失效。

进一步了解

阅读与 Pod 失效策略密切相关的博客文章：Kubernetes 1.31：Job 的 Pod 失效策略进阶至 GA
查看包含 FailIndex 用法在内的 Pod 失效策略实操指南：使用 Pod 失效策略处理可重试和不可重试的 Pod 失效
阅读逐索引的回退限制和 Pod 失效策略等文档
查阅 KEP：带索引的 Job 的逐索引回退限制

参与此工作

这项工作由 Kubernetes Batch Working Group（批处理工作组）负责，且与 SIG Apps 社区密切协作。

如果你有兴趣参与此领域的新特性开发，建议订阅我们的 Slack 频道，并参加定期社区会议。

Kubernetes v1.33：镜像拉取策略终于按你的预期工作了！

Mon, 12 May 2025 10:30:00 -0800

镜像拉取策略终于按你的预期工作了！

Kubernetes 中有些东西让人感到奇怪，imagePullPolicy 的行为就是其中之一。 Kubernetes 作为一个专注于运行 Pod 的平台，居然在限制 Pod 访问经认证的镜像方面，存在一个长达十余年的问题，详见 Issue 18787！ v1.33 解决了这个十年前的老问题，这真是一个有纪念意义的版本。

说明：

在本博文中，“Pod 凭据”这个术语将被频繁使用。在这篇博文的上下文中，这一术语通常指的是 Pod 拉取容器镜像时可用于身份认证的认证材料。

IfNotPresent：即使我本不该有这个镜像

问题的本质在于，imagePullPolicy: IfNotPresent 策略正如其字面意义所示，仅此而已。我们来设想一个场景：Pod A 运行在 Namespace X 中，被调度到 Node 1，此 Pod 需要从某个私有仓库拉取镜像 Foo。此 Pod 在 imagePullSecrets 中引用 Secret 1 来作为镜像拉取认证材料。Secret 1 包含从私有仓库拉取镜像所需的凭据。 kubelet 将使用 Pod A 提供的 Secret 1 来拉取 镜像 Foo，这是预期的（也是安全的）行为。

但现在情况变得奇怪了。如果 Namespace Y 中的 Pod B 也被调度到 Node 1，就会出现意外（甚至是不安全）的情况。 Pod B 可以引用同一个私有镜像，指定 IfNotPresent 镜像拉取策略。 Pod B 未在其 imagePullSecrets 中引用 Secret 1（甚至未引用任何 Secret）。当 kubelet 尝试运行此 Pod 时，它会采用 IfNotPresent 策略。 kubelet 发现本地已存在镜像 Foo，会将镜像 Foo 提供给 Pod B。即便 Pod B 一开始并未提供授权拉取镜像的凭据，却依然能够运行此镜像。

使用由另一个 Pod 拉取的私有镜像

虽然 IfNotPresent 不应在节点上已存在镜像 Foo 的情况下再拉取此镜像，但允许将所有 Pod 调度到有权限访问之前已拉取私有镜像的节点上，这从安全态势讲是不正确的做法。因为这些 Pod 从开始就未被授权拉取此镜像。

IfNotPresent：但前提是我有权限

在 Kubernetes v1.33 中，SIG Auth 和 SIG Node 终于开始修复这个（非常古老的）难题，并经过验证可行！基本的预期行为没有变。如果某镜像不存在，kubelet 会尝试拉取此镜像。利用每个 Pod 提供的凭据来完成此拉取任务。这与 v1.33 之前的行为相匹配。

但如果镜像存在，kubelet 的行为就变了。 kubelet 现在先要验证 Pod 的凭据，然后才会允许 Pod 使用镜像。

在修缮此特性时，我们也考虑到了性能和服务稳定性。如果多个 Pod 使用相同的凭据，则无需重复认证。即使这些 Pod 使用的是相同的 Kubernetes Secret 对象（即便其凭据已轮换），也同样适用。

Never：永不拉取，但使用前仍需鉴权

采用 imagePullPolicy: Never 选项时，不会获取镜像。但如果节点上已存在此容器镜像，任何尝试使用此私有镜像的 Pod 都需要提供凭据，并且这些凭据需要经过验证。

使用相同凭据的 Pod 无需重新认证。未提供之前已成功拉取镜像所用凭据的 Pod，将不允许使用此私有镜像。

Always：鉴权通过后始终拉取

imagePullPolicy: Always 一直以来都能按预期工作。每次某镜像被请求时，请求会流转到镜像仓库，镜像仓库将执行身份认证检查。

过去，为了确保你的私有容器镜像不会被节点上已拉取过镜像的其他 Pod 重复使用，通过 Pod 准入来强制执行 Always 镜像拉取策略是唯一的方式。

幸运的是，这个过程相对高效：仅拉取镜像清单，而不是镜像本体。但这依然带来代价与风险。每当发布新版本、扩容或重启 Pod 时，提供镜像的镜像仓库必须可以接受认证检查，从而将镜像仓库放到关键路径中确保集群中所运行的服务的稳定性。

工作原理

此特性基于每个节点上存在的持久化文件缓存。以下简要说明了此特性的工作原理。完整细节请参见 KEP-2535。

首次请求某镜像的流程如下：

请求私有仓库中某镜像的 Pod 被调度到某节点。
此镜像在节点上不存在。
kubelet 记录一次拉取镜像的意图。
kubelet 从 Pod 引用的 Kubernetes Secret 中提取凭据作为镜像拉取 Secret，并使用这些凭据从私有仓库拉取镜像。

镜像已成功拉取后，kubelet 会记录这次成功的拉取。记录包括所使用的凭据细节（哈希格式）以及构成这些凭据的原始 Secret。
kubelet 移除原始意图记录。
kubelet 保留成功拉取的记录供后续使用。

当以后调度到同一节点的 Pod 请求之前拉取过的私有镜像：

kubelet 检查新 Pod 为拉取镜像所提供的凭据。
如果这些凭据的哈希或其源 Secret 与之前成功拉取记录的哈希或源 Secret 相匹配，则允许此 Pod 使用之前拉取的镜像。
如果在该镜像的成功拉取记录中找不到这些凭据或其源 Secret，则 kubelet 将尝试使用这些新的凭据从远程仓库进行拉取，同时触发认证流程。

试用

在 Kubernetes v1.33 中，我们发布了此特性的 Alpha 版本。要想试用，在 kubelet v1.33 上启用 KubeletEnsureSecretPulledImages 特性门控。

你可以在 Kubernetes 官方文档中的镜像概念页中了解此特性和更多可选配置的细节。

下一步工作

在未来的版本中，我们将：

使此特性与 kubelet 镜像凭据提供程序的投射服务账号令牌协同工作，后者能够添加新的、特定于工作负载的镜像拉取凭据源。
编写基准测试套件，以评估此特性的性能并衡量后续变更的影响。
实现内存中的缓存层，因此我们不需要为每个镜像拉取请求都读取文件。
添加对凭据过期的支持，从而强制重新认证之前已验证过的凭据。

如何参与

阅读 KEP-2535 是深入理解这些变更的绝佳方式。

如果你想进一步参与，可以加入 Kubernetes Slack 频道 #sig-auth-authenticators-dev （如需邀请链接，请访问 https://slack.k8s.io/）。欢迎你参加每隔一周在星期三举行的 SIG Auth 双周例会。

Kubernetes v1.33：流式 List 响应

Fri, 09 May 2025 10:30:00 -0800

随着基础设施的增长，管理 Kubernetes 集群的稳定性变得愈发重要。在大规模集群的运维中，最具挑战性的操作之一就是处理获取大量数据集的 List 请求。 List 请求是一种常见的操作，却可能意外影响集群的稳定性。

今天，Kubernetes 社区非常高兴地宣布一项重大的架构改进：对 List 响应启用流式编码。

问题：大型资源导致的不必要内存消耗

当前的 API 响应编码器会将整个响应序列化为一个连续的内存块，并通过一次 ResponseWriter.Write 调用将数据发送给客户端。尽管 HTTP/2 能够将响应拆分为较小的帧进行传输，但底层的 HTTP 服务器仍然会将完整的响应数据保存在一个单一缓冲区中。即使这些帧被逐步传输到客户端，与这些帧关联的内存也无法被逐步释放。

随着集群规模的扩大，单个响应体可能非常庞大，可能达到几百兆字节。在大规模环境下，当前的方式显得特别低效，因为它使得系统无法在传输过程中逐步释放内存。想象一下，如果网络发生拥堵，那么大型响应体的内存块会持续占用数十秒甚至几分钟。这一局限性导致 kube-apiserver 进程出现不必要的高内存占用，持续时间也很长。如果多个大型 List 请求同时发生，累计的内存消耗可能迅速飙升，最终可能触发 OOM（内存溢出）事件，从而危及集群稳定性。

encoding/json 包在序列化时使用了 sync.Pool 来复用内存缓冲区。这对于一致的工作负载来说是高效的，但在处理偶发性的大型 List 响应时却带来了新的挑战。在处理这些大型响应时，内存池会迅速膨胀。而由于 sync.Pool 的设计特性，这些膨胀后的缓冲区在使用后仍然会保留。后续的小型 List 请求继续使用这些大型内存分配，导致垃圾回收无法生效，使得 kube-apiserver 在处理完大型响应后仍然保持较高的内存占用。

此外，Protocol Buffers（协议缓冲）并不适合处理大型数据集。但它非常适合处理大型数据集中的单个消息。这凸显出采用基于流式处理方式的必要性，这种方式可以逐步处理和传输大型集合，而不是一次性处理整个数据块。

一个通用的经验法则是：如果你处理的消息每个都大于一兆字节，那么可能需要考虑替代策略。

引自：https://protobuf.dev/programming-guides/techniques/

List 响应的流式编码器

流式编码机制是专门为 List 响应设计的，它利用了这类响应通用且定义良好的集合结构。核心思想是聚焦于集合结构中的 Items 字段，此字段在大型响应中占用了大部分内存。新的流式编码器不再将整个 Items 数组编码为一个连续的内存块，而是逐个处理并传输每个 Item，从而在传输每个帧或数据块后可以逐步释放内存。逐项编码显著减少了 API 服务器所需的内存占用。

考虑到 Kubernetes 对象通常限制在 1.5 MiB（由 ETCD 限制），流式编码可使内存占用更加可预测和易于管理，无论 List 响应中包含多少个对象。其结果是大幅提升了 API 服务器的稳定性，减少了内存峰值，并改善了整体集群性能，尤其是在同时发生多个大型 List 操作的环境下更是如此。

为了确保完全向后兼容，流式编码器在启用前会严格验证 Go 结构体标签，确保与原始编码器在字节级别上保持一致。标准编码机制仍然会处理除 Items 外的所有字段，从而保持输出格式的一致性。这种方法无缝支持所有 Kubernetes 的 List 类型（从内置的 *List 对象到自定义资源的 UnstructuredList 对象）客户端无需任何修改，也无需感知底层的编码方式是否已发生变化。

肉眼可见的性能提升

内存消耗降低： 当处理大型 list 请求，尤其是涉及大型资源时，API 服务器的内存占用大幅下降。
可扩展性提升： 允许 API 服务器处理更多并发请求和更大数据集，而不会耗尽内存。
稳定性增强： 降低 OOM 被杀和服务中断的风险。
资源利用率提升： 优化内存使用率，提高整体资源效率。

基准测试结果

为了验证效果，Kubernetes 引入了一个新的 list 基准测试，同时并发执行 10 个 list 请求，每个请求返回 1GB 数据。

此基准测试显示内存使用量下降了 20 倍，从 70–80GB 降低到了 3GB。

List 基准测试内存使用量

Kubernetes 1.33：卷填充器进阶至 GA

Thu, 08 May 2025 10:30:00 -0800

Kubernetes 的卷填充器现已进阶至 GA（正式发布）！ AnyVolumeDataSource 特性门控在 Kubernetes v1.33 中设为始终启用，这意味着用户可以将任何合适的自定义资源作为 PersistentVolumeClaim（PVC）的数据源。

以下是如何在 PVC 中使用 dataSourceRef 的示例：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  ...
  dataSourceRef:
    apiGroup: provider.example.com
    kind: Provider
    name: provider1

新变化

从 Beta 进阶到 GA 后，主要有四个增强。

填充器 Pod 成为可选

在 Beta 阶段，Kubernetes 的贡献者们发现当正在进行卷填充时删除 PersistentVolumeClaim（PVC）可能导致资源泄露问题，这些泄漏是由于 Finalizer 处理机制的局限性所致。在进阶至 GA 之前，Kubernetes 项目增加了在原始 PVC 被删除时对删除临时资源（PVC 派生体等）的支持。

为支持此能力，我们引入了三个基于插件的新函数：

PopulateFn()：执行特定于提供程序的数据填充逻辑。
PopulateCompleteFn()：检查数据填充操作是否成功完成。
PopulateCleanupFn()：在数据填充完成后，清理由提供程序特定函数创建的临时资源。

有关提供程序的例子，参见 lib-volume-populator/example。

支持修改 Kubernetes 资源的 Mutator 函数

在 GA 版本中，CSI 卷填充器控制器代码新增了 MutatorConfig，允许指定 Mutator 函数用于修改 Kubernetes 资源。例如，如果 PVC 派生体不是 PVC 的完美副本，并且你需要为驱动提供一些特定于提供程序的信息，你可以通过可选的 MutatorConfig 将这些信息加入。这使你能够自定义卷填充器中的 Kubernetes 对象。

灵活处理提供程序的指标

在 Beta 阶段，我们发现一个新需求：不仅需要从 lib-volume-populator 聚合指标，还要能够从提供程序代码库中的其他组件聚合指标。

为此，SIG Storage 引入了一个提供程序指标管理器。此增强特性将指标逻辑的实现委托给提供程序自身，而不再仅仅依赖于 lib-volume-populator。这种转变使指标收集与聚合更灵活、更好控制，有助于更好地观察提供程序的总体性能。

清理临时资源

在 Beta 阶段，我们发现当卷填充过程尚未完成时删除 PVC 会导致资源泄露问题，这是由于 Finalizer 的局限性引起的。在 GA 版本中，我们改善了填充器特性，在原始 PVC 被删除时支持删除临时资源（如 PVC 派生体等）。

如何使用

如需试用，请参考之前 Beta 版本博客中的操作步骤。

后续方向与潜在特性请求

下一阶段，卷填充器可能会引入以下特性请求：

多次同步：当前实现是从源到目的地的一次性单向同步，可以扩展为支持周期性同步或允许用户按需同步。
双向同步：多次同步的扩展版本，实现源与目的地之间的双向同步。
基于优先级的数据填充：提供多个 dataSourceRef，并按优先级进行数据填充。
从同一提供程序的多个源填充数据：将多个不同源填充到同一个目的地。
从不同提供程序的多个源填充数据：将多个不同源填充到一个目的地，支持流水线式的不同资源的填充。

为了确保我们构建的特性真正有价值，Kubernetes SIG Storage 非常希望了解你所知道的与此特性有关的任何具体使用场景。如有任何关于卷填充器的疑问或特定问题，请联系 SIG Storage 社区。

Kubernetes v1.33：防止无序删除时 PersistentVolume 泄漏特性进阶到 GA

Mon, 05 May 2025 10:30:00 -0800

我很高兴地宣布，当无序删除时防止 PersistentVolume（简称 PV）泄漏的特性已经在 Kubernetes v1.33 中进阶为正式版（GA）！这项改进最初在 Kubernetes v1.31 中作为 Beta 特性引入，确保你的存储资源能够被正确回收，防止不必要的泄漏。

以前的 Kubernetes 版本中 reclaim 是如何工作的？

PersistentVolumeClaim（简称 PVC）是用户对存储的请求。如果创建了新的 PV 或找到了匹配的 PV，则认为 PV 和 PVC 是绑定的。 PV 本身由存储后端分配的卷支持。

通常，如果卷需要被删除，则预期是删除绑定的 PV-PVC 对的 PVC。但是，删除 PVC 之前并没有限制不能删除 PV。

对于一个“已绑定”的 PV-PVC 对，PV 和 PVC 的删除顺序决定了是否遵守 PV 回收策略。如果先删除 PVC，则会遵守回收策略；然而，如果在删除 PVC 之前删除了 PV，则不会执行回收策略。因此，外部基础设施中相关的存储资源不会被移除。

在 Kubernetes v1.33 中的 PV 回收策略

随着在 Kubernetes v1.33 中升级为 GA，这个问题现在得到了解决。 Kubernetes 现在可靠地遵循配置的 Delete 回收策略（即使在删除 PV 时，其绑定的 PVC 尚未被删除）。这是通过使用 Finalizer 来实现的，确保存储后端如预期释放分配的存储资源。

它是如何工作的？

对于 CSI 卷，新的行为是通过在新创建和现有的 PV 上添加 Finalizer external-provisioner.volume.kubernetes.io/finalizer 来实现的。只有在后端存储被删除后，Finalizer 才会被移除。

下面是一个带 Finalizer 的 PV 示例，请注意 Finalizer 列表中的新 Finalizer：

kubectl get pv pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53 -o yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: csi.example.driver.com
  creationTimestamp: "2021-11-17T19:28:56Z"
  finalizers:
  - kubernetes.io/pv-protection
  - external-provisioner.volume.kubernetes.io/finalizer
  name: pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53
  resourceVersion: "194711"
  uid: 087f14f2-4157-4e95-8a70-8294b039d30e
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: example-vanilla-block-pvc
    namespace: default
    resourceVersion: "194677"
    uid: a7b7e3ba-f837-45ba-b243-dec7d8aaed53
  csi:
    driver: csi.example.driver.com
    fsType: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.example.driver.com
      type: CNS Block Volume
    volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
  persistentVolumeReclaimPolicy: Delete
  storageClassName: example-vanilla-block-sc
  volumeMode: Filesystem
status:
  phase: Bound

Finalizer 防止此 PersistentVolume 从集群中被移除。如前文所述，Finalizer 仅在从存储后端被成功删除后才会从 PV 对象中被移除。进一步了解 Finalizer，请参阅使用 Finalizer 控制删除。

同样，Finalizer kubernetes.io/pv-controller 也被添加到动态制备的树内插件卷中。

重要提示

此修复不适用于静态制备的内置插件卷。

如何启用新行为？

要利用新行为，你必须将集群升级到 Kubernetes 的 v1.33 版本，并运行 CSI external-provisioner 5.0.1 或更新版本。此特性在 Kubernetes 的 v1.31 版本中作为 Beta 版发布，并且默认启用。

参考

如何参与？

Kubernetes Slack 频道 SIG Storage 交流渠道是接触 SIG Storage 和迁移工作组团队的绝佳方式。

特别感谢以下人员的深入审查、细致考虑和宝贵贡献：

Fan Baofa (carlory)
Jan Šafránek (jsafrane)
Xing Yang (xing-yang)
Matthew Wong (wongma7)

如果你对 CSI 或 Kubernetes 存储系统的任何部分的设计和开发感兴趣，可以加入 Kubernetes 存储特别兴趣小组（SIG）。我们正在迅速成长，并且总是欢迎新的贡献者。

Kubernetes v1.33：可变的 CSI 节点可分配数

Fri, 02 May 2025 10:30:00 -0800

可靠调度有状态应用极度依赖于节点上资源可用性的准确信息。
Kubernetes v1.33 引入一个名为可变的 CSI 节点可分配计数的 Alpha 特性，允许 CSI（容器存储接口）驱动动态更新节点可以处理的最大卷数量。
这一能力显著提升 Pod 调度决策的准确性，并减少因卷容量信息过时而导致的调度失败。

背景

传统上，Kubernetes 中的 CSI 驱动在初始化时会报告一个静态的最大卷挂接限制。然而，在节点生命周期内，实际的挂接容量可能会由于多种原因发生变化，例如：

在 Kubernetes 控制之外的手动或外部操作挂接/解除挂接卷。
动态挂接的网络接口或专用硬件（如 GPU、NIC 等）占用可用的插槽。
在多驱动场景中，一个 CSI 驱动的操作会影响另一个驱动所报告的可用容量。

静态报告可能导致 Kubernetes 将 Pod 调度到看似有容量但实际没有的节点上，进而造成 Pod 长时间卡在 ContainerCreating 状态。

动态适应 CSI 卷限制

借助新的特性门控 MutableCSINodeAllocatableCount，Kubernetes 允许 CSI 驱动在运行时动态调整并报告节点的挂接容量。如此确保调度器能获取到最准确、最新的节点容量信息。

工作原理

启用此特性后，Kubernetes 支持通过以下两种机制来更新节点卷限制的报告值：

周期性更新： CSI 驱动指定一个间隔时间，来定期刷新节点的可分配容量。
响应式更新： 当因资源耗尽（ResourceExhausted 错误）导致卷挂接失败时，立即触发更新。

启用此特性

要使用此 Alpha 特性，你必须在以下组件中启用 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 秒，以平衡准确性和资源使用量。

挂接失败时的即时更新

除了周期性更新外，Kubernetes 现在也能对挂接失败做出响应。
具体来说，如果卷挂接由于 ResourceExhausted 错误（gRPC 错误码 8）而失败，将立即触发更新，以快速纠正可分配数量。

这种主动纠正可以防止重复的调度错误，有助于保持集群的健康状态。

快速开始

要在 Kubernetes v1.33 集群中试用可变的 CSI 节点可分配数：

在 kube-apiserver 和 kubelet 组件上启用特性门控 MutableCSINodeAllocatableCount。
在 CSI 驱动配置中设置 nodeAllocatableUpdatePeriodSeconds。
监控并观察调度准确性和 Pod 放置可靠性的提升程度。

后续计划

此特性目前处于 Alpha 阶段，Kubernetes 社区欢迎你的反馈。无论是参与测试、分享你的经验，都有助于推动此特性向 Beta 和 GA（正式发布）稳定版迈进。

欢迎加入 Kubernetes SIG-Storage 的讨论，共同塑造 Kubernetes 存储能力的未来。

Kubernetes v1.33：存储动态制备模式下的节点存储容量评分（Alpha 版）

Wed, 30 Apr 2025 10:30:00 -0800

Kubernetes v1.33 引入了一个名为 StorageCapacityScoring 的新 Alpha 级别特性。此特性添加了一种为 Pod 调度评分的方法，并与拓扑感知卷制备相关。此特性可以轻松地选择在具有最多或最少可用存储容量的节点上调度 Pod。

关于此特性

此特性扩展了 kube-scheduler 的 VolumeBinding 插件，以使用从存储容量获得的节点存储容量信息进行评分。目前，你只能过滤掉存储容量不足的节点。因此，你必须使用调度器扩展程序来实现基于存储容量的 Pod 调度。

此特性对于制备节点本地的 PV 非常有用，这些 PV 的大小限制取决于节点的存储容量。通过使用此特性，你可以将 PV 指派给具有最多可用存储空间的节点，以便以后尽可能多地扩展 PV。

在另一个用例中，你可能希望通过选择存储容量最小的节点，在云环境中尽可能减少节点数量以降低运维成本。此特性通过从利用率最高的节点开始填充节点，从而帮助最大化资源利用率，前提是这些节点仍有足够的存储容量来满足请求的卷大小。

如何使用

启用此特性

在 Alpha 阶段，StorageCapacityScoring 默认是禁用的。要使用此特性，请将 StorageCapacityScoring=true 添加到 kube-scheduler 命令行选项 --feature-gates 中。

配置更改

你可以使用 VolumeBinding 插件配置中的 shape 参数，根据存储利用率来配置节点优先级。这允许你优先考虑具有更高可用存储容量（默认）的节点，或者相反，优先考虑具有更低可用存储容量的节点。例如，要优先考虑更低的可用存储容量，请按如下方式配置 KubeSchedulerConfiguration：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  ...
  pluginConfig:
  - name: VolumeBinding
    args:
      ...
      shape:
      - utilization: 0
        score: 0
      - utilization: 100
        score: 10

详情请参阅文档。

进一步阅读

KEP-4049: Storage Capacity Scoring of Nodes for Dynamic Provisioning

附加说明：与 VolumeCapacityPriority 的关系

基于静态配置期间的可用存储容量进行节点评分的 Alpha 特性门控 VolumeCapacityPriority，将被弃用，并由 StorageCapacityScoring 替代。

请注意，虽然 VolumeCapacityPriority 默认优先考虑可用存储容量较低的节点，但 StorageCapacityScoring 默认优先考虑可用存储容量较高的节点。

Kubernetes v1.33：镜像卷进阶至 Beta！

Tue, 29 Apr 2025 10:30:00 -0800

镜像卷作为 Alpha 特性首次引入 Kubernetes v1.31 版本，并作为 KEP-4639 的一部分发布。在 Kubernetes v1.33 中，此特性进阶至 Beta。

请注意，此特性目前仍默认禁用，因为并非所有的容器运行时都完全支持此特性。 CRI-O 自 v1.31 起就支持此初始特性，并将在 v1.33 中添加对镜像卷的 Beta 支持。 containerd 已合并对 Alpha 特性的支持，此特性将包含在 containerd v2.1.0 版本中，并正通过 PR #11578 实现对 Beta 的支持。

新增内容

镜像卷进阶为 Beta 的主要变化是支持通过 spec.containers[*].volumeMounts.[subPath,subPathExpr] 配置容器的 subPath 和 subPathExpr 挂载。这允许最终用户在保持只读（noexec）方式挂载的同时可以挂载某镜像卷中的某个子目录。这意味着默认情况下无法挂载不存在的子目录。与其他 subPath 和 subPathExpr 取值一样， Kubernetes 将确保所指定的子路径中不包含绝对路径或相对路径成分。出于安全考虑，容器运行时也需要再次验证这些要求。如果指定的子目录在卷中不存在，则运行时应在创建容器时失败，并通过现有的 kubelet 事件向用户提供反馈。

除此之外，还为镜像卷新增三个 kubelet 指标：

kubelet_image_volume_requested_total：统计请求镜像卷的数量。
kubelet_image_volume_mounted_succeed_total：统计镜像卷成功挂载的数量。
kubelet_image_volume_mounted_errors_total：统计镜像卷挂载失败的数量。

若要为特定镜像卷使用已有的子目录，只需将其用作容器 volumeMounts 的 subPath 或 subPathExpr 取值：

apiVersion: v1
kind: Pod
metadata:
  name: image-volume
spec:
  containers:
  - name: shell
    command: ["sleep", "infinity"]
    image: debian
    volumeMounts:
    - name: volume
      mountPath: /volume
      subPath: dir
  volumes:
  - name: volume
    image:
      reference: quay.io/crio/artifact:v2
      pullPolicy: IfNotPresent

然后，在集群中创建 Pod：

kubectl apply -f image-volumes-subpath.yaml

现在你可以挂接到容器：

kubectl attach -it image-volume bash

并查看卷中 dir 子路径下的文件内容：

cat /volume/file

输出将类似于：

感谢你读完本博文！SIG Node 团队非常自豪和高兴地在 Kubernetes v1.33 中交付此特性的进阶版本。

作为本文作者，我要特别感谢参与开发此特性的所有人！

如果你有任何反馈或建议，欢迎通过 Kubernetes Slack (#sig-node) 频道或 SIG Node 邮件列表与 SIG Node 团队联系。

进一步阅读

Kubernetes v1.33：HorizontalPodAutoscaler 可配置容差

Mon, 28 Apr 2025 10:30:00 -0800

这篇文章描述了水平 Pod 自动扩缩的可配置容差，这是在 Kubernetes 1.33 中首次出现的一个新的 Alpha 特性。

它是什么？

水平 Pod 自动扩缩是 Kubernetes 中一个众所周知的特性，它允许你的工作负载根据资源利用率自动增减副本数量。

假设你在 Kubernetes 集群中运行了一个具有 50 个副本的 Web 应用程序。你配置了 Horizontal Pod Autoscaler （HPA）根据 CPU 利用率进行扩缩，目标利用率 75%。现在，假设所有副本的当前 CPU 利用率为 90%，这高于预期的 75%。HPA 将使用以下公式计算所需的副本数量：

$$desiredReplicas = ceil\left\lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \right\rceil$$

在此示例中：

$$50 \times (90/75) = 60$$

因此，HPA 将增加副本数量从 50 个提高到 60 个，以减少每个 Pod 的负载。同样，如果 CPU 利用率降至 75% 以下，HPA 会相应地减少副本数量。 Kubernetes 文档提供了扩缩算法的详细描述。

为了避免在指标发生小波动时创建或删除副本， Kubernetes 应用了一种迟滞形式：仅当当前和期望的指标值差异超过 10% 时，才改变副本数量。在上面的例子中，因为当前和期望的指标值比率是 $90/75$，即超出目标 20%，超过了 10% 的容差，所以扩容操作将继续进行。

这个 10% 的默认容差是集群范围的；在旧版本的 Kubernetes 中，它无法进行微调。对于大多数使用场景来说，这是一个合适的值，但对于大型部署而言则过于粗糙，因为 10% 的容差代表着数十个 Pod。因此，社区长期以来要求能够调整这个值。

在 Kubernetes v1.33 中，现在这已成为可能。

我如何使用它？

在你的 Kubernetes v1.33 集群中启用 HPAConfigurableTolerance [特性门控][/zh-cn/docs/reference/command-line-tools-reference/feature-gates/]后，你可以为你的 HorizontalPodAutoscaler 对象添加期望的容差。

容差出现在 spec.behavior.scaleDown 和 spec.behavior.scaleUp 字段下，因此对于扩容和缩容可以有不同的设置。一个典型的用法是在扩容时指定一个小的容差（以快速响应峰值），而在缩容时指定较大的容差（以避免因小的指标波动而过快地添加或移除副本）。

例如，一个在缩容时有 5% 容差，在扩容时没有容差的 HPA 配置如下所示：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  ...
  behavior:
    scaleDown:
      tolerance: 0.05
    scaleUp:
      tolerance: 0

所有细节

通过阅读 KEP-4951 获取所有技术细节，并关注 Issue 4951 以获得特性毕业的通知。

Kubernetes 多容器 Pod：概述

Tue, 22 Apr 2025 00:00:00 +0000

随着云原生架构的不断演进，Kubernetes 已成为部署复杂分布式系统的首选平台。在这个生态系统中，最强大却又微妙的设计模式之一是边车（Sidecar）模式 —— 一种允许开发者扩展应用功能而不深入源代码的技术。

边车模式的起源

想象一下边车就像一个可靠的伴侣摩托车附件。历史上，IT 基础设施总是使用辅助服务来处理关键任务。在容器出现之前，我们依赖后台进程和辅助守护程序来管理日志记录、监控和网络。微服务革命改变了这种方法，使边车成为一种结构化且有意图的架构选择。随着微服务的兴起，边车模式变得更加明确，允许开发者从主服务中卸载特定职责而不改变其代码。诸如 Istio 和 Linkerd 之类的服务网格普及了边车代理，展示了这些伴侣容器如何优雅地处理分布式系统中的可观察性、安全性和流量管理。

Kubernetes 实现

在 Kubernetes 中，边车容器与主应用位于同一个 Pod 内，实现通信和资源共享。这听起来就像是在 Pod 内一起定义多个容器一样？实际上确实如此，这也是在 Kubernetes v1.29.0 引入对边车的本地支持之前实现边车容器的唯一方式。现在，边车容器可以使用 spec.initContainers 字段在 Pod 清单中定义。所指定容器之所以变成了边车容器，是因为你在规约中设置了 restartPolicy: Always 你可以在下面看到一个示例，这是完整 Kubernetes 清单的一个片段：

initContainers:
  - name: logshipper
    image: alpine:latest
    restartPolicy: Always
  command: ['sh', '-c', 'tail -F /opt/logs.txt']
    volumeMounts:
    - name: data
        mountPath: /opt

该字段名称 spec.initContainers 可能听起来令人困惑。为何在定义边车容器时，必须在 spec.initContainers 数组中添加条目？spec.initContainers 在主应用启动前运行至完成，因此它们是一次性的，而边车容器通常与主应用容器并行运行。正是通过带有 restartPolicy:Always 的 spec.initContainers 区分了经典的 Init 容器和 Kubernetes 原生的边车容器，并确保它们始终保持运行。

何时采用（或避免使用）边车

虽然边车模式在许多情况下非常有用，但除非使用场景证明其合理性，否则通常不推荐优先采用这种方法。添加边车会增加复杂性、资源消耗以及可能的网络延迟。因此，应首先考虑更简单的替代方案，例如内置库或共享基础设施。

在以下情况部署边车：

你需要扩展应用功能，而无需修改原始代码
实现日志记录、监控或安全等跨领域关注点
处理需要现代网络功能的遗留应用
设计需要独立扩展和更新的微服务

谨慎行事，如果：

资源效率是你的首要考虑
最小网络延迟至关重要
存在更简单的替代方案
你希望最小化故障排查的复杂性

四个基本的多容器模式

Init 容器模式

Init 容器模式用于在主应用容器启动之前执行（通常是关键的）设置任务。与常规容器不同，Init 容器会运行至完成然后终止，确保满足主应用的前提条件。

适合于：

准备配置
加载密钥
验证依赖项的可用性
运行数据库迁移

Init 容器确保你的应用在一个可预测、受控的环境中启动，而无需修改代码。

Ambassador 模式

一个大使（Ambassador）容器提供了 Pod 本地的辅助服务，这些服务暴露了一种访问网络服务的简单方式。通常，Ambassador 容器代表应用容器发送网络请求，并处理诸如服务发现、对等身份验证或传输中加密等挑战。

能够完美地处理以下需求：

卸载客户端连接问题
实现语言无关的网络功能
添加如 TLS 的安全层
创建强大的断路器和重试机制

配置助手

一个配置助手边车容器动态地向应用提供配置更新，确保它始终可以访问最新的设置而不会中断服务。通常，助手需要在应用能够成功启动之前提供初始配置。

使用场景：

获取环境变量和密钥
轮询配置更改
将配置管理与应用逻辑解耦

适配器模式

一个适配器（adapter）（有时也称为切面（façade））容器使主应用容器与外部服务之间能够互操作。它通过转换数据格式、协议或 API 来实现这一点。

优点：

转换遗留数据格式
搭建通信协议桥梁
帮助不匹配服务之间的集成

总结

尽管边车模式提供了巨大的灵活性，但它不是万能的。所添加的每个边车容器都会引入复杂性、消耗资源，并可能增加操作负担。始终首先评估更简单的替代方案。关键在于战略性实施：将边车用作解决特定架构挑战的精准工具，而不是默认选择。正确使用时，它们可以提升容器化环境中的安全性、网络和配置管理。明智地选择，谨慎地实施，让你的边车提升你的容器生态系统。

kube-scheduler-simulator 介绍

Mon, 07 Apr 2025 00:00:00 +0000

Kubernetes 调度器（Scheduler）是一个关键的控制平面组件，负责决定 Pod 将运行在哪个节点上。
因此，任何使用 Kubernetes 的人都依赖于调度器。

kube-scheduler-simulator 是一个 Kubernetes 调度器的模拟器，最初是作为 Google Summer of Code 2021 项目由我（Kensei Nakada）开发的，后来收到了许多贡献。
该工具允许用户深入检查调度器的行为和决策。

对于使用调度约束（例如， Pod 间亲和性）的普通用户和通过自定义插件扩展调度器的专家来说，它都是非常有用的。

出发点

调度器通常被视为一个“黑箱”，
由许多插件组成，每个插件从其独特的角度对调度决策过程做出贡献。
由于调度器考虑的因素繁多，理解其行为可能会非常具有挑战性。

即使在一个简单的测试集群中，Pod 似乎被正确调度，它也可能基于与预期不同的计算逻辑进行调度。这种差异可能会在大规模生产环境中导致意外的调度结果。

此外，测试调度器是一个复杂的挑战。
在实际集群中执行的操作模式数不胜数，使得通过有限数量的测试来预见每种场景变得不可行。
通常，只有当调度器部署到实际集群时，才会发现其中的 Bug。

实际上，许多 Bug 是在发布版本后由用户发现的，即使是在上游 kube-scheduler 中也是如此。

拥有一个用于测试调度器或任何 Kubernetes 控制器的开发或沙箱环境是常见做法。
然而，这种方法不足以捕捉生产集群中可能出现的所有潜在场景，因为开发集群通常规模要小得多，在工作负载大小和扩展动态方面存在显著差异。
它永远不会看到与生产环境中完全相同的使用情况或表现出相同的行为。

kube-scheduler-simulator 旨在解决这些问题。
它使用户能够在检查调度决策每一个细节的同时，测试他们的调度约束、调度器配置和自定义插件。
它还允许用户创建一个模拟集群环境，在该环境中，他们可以使用与生产集群相同的资源来测试其调度器，而不会影响实际的工作负载。

kube-scheduler-simulator 的特性

kube-scheduler-simulator 的核心特性在于它能够揭示调度器的内部决策过程。
调度器基于 scheduling framework 运作，在不同的扩展点使用各种插件，过滤节点（Filter 阶段）、为节点打分（Score 阶段），并最终确定最适合 Pod 的节点。

模拟器允许用户创建 Kubernetes 资源，并观察每个插件如何影响 Pod 的调度决策。
这种可见性帮助用户理解调度器的工作机制并定义适当的调度约束。

模拟器 Web 前端

在模拟器内部，运行的是一个可调试的调度器，而不是普通的调度器。
这个可调试的调度器会将每个调度器插件在各个扩展点的结果输出到 Pod 的注解中，如下所示的清单所示，而 Web 前端则基于这些注解对调度结果进行格式化和可视化。

kind: Pod
apiVersion: v1
metadata:
  # 为了使博客文章更清晰，这些注释中的 JSON 都是手动格式化的。
  annotations:
    kube-scheduler-simulator.sigs.k8s.io/bind-result: '{"DefaultBinder":"success"}'
    kube-scheduler-simulator.sigs.k8s.io/filter-result: >-
      {
        "node-jjfg5":{
            "NodeName":"passed",
            "NodeResourcesFit":"passed",
            "NodeUnschedulable":"passed",
            "TaintToleration":"passed"
        },
        "node-mtb5x":{
            "NodeName":"passed",
            "NodeResourcesFit":"passed",
            "NodeUnschedulable":"passed",
            "TaintToleration":"passed"
        }
      }      
    kube-scheduler-simulator.sigs.k8s.io/finalscore-result: >-
      {
        "node-jjfg5":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"52",
            "NodeResourcesFit":"47",
            "TaintToleration":"300",
            "VolumeBinding":"0"
        },
        "node-mtb5x":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"76",
            "NodeResourcesFit":"73",
            "TaintToleration":"300",
            "VolumeBinding":"0"
        }
      }       
    kube-scheduler-simulator.sigs.k8s.io/permit-result: '{}'
    kube-scheduler-simulator.sigs.k8s.io/permit-result-timeout: '{}'
    kube-scheduler-simulator.sigs.k8s.io/postfilter-result: '{}'
    kube-scheduler-simulator.sigs.k8s.io/prebind-result: '{"VolumeBinding":"success"}'
    kube-scheduler-simulator.sigs.k8s.io/prefilter-result: '{}'
    kube-scheduler-simulator.sigs.k8s.io/prefilter-result-status: >-
      {
        "AzureDiskLimits":"",
        "EBSLimits":"",
        "GCEPDLimits":"",
        "InterPodAffinity":"",
        "NodeAffinity":"",
        "NodePorts":"",
        "NodeResourcesFit":"success",
        "NodeVolumeLimits":"",
        "PodTopologySpread":"",
        "VolumeBinding":"",
        "VolumeRestrictions":"",
        "VolumeZone":""
      }      
    kube-scheduler-simulator.sigs.k8s.io/prescore-result: >-
      {
        "InterPodAffinity":"",
        "NodeAffinity":"success",
        "NodeResourcesBalancedAllocation":"success",
        "NodeResourcesFit":"success",
        "PodTopologySpread":"",
        "TaintToleration":"success"
      }      
    kube-scheduler-simulator.sigs.k8s.io/reserve-result: '{"VolumeBinding":"success"}'
    kube-scheduler-simulator.sigs.k8s.io/result-history: >-
      [
        {
            "kube-scheduler-simulator.sigs.k8s.io/bind-result":"{\"DefaultBinder\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/filter-result":"{\"node-jjfg5\":{\"NodeName\":\"passed\",\"NodeResourcesFit\":\"passed\",\"NodeUnschedulable\":\"passed\",\"TaintToleration\":\"passed\"},\"node-mtb5x\":{\"NodeName\":\"passed\",\"NodeResourcesFit\":\"passed\",\"NodeUnschedulable\":\"passed\",\"TaintToleration\":\"passed\"}}",
            "kube-scheduler-simulator.sigs.k8s.io/finalscore-result":"{\"node-jjfg5\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"52\",\"NodeResourcesFit\":\"47\",\"TaintToleration\":\"300\",\"VolumeBinding\":\"0\"},\"node-mtb5x\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"76\",\"NodeResourcesFit\":\"73\",\"TaintToleration\":\"300\",\"VolumeBinding\":\"0\"}}",
            "kube-scheduler-simulator.sigs.k8s.io/permit-result":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/permit-result-timeout":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/postfilter-result":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/prebind-result":"{\"VolumeBinding\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/prefilter-result":"{}",
            "kube-scheduler-simulator.sigs.k8s.io/prefilter-result-status":"{\"AzureDiskLimits\":\"\",\"EBSLimits\":\"\",\"GCEPDLimits\":\"\",\"InterPodAffinity\":\"\",\"NodeAffinity\":\"\",\"NodePorts\":\"\",\"NodeResourcesFit\":\"success\",\"NodeVolumeLimits\":\"\",\"PodTopologySpread\":\"\",\"VolumeBinding\":\"\",\"VolumeRestrictions\":\"\",\"VolumeZone\":\"\"}",
            "kube-scheduler-simulator.sigs.k8s.io/prescore-result":"{\"InterPodAffinity\":\"\",\"NodeAffinity\":\"success\",\"NodeResourcesBalancedAllocation\":\"success\",\"NodeResourcesFit\":\"success\",\"PodTopologySpread\":\"\",\"TaintToleration\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/reserve-result":"{\"VolumeBinding\":\"success\"}",
            "kube-scheduler-simulator.sigs.k8s.io/score-result":"{\"node-jjfg5\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"52\",\"NodeResourcesFit\":\"47\",\"TaintToleration\":\"0\",\"VolumeBinding\":\"0\"},\"node-mtb5x\":{\"ImageLocality\":\"0\",\"NodeAffinity\":\"0\",\"NodeResourcesBalancedAllocation\":\"76\",\"NodeResourcesFit\":\"73\",\"TaintToleration\":\"0\",\"VolumeBinding\":\"0\"}}",
            "kube-scheduler-simulator.sigs.k8s.io/selected-node":"node-mtb5x"
        }
      ]      
    kube-scheduler-simulator.sigs.k8s.io/score-result: >-
      {
        "node-jjfg5":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"52",
            "NodeResourcesFit":"47",
            "TaintToleration":"0",
            "VolumeBinding":"0"
        },
        "node-mtb5x":{
            "ImageLocality":"0",
            "NodeAffinity":"0",
            "NodeResourcesBalancedAllocation":"76",
            "NodeResourcesFit":"73",
            "TaintToleration":"0",
            "VolumeBinding":"0"
        }
      }      
    kube-scheduler-simulator.sigs.k8s.io/selected-node: node-mtb5x

用户还可以将其自定义插件或扩展器集成到可调试调度器中，并可视化其结果。

这个可调试调度器还可以独立运行，例如，在任何 Kubernetes 集群上或在集成测试中运行。
这对于希望测试其插件或在真实集群中以更好的可调试性检查其自定义调度器的插件开发者来说非常有用。

作为更优开发集群的模拟器

如前所述，由于测试用例的数量有限，不可能预测真实世界集群中的每一种可能场景。
通常，用户会在一个小型开发集群中测试调度器，然后再将其部署到生产环境中，希望能不出现任何问题。

模拟器的导入功能通过允许用户在类似生产环境的模拟中部署新的调度器版本而不影响其线上工作负载，提供了一种解决方案。

通过在生产集群和模拟器之间进行持续同步，用户可以安全地使用与生产集群相同的资源测试新的调度器版本。一旦对其性能感到满意，便可以继续进行生产部署，从而减少意外问题的风险。

有哪些使用场景？

集群用户：检查调度约束（例如，PodAffinity、PodTopologySpread）是否按预期工作。
集群管理员：评估在调度器配置更改后集群的行为表现。
调度器插件开发者：测试自定义调度器插件或扩展器，在集成测试或开发集群中使用可调试调度器，或利用同步功能在类似生产环境的环境中进行测试。

入门指南

模拟器仅要求在机器上安装 Docker；并不需要 Kubernetes 集群。

git clone git@github.com:kubernetes-sigs/kube-scheduler-simulator.git
cd kube-scheduler-simulator
make docker_up

然后，你可以通过访问 http://localhost:3000 来使用模拟器的 Web UI。

更多详情，请访问 kube-scheduler-simulator 仓库！

参与其中

调度器模拟器由 Kubernetes SIG Scheduling 开发。欢迎你提供反馈并参与贡献！

在 kube-scheduler-simulator 仓库开启问题或提交 PR。

加入 #sig-scheduling Slack 频道参与讨论。

致谢

模拟器由致力于该项目的志愿者工程师们维护，克服了许多挑战才达到了现在的形式。

特别感谢所有杰出的贡献者！

Kubernetes v1.33 预览

Wed, 26 Mar 2025 10:30:00 -0800

随着 Kubernetes v1.33 版本的发布临近，Kubernetes 项目仍在不断发展。为了提升项目的整体健康状况，某些特性可能会被弃用、移除或替换。这篇博客文章概述了 v1.33 版本的一些计划变更，发布团队认为你有必要了解这些内容，以确保 Kubernetes 环境的持续平稳运行，并让你掌握最新的发展动态。以下信息基于 v1.33 版本的当前状态，在最终发布日期之前可能会有所变化。

Kubernetes API 的移除与弃用流程

Kubernetes 项目针对特性的弃用有一套完善的弃用政策。该政策规定，只有在有更新的、稳定的同名 API 可用时，才能弃用稳定的 API，并且每个稳定性级别的 API 都有最低的生命周期要求。被弃用的 API 已被标记为将在未来的 Kubernetes 版本中移除。在移除之前（自弃用起至少一年内），它仍然可以继续使用，但使用时会显示警告信息。已被移除的 API 在当前版本中不再可用，届时你必须迁移到使用替代方案。

一般可用（GA）或稳定 API 版本可以被标记为已弃用，但在 Kubernetes 的一个主要版本内不得移除。
测试版或预发布 API 版本在弃用后必须支持至少三个发行版本。
Alpha 或实验性 API 版本可以在任何版本中被移除，且无需事先发出弃用通知；如果同一特性已经有了不同的实现，这个过程可能会变为撤回。

无论是由于某个特性从测试阶段升级为稳定阶段而导致 API 被移除，还是因为该 API 未能成功，所有的移除操作都遵循此弃用政策。每当一个 API 被移除时，迁移选项都会在弃用指南中进行说明。

Kubernetes v1.33 的弃用与移除

稳定版 Endpoints API 的弃用

EndpointSlices API 自 v1.21 起已稳定，实际上取代了原有的 Endpoints API。虽然原有的 Endpoints API 简单直接，但在扩展到大量网络端点时也带来了一些挑战。EndpointSlices API 引入了诸如双栈网络等新特性，使得原有的 Endpoints API 已准备好被弃用。

此弃用仅影响那些直接在工作负载或脚本中使用 Endpoints API 的用户；这些用户应迁移到使用 EndpointSlices。未来几周内将发布一篇专门的博客文章，详细介绍弃用的影响和迁移计划。

你可以在 KEP-4974: Deprecate v1.Endpoints 中找到更多信息。

节点状态中 kube-proxy 版本信息的移除

继在 v1.31 中被弃用，并在发布说明中强调后， status.nodeInfo.kubeProxyVersion 字段将在 v1.33 中被移除。此字段由 kubelet 设置，但其值并不总是准确的。由于自 v1.31 起该字段默认已被禁用，v1.33 发行版将完全移除此字段。

你可以在 KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field 中找到更多信息。

移除对 Windows Pod 的主机网络支持

Windows Pod 网络旨在通过允许容器使用节点的网络命名空间来实现与 Linux 的特性对等，并提供更高的集群密度。最初的实现作为 Alpha 版本在 v1.26 中引入，但由于遇到了未预期的 containerd 行为，且存在替代方案，Kubernetes 项目决定撤回相关的 KEP。我们预计在 v1.33 中完全移除对该特性的支持。

你可以在 KEP-3503: Host network support for Windows pods 中找到更多信息。

Kubernetes v1.33 的特色改进

作为本文的作者，我们挑选了一项改进作为最重要的变更来特别提及！

Linux Pods 中用户命名空间的支持

当前最古老的开放 KEP 之一是 KEP-127，通过使用 Linux 用户命名空间为 Pod 提供安全性改进。该 KEP 最初在 2016 年末提出，经过多次迭代，在 v1.25 中发布了 Alpha 版本，在 v1.30 中首次进入 Beta 阶段（在此版本中默认禁用），现在它将成为 v1.33 的一部分，默认情况下即可使用该特性。

除非你手动指定 pod.spec.hostUsers 以选择使用此特性，否则此支持不会影响现有的 Pod。正如在 v1.30 预览博客中强调的那样，就缓解漏洞的影响而言，这是一个重要里程碑。

你可以在 KEP-127: Support User Namespaces in pods 中找到更多信息。

精选的其他 Kubernetes v1.33 改进

以下列出的改进很可能会包含在即将到来的 v1.33 发行版中。这些改进尚无法承诺，发行内容仍有可能发生变化。

Pod 垂直扩展的就地资源调整

在制备某个 Pod 时，你可以使用诸如 Deployment、StatefulSet 等多种资源。为了满足可扩缩性需求，可能需要通过更新 Pod 副本数量进行水平扩缩，或通过更新分配给 Pod 容器的资源进行垂直扩缩。在此增强特性之前，Pod 的 spec 中定义的容器资源是不可变的，更新 Pod 模板中的这类细节会触发 Pod 的替换。

但是如果可以在不重启的情况下动态更新现有 Pod 的资源配置，那会怎样呢？

KEP-1287 正是为了实现这种就地 Pod 更新而设计的。它为无状态进程的垂直扩缩开辟了多种可能性，例如在不停机的情况下进行扩容、在流量较低时无缝缩容，甚至在启动时分配更多资源，待初始设置完成后减少资源分配。该特性在 v1.27 中以 Alpha 版本发布，并预计在 v1.33 中进入 beta 阶段。

你可以在 KEP-1287：Pod 资源的就地更新中找到更多信息。

DRA 的 ResourceClaim 设备状态升级为 Beta

在 v1.32 版本中首次引入的 ResourceClaim status 中的 devices 字段，预计将在 v1.33 中升级为 beta 阶段。此字段允许驱动程序报告设备状态数据，从而提升可观测性和故障排查能力。

例如，在 ResourceClaim 的状态中报告网络接口的接口名称、MAC 地址和 IP 地址，可以显著帮助配置和管理网络服务，并且在调试网络相关问题时也非常有用。你可以在动态资源分配：ResourceClaim 设备状态文档中阅读关于 ResourceClaim 设备状态的更多信息。

此外，你可以在 KEP-4817: DRA: Resource Claim Status with possible standardized network interface data 中找到更多关于此计划增强特性的信息。

有序的命名空间删除

此 KEP 为 Kubernetes 命名空间引入了一种更为结构化的删除流程，以确保更为安全且更为确定的资源移除。当前半随机的删除顺序可能会导致安全漏洞或意外行为，例如在相关的 NetworkPolicy 被删除后，Pod 仍然存在。通过强制执行尊重逻辑和安全依赖关系的结构化删除顺序，此方法确保在删除其他资源之前先删除 Pod。这种设计通过减少与非确定性删除相关的风险，提升了 Kubernetes 的安全性和可靠性。

你可以在 KEP-5080: Ordered namespace deletion 中找到更多信息。

针对带索引作业（Indexed Job）管理的增强

这两个 KEP 都计划升级为 GA，以提供更好的作业处理可靠性，特别是针对索引作业。 KEP-3850 为索引作业中的不同索引分别支持独立的回退限制，这使得每个索引可以完全独立于其他索引。此外，KEP-3998 扩展了 Job API，定义了在并非所有索引都成功的情况下将索引作业标记为成功完成的条件。

你可以在 KEP-3850: Backoff Limit Per Index For Indexed Jobs 和 KEP-3998: Job success/completion policy 中找到更多信息。

想了解更多？

新特性和弃用也会在 Kubernetes 发行说明中宣布。我们将在该版本的 CHANGELOG 中正式宣布 Kubernetes v1.33 的新内容。

Kubernetes v1.33 版本计划于 2025年4月23日星期三发布。请持续关注以获取更新！

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

参与进来

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

在 Bluesky 上关注我们 @kubernetes.io 以获取最新更新
在 Discuss 上参与社区讨论
在 Slack 上加入社区
在 Server Fault 或 Stack Overflow 上提问（或回答问题）
分享你的 Kubernetes 故事
在博客上阅读更多关于 Kubernetes 最新动态的内容
了解更多关于 Kubernetes 发布团队的信息

ingress-nginx CVE-2025-1974 须知

Mon, 24 Mar 2025 12:00:00 -0800

今天，ingress-nginx 项目的维护者们发布了一批关键漏洞的修复补丁，这些漏洞可能让攻击者轻易接管你的 Kubernetes 集群。目前有 40% 以上的 Kubernetes 管理员正在使用 ingress-nginx，如果你是其中之一，请立即采取行动，保护你的用户和数据。

背景

Ingress 是 Kubernetes 提供的一种传统特性，可以将你的工作负载 Pod 暴露给外部世界，方便外部用户使用。 Kubernetes 用户可以用与实现无关的方式来定义应用如何在网络上可用。 Ingress 控制器会根据定义，配置所需的本地资源或云端资源，以满足用户的特定场景和需求。

为了满足不同云厂商用户或负载均衡器产品的需求，目前有许多不同类型的 Ingress 控制器。 ingress-nginx 是 Kubernetes 项目提供的纯软件的 Ingress 控制器。 ingress-nginx 由于灵活易用，非常受用户欢迎。它已经被部署在超过 40% 的 Kubernetes 集群中！

ingress-nginx 会将 Ingress 对象中的要求转换为 Nginx（一个强大的开源 Web 服务器守护进程）的配置。 Nginx 使用这些配置接受请求并将其路由到 Kubernetes 集群中运行的不同应用。正确处理这些 Nginx 配置参数至关重要，因为 ingress-nginx 既要给予用户足够的灵活性，又要防止用户无意或有意诱使 Nginx 执行其不应执行的操作。

今日修复的漏洞

今天修复的四个 ingress-nginx 漏洞都是对 ingress-nginx 如何处理特定 Nginx 配置细节的改进。如果不打这些修复补丁，一个精心构造的 Ingress 资源对象就可以让 Nginx 出现异常行为，包括泄露 ingress-nginx 可访问的 Secret 的值。默认情况下，ingress-nginx 可以访问集群范围内的所有 Secret，因此这往往会导致任一有权限创建 Ingress 的用户或实体接管整个集群。

本次最严重的漏洞是 CVE-2025-1974， CVSS 评分高达 9.8，它允许 Pod 网络中的任意实体通过 ingress-nginx 的验证性准入控制器特性滥用配置注入漏洞。这种机制使得这些漏洞会产生更危险的情形：攻击者通常需要能够在集群中创建 Ingress 对象（这是一种较高权限的操作）。当结合使用今天修复的其他漏洞（比如 CVE-2025-1974）， 就意味着 Pod 网络中的任何实体都有极大可能接管你的 Kubernetes 集群，而不需要任何凭证或管理权限。在许多常见场景下，Pod 网络可以访问云端 VPC 中的所有工作负载，甚至能访问连接到你公司内网的任何人的机器！这是一个非常严重的安全风险。

我们今天已经发布了 ingress-nginx v1.12.1 和 v1.11.5，这两个版本修复了所有这 5 个漏洞。

你需要做什么

首先，确定你的集群是否在使用 ingress-nginx。大多数情况下，你可以使用集群管理员权限运行以下命令进行检查：

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

如果你在使用 ingress-nginx，请立即针对这些漏洞制定补救计划。

最简单且推荐的补救方案是立即升级到最新补丁版本。 安装今天的补丁，就能修复所有这 5 个漏洞。

如果你暂时无法升级，可以通过关闭 ingress-nginx 的验证性准入控制器特性来显著降低风险。

如果你使用 Helm 安装了 ingress-nginx
- 重新安装，设置 Helm 参数 controller.admissionWebhooks.enabled=false
如果你是手动安装的
- 删除名为 ingress-nginx-admission 的 ValidatingWebhookConfiguration
- 编辑 ingress-nginx-controller Deployment 或 DaemonSet，从控制器容器的参数列表中移除 --validating-webhook

如果你为了缓解 CVE-2025-1974 造成的风险而关闭了验证性准入控制器特性，请在升级完成后记得重新开启此特性。这个特性可以为你的用户提供重要的生命期帮助，可以在错误的 Ingress 配置在生效之前及时提醒用户。

总结、致谢与更多参考

今天公布的包括 CVE-2025-1974 在内的 ingress-nginx 漏洞对许多 Kubernetes 用户及其数据构成了严重风险。如果你正在使用 ingress-nginx，请立即采取行动确保自身安全。

我们要感谢来自 Wiz 的 Nir Ohfeld、Sagi Tzadik、Ronen Shustin 和 Hillai Ben-Sasson，他们负责任地披露了这些漏洞，并与 Kubernetes 安全响应委员会成员以及 ingress-nginx 维护者（Marco Ebert 和 James Strong）协同合作，确保这些漏洞被有效修复。

有关 ingress-nginx 的维护和未来的更多信息，请参阅这个 GitHub Issue，或参与 James 和 Marco 在 KubeCon/CloudNativeCon EU 2025 的演讲。

关于本文中提到的具体漏洞的信息，请参阅以下 GitHub Issue：

JobSet 介绍

Sun, 23 Mar 2025 00:00:00 +0000

在本文中，我们介绍 JobSet，这是一个用于表示分布式任务的开源 API。 JobSet 的目标是为 Kubernetes 上的分布式机器学习训练和高性能计算（HPC）工作负载提供统一的 API。

为什么需要 JobSet？

Kubernetes 社区近期对 Kubernetes 批处理生态系统的增强，吸引了许多机器学习工程师，他们发现这非常符合运行分布式训练工作负载的需求。

单个主机上的 GPU 或 TPU 芯片通常无法满足大型机器学习模型（尤其是大语言模型，LLM）的内存需求，因此往往会被分布到成千上万的加速器芯片上，而这些芯片可能跨越数千个主机。

因此，模型训练代码通常会被容器化，并在所有这些主机上同时执行，进行分布式计算。这些计算通常会将模型参数和/或训练数据集拆分到目标加速器芯片上，并使用如 all-gather 和 all-reduce 等通信集合原语来进行分布式计算以及在主机之间同步梯度。

这些工作负载的特性使得 Kubernetes 非常适合此类任务，因为高效地调度和管理跨计算资源集群的容器化应用生命周期是 Kubernetes 的强项。

Kubernetes 还具有很强的可扩展性，允许开发者定义自己的 Kubernetes API、对象以及管理这些对象行为和生命周期的控制器，从而让工程师能够开发定制化的分布式训练编排解决方案以满足特定需求。

然而，随着分布式机器学习训练技术的不断发展，现有的 Kubernetes 原语已经无法单独充分描述这些新技术。

此外，Kubernetes 分布式训练编排 API 的领域已经变得支离破碎，而这个碎片化的领域中每个现有的解决方案都存在某些限制，使得它们在分布式机器学习训练方面并非最优选择。

例如，KubeFlow 训练 Operator 为不同的框架定义了自定义 API（例如 PyTorchJob、TFJob、MPIJob 等）。然而，这些作业类型实际上分别是针对特定框架量身定制的解决方案，各自具有不同的语义和行为。

另一方面，Job API 弥补了运行批处理工作负载的许多空白，包括带索引的完成模式（Indexed Completion Mode）、更高的可扩展性、Pod 失效策略和 Pod 回退策略等，这些都是最近的一些重要增强功能。然而，使用上游 Job API 运行机器学习训练和高性能计算（HPC）工作负载时，需要额外的编排来填补以下空白：

多模板 Pod：大多数 HPC 或机器学习训练任务包含多种类型的 Pod。这些不同的 Pod 属于同一工作负载，但它们需要运行不同的容器、请求不同的资源或具有不同的失效策略。一个常见的例子是驱动器-工作节点（driver-worker）模式。

任务组：大规模训练工作负载跨越多个网络拓扑，例如在多个机架之间运行。这类工作负载对网络延迟非常敏感，目标是将通信本地化并尽量减少跨越高延迟网络链路的流量。为此，需要将工作负载拆分为 Pod 组，每组分配到一个网络拓扑。
Pod 间通信：创建和管理建立作业中 Pod 之间通信所需的资源（例如无头服务）。

启动顺序：某些任务需要特定的 Pod 启动顺序；有时需要驱动（driver）首先启动（例如 Ray 或 Spark），而有时，人们期望多个工作节点（worker）在驱动启动之前就绪（例如 MPI）。

JobSet 旨在以 Job API 为基础，填补这些空白，构建一个更丰富的 API，以支持大规模分布式 HPC 和 ML 使用场景。

JobSet 的工作原理

JobSet 将分布式批处理工作负载建模为一组 Kubernetes Job。这使得用户可以轻松为不同的 Pod 组（例如领导者 Pod、工作节点 Pod、参数服务器 Pod 等）指定不同的 Pod 模板。

它通过抽象概念 ReplicatedJob 来管理子 Job，其中 ReplicatedJob 本质上是一个带有指定副本数量的 Job 模板。这种方式提供了一种声明式的手段，能够轻松创建相同的子 Job，使其在不同的加速器集群上运行，而无需借助脚本或 Helm Chart 来生成具有不同名称的多个相同任务版本。

解决上述问题的其他一些关键 JobSet 特性包括：

任务副本（Replicated Jobs）：在现代数据中心中，硬件加速器（如 GPU 和 TPU）通常以同质加速器岛的形式分配，并通过专用的高带宽网络链路连接。例如，用户可能会配置包含一组主机的节点，这些主机位于同一机架内，每个主机都配备了 H100 GPU，主机内的 GPU 芯片通过 NVLink 连接，并通过 NVLink 交换机连接多个 NVLink。 TPU Pod 是另一个例子：TPU ViperLitePods 包含 64 个主机，每个主机连接了 4 个 TPU v5e 芯片，所有芯片通过 ICI 网格连接。在跨多个这样的加速器岛运行分布式训练任务时，我们通常希望将工作负载划分为一组较小的相同任务，每个岛一个任务，其中每个 Pod 主要与同一岛内的其他 Pod 通信以完成分布式计算的部分段，并将梯度同步通过数据中心网络（DCN，其带宽低于 ICI）降到最低。

自动创建、配置无头服务并管理其生命周期：默认情况下，启用通过 Pod 主机名来完成 Pod 到 Pod 的通信，并通过无头服务的自动配置和生命周期管理来支持这一功能。
可配置的成功策略：JobSet 提供了可配置的成功策略，这些策略针对特定的 ReplicatedJob，并可通过操作符指定 "Any" 或 "All" 子任务。例如，你可以将 JobSet 配置为仅在属于 "worker" ReplicatedJob 的所有 Pod 完成时才标记为完成。

可配置的失效策略：JobSet 提供了可配置的失效策略，允许用户指定在发生故障时 JobSet 应重启的最大次数。如果任何任务被标记为失败，整个 JobSet 将会被重新创建，从而使工作负载可以从最后一个检查点恢复。当未指定失效策略时，如果任何任务失败， JobSet 会直接标记为失败。

按拓扑域的独占放置：JobSet 允许用户指定子任务与拓扑域（通常是加速器岛，例如机架）之间的一对一独占分配关系。例如，如果 JobSet 创建了两个子任务，此功能将确保每个子任务的 Pod 位于同一个加速器岛内，并且每个岛只允许调度一个子任务。这在我们希望使用分布式数据并行（DDP）训练策略的情况下非常有用，例如利用多个计算资源岛（GPU 机架或 TPU 切片）训练模型，在每个加速器岛内运行一个模型副本，确保前向和反向传播过程通过岛内加速器芯片之间的高带宽互联完成，而模型副本之间的梯度同步则通过低带宽的数据中心网络在加速器岛之间进行。

与 Kueue 集成：用户可以通过 Kueue 提交 JobSet，以实现集群的超额订阅、将工作负载排队等待容量可用时运行、防止部分调度和死锁、支持多租户等更多功能。

示例用例

使用 Jax 在多个 TPU 切片上进行分布式 ML 训练

以下示例展示了一个 JobSet 规范，用于在 4 个 TPU v5e 切片上运行 TPU 多切片工作负载。若想了解更多关于 TPU 的概念和术语，请参考这些文档。

此示例使用了 Jax，这是一个通过 OpenXLA 提供对 TPU 芯片即时（JIT）编译原生支持的机器学习框架。不过，你也可以使用 PyTorch/XLA 在 TPUs 上进行机器学习训练。

此示例利用了 JobSet 的多个功能（无论是显式还是隐式），以开箱即用地支持 TPU 多切片训练的独特调度需求，而用户需要的配置非常少。

# 运行简单的 Jax 工作负载
apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: multislice
  annotations:
    # 为每个子任务提供 TPU 切片的独占使用权
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-nodepool
spec:
  failurePolicy:
    maxRestarts: 3
  replicatedJobs:
  - name: workers
    replicas: 4 # 设置为 TPU 切片的数量
    template:
      spec:
        parallelism: 2 # 设置为每个 TPU 切片的虚拟机数量
        completions: 2 # 设置为每个 TPU 切片的虚拟机数量
        backoffLimit: 0
        template:
          spec:
            hostNetwork: true
            dnsPolicy: ClusterFirstWithHostNet
            nodeSelector:
              cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
              cloud.google.com/gke-tpu-topology: 2x4
            containers:
            - name: jax-tpu
              image: python:3.8
              ports:
              - containerPort: 8471
              - containerPort: 8080
              securityContext:
                privileged: true
              command:
              - bash
              - -c
              - |
                pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                python -c 'import jax; print("Global device count:", jax.device_count())'
                sleep 60                
              resources:
                limits:
                  google.com/tpu: 4

未来工作与参与方式

我们今年的 JobSet 路线图中计划开发多项功能，具体内容可以在 JobSet 路线图中找到。

欢迎你随时提供任何形式的反馈。我们也欢迎更多贡献者加入，无论是修复或报告问题、帮助添加新功能，还是撰写文档，都非常欢迎。

你可以通过我们的代码仓库、邮件列表或者在 Slack 上与我们联系。

最后但同样重要的是，感谢所有贡献者，是你们让这个项目成为可能！

聚焦 SIG Apps

Wed, 12 Mar 2025 00:00:00 +0000

在我们正在进行的 SIG 聚焦系列中，我们通过与 Kubernetes 项目各个特别兴趣小组（SIG）的领导者对话，深入探讨 Kubernetes 项目的核心。这一次，我们聚焦于 SIG Apps，这个小组负责 Kubernetes 上与应用程序开发、部署和操作相关的所有内容。 Sandipan Panda（[DevZero](https://www.devzero.io/））有机会采访了 SIG Apps 的主席和技术负责人 Maciej Szulik（Defense Unicorns）以及 Janet Kuo（Google）。他们分享了在 Kubernetes 生态系统中关于应用管理的经验、挑战以及未来愿景。

自我介绍

Sandipan：你好，能否先简单介绍一下你自己、你的角色，以及你在 Kubernetes 社区中的经历，这些经历是如何引导你担任 SIG Apps 的当前角色的？

Maciej：嗨，我叫 Maciej，是 SIG Apps 的负责人之一。除了这个角色，你还可以看到我在协助 SIG CLI 的工作，同时我也是指导委员会的成员之一。自 2014 年底以来，我一直为 Kubernetes 做出贡献，涉及的领域包括控制器、API 服务器以及 kubectl。

Janet：当然可以！我是 Janet，在 Google 担任资深软件工程师，并且从 Kubernetes 项目早期（甚至在 2015 年 1.0 版本发布之前）就深度参与其中。这是一段非常精彩的旅程！

我在 Kubernetes 社区中的当前角色是 SIG Apps 的主席之一和技术负责人之一。我与 SIG Apps 的结缘始于自然而然的过程。最初，我从构建 Deployment API 并添加滚动更新功能开始，逐渐对 SIG Apps 产生了浓厚的兴趣，并且参与度越来越高。随着时间推移，我承担了更多的责任，最终走到了目前的领导岗位。

关于 SIG Apps

以下所有回答均由 Maciej 和 Janet 共同提供。

Sandipan：对于那些不熟悉的人，能否简要介绍一下 SIG Apps 的使命和目标？它在 Kubernetes 生态系统中旨在解决哪些关键问题？

正如我们在章程中所描述的那样，我们涵盖了与在 Kubernetes 上开发、部署和操作应用程序相关的广泛领域。简而言之，这意味着我们欢迎每个人参加我们的双周会议，讨论在 Kubernetes 上编写和部署各种应用程序的经验和挑战。

Sandipan：SIG Apps 目前正在进行的一些最重要项目或倡议有哪些？

在当前阶段，推动我们控制器开发的主要因素是运行各种 AI 相关工作负载所带来的挑战。在此值得一提的是，过去几年我们支持的两个工作组：

Batch 工作组，该工作组致力于在 Kubernetes 上运行 HPC、AI/ML 和数据分析作业。
Serving 工作组，该工作组专注于硬件加速的 AI/ML 推理。

最佳实践与挑战

Sandipan：SIG Apps 在为 Kubernetes 开发应用程序管理最佳实践方面发挥着关键作用。你能分享一些这些最佳实践吗？以及它们如何帮助改进应用程序生命周期管理？

实施健康检查和就绪探针确保你的应用程序处于健康状态并准备好处理流量，从而提高可靠性和正常运行时间。结合全面的日志记录、监控和跟踪解决方案，上述措施将为您提供应用程序行为的洞察，使你能够快速识别并解决问题。

根据资源利用率或自定义指标自动扩缩你的应用，优化资源使用并确保您的应用程序能够处理不同的负载。

对于无状态应用程序使用 Deployment，对于有状态应用程序使用 StatefulSet，对于批处理工作负载使用 Job 和 CronJob，在每个节点上运行守护进程时使用 DaemonSet。使用 Operator 和 CRD 扩展 Kubernetes API 以自动化复杂应用程序的部署、管理和生命周期，使其更易于操作并减少手动干预。

Sandipan：SIG Apps 面临的一些常见挑战是什么？你们是如何解决这些问题的？

我们一直面临的最大挑战是需要拒绝许多功能、想法和改进。这需要大量的纪律性和耐心，以便能够解释做出这些决定背后的原因。

Sandipan：Kubernetes 的演进如何影响了 SIG Apps 的工作？ Kubernetes 最近是否有任何变化或即将推出的功能，你认为对 SIG Apps 特别相关或有益？

对我们以及围绕 SIG Apps 的整个社区而言，最大的好处是能够通过自定义资源定义（Custom Resource Definitions）扩展 Kubernetes。用户可以利用内置控制器构建自己的自定义控制器，以实现他们可能面对的各种复杂用例，而我们作为核心维护者，可能没有考虑过这些用例，或者无法在 Kubernetes 内部高效解决。

贡献于 SIG Apps

Sandipan：对于想要参与 SIG Apps 的新贡献者，有哪些机会？你会给他们什么建议？

我们经常被问道：“你们建议我们从哪个好的初始问题开始？” :-) 但遗憾的是，这个问题没有简单的答案。我们总是告诉大家，为核心控制器做贡献的最佳方式是找到一个你愿意花时间研究的控制器。阅读代码，然后尝试运行针对该控制器的单元测试和集成测试。一旦你掌握了大致的概念，试着破坏它并再次运行测试以验证你的改动。当你开始有信心理解了这个特定的控制器后，你可以搜索影响该控制器的待处理问题，提供一些建议，解释用户遇到的问题，或者尝试提交你的第一个修复。

正如我们所说，在这条道路上没有捷径可走；你需要花时间研究代码库，以理解我们逐步积累的所有边缘情况，从而达到我们现在的位置。一旦你在一个控制器上取得了成功，你就需要在其他控制器上重复同样的过程。

Sandipan：SIG Apps 如何从社区收集反馈，以及这些反馈是如何整合到你们的工作中的？

我们总是鼓励每个人参加我们的双周会议，并在会上提出他们的问题和解决方案。只要你是在 Kubernetes 上解决一个有趣的问题，并且能够对任何核心控制器提供有价值的反馈，我们都非常乐意听取每个人的意见。

展望未来

Sandipan：展望未来，Kubernetes 中应用程序管理的关键关注领域或即将到来的趋势有哪些是 SIG Apps 感到兴奋的？SIG 是如何适应这些趋势的？

当前的 AI 热潮无疑是主要的驱动因素；如上所述，我们有两个工作组，每个工作组都涵盖了它的一个不同方面。

Sandipan：关于这个 SIG，你们最喜欢的事情有哪些？

毫无疑问，参与我们会议和 Slack 频道的人们是最让我们感到欣慰的。他们不知疲倦地帮助处理问题、拉取请求，并投入大量的时间（很多时候是他们的私人时间）来让 Kubernetes 变得更好！

SIG Apps 是 Kubernetes 社区的重要组成部分，帮助塑造了应用程序如何在大规模下部署和管理的方式。从改进 Kubernetes 的工作负载 API 到推动 AI/ML 应用程序管理的创新，SIG Apps 不断适应以满足现代应用程序开发者和操作人员的需求。无论你是新贡献者还是有经验的开发者，都有机会参与其中并产生影响。

如果你有兴趣了解更多关于 SIG Apps 的信息或为其做出贡献，务必查看他们的 SIG README，并加入他们的双周会议。

kube-proxy 的 NFTables 模式

Fri, 28 Feb 2025 00:00:00 +0000

Kubernetes 1.29 引入了一种新的 Alpha 特性：kube-proxy 的 nftables 模式。目前该模式处于 Beta 阶段，并预计将在 1.33 版本中达到一般可用（GA）状态。新模式解决了 iptables 模式长期存在的性能问题，建议所有运行在较新内核版本系统上的用户尝试使用。出于兼容性原因，即使 nftables 成为 GA 功能，iptables 仍将是默认模式。

为什么选择 nftables？第一部分：数据平面延迟

iptables API 是被设计用于实现简单的防火墙功能，在扩展到支持大型 Kubernetes 集群中的 Service 代理时存在局限性，尤其是在包含数万个 Service 的集群中。

通常，kube-proxy 在 iptables 模式下生成的规则集中的 iptables 规则数量与 Service 数量和总端点数量的总和成正比。特别是，在规则集的顶层，针对数据包可能指向的每个可能的 Service IP（以及端口），都有一条规则用于测试。

# 如果数据包的目标地址是 172.30.0.41:80，则跳转到 KUBE-SVC-XPGD46QRK7WJZT7O 链进行进一步处理
-A KUBE-SERVICES -m comment --comment "namespace1/service1:p80 cluster IP" -m tcp -p tcp -d 172.30.0.41 --dport 80 -j KUBE-SVC-XPGD46QRK7WJZT7O

# 如果数据包的目标地址是 172.30.0.42:443，则...
-A KUBE-SERVICES -m comment --comment "namespace2/service2:p443 cluster IP" -m tcp -p tcp -d 172.30.0.42 --dport 443 -j KUBE-SVC-GNZBNJ2PO5MGZ6GT

# 等等...
-A KUBE-SERVICES -m comment --comment "namespace3/service3:p80 cluster IP" -m tcp -p tcp -d 172.30.0.43 --dport 80 -j KUBE-SVC-X27LE4BHSL4DOUIK

这意味着当数据包到达时，内核检查该数据包与所有 Service 规则所需的时间是 O(n)，其中 n 为 Service 的数量。随着 Service 数量的增加，新连接的第一个数据包的平均延迟和最坏情况下的延迟都会增加（最佳情况、平均情况和最坏情况之间的差异主要取决于某个 Service IP 地址在 KUBE-SERVICES 链中出现的顺序是靠前还是靠后）。

相比之下，使用 nftables，编写此类规则集的常规方法是使用一个单一规则，并通过"判决映射"（verdict map）来完成分发：

table ip kube-proxy {

  # service-ips 判决映射指示了对每个匹配数据包应采取的操作。
  map service-ips {
    type ipv4_addr . inet_proto . inet_service : verdict
    comment "ClusterIP、ExternalIP 和 LoadBalancer IP 流量"
    elements = { 172.30.0.41 . tcp . 80 : goto service-ULMVA6XW-namespace1/service1/tcp/p80,
                 172.30.0.42 . tcp . 443 : goto service-42NFTM6N-namespace2/service2/tcp/p443,
                 172.30.0.43 . tcp . 80 : goto service-4AT6LBPK-namespace3/service3/tcp/p80,
                 ... }
    }

  # 现在我们只需要一条规则来处理所有与映射中元素匹配的数据包。
  # （此规则表示："根据目标 IP 地址、第 4 层协议和目标端口构建一个元组；
  # 在 'service-ips' 中查找该元组；如果找到匹配项，则执行与之关联的判定。"）
  chain services {
    ip daddr . meta l4proto . th dport vmap @service-ips
  }

  ...
}

由于只有一条规则，并且映射查找的时间复杂度大约为 O(1)，因此数据包处理时间几乎与集群规模无关，并且最佳、平均和最坏情况下的表现非常接近：

但请注意图表中 iptables 和 nftables 之间在纵轴上的巨大差异！在包含 5000 和 10,000 个 Service 的集群中，nftables 的 p50（平均）延迟与 iptables 的 p01（接近最佳情况）延迟大致相同。在包含 30,000 个 Service 的集群中，nftables 的 p99（接近最坏情况）延迟比 iptables 的 p01 延迟快了几微秒！以下是两组数据的对比图，但你可能需要仔细观察才能看到 nftables 的结果！

为什么选择 nftables？第二部分：控制平面延迟

虽然在大型集群中数据平面延迟的改进非常显著，但 iptables 模式的 kube-proxy 还存在另一个问题，这往往使得用户无法将集群扩展到较大规模：那就是当 Service 及其端点发生变化时，kube-proxy 更新 iptables 规则所需的时间。

对于 iptables 和 nftables，规则集的整体大小（实际规则加上相关数据）与 Service 及其端点的总数呈 O(n) 关系。原来，iptables 后端在每次更新时都会重写所有规则，当集群中存在数万个 Service 时，这可能导致规则数量增长至数十万条 iptables 规则。从 Kubernetes 1.26 开始，我们开始优化 kube-proxy，使其能够在每次更新时跳过对大多数未更改规则的更新，但由于 iptables-restore API 的限制，仍然需要发送与 Service 数量呈 O(n) 比例的更新（尽管常数因子比以前明显减小）。即使进行了这些优化，有时仍需使用 kube-proxy 的 minSyncPeriod 配置选项，以确保它不会每秒钟都在尝试推送 iptables 更新。

nftables API 支持更为增量化的更新，当以 nftables 模式运行的 kube-proxy 执行更新时，更新的规模仅与自上次同步以来发生变化的 Service 和端点数量呈 O(n) 关系，而与总的 Service 和端点数量无关。此外，由于 nftables API 允许每个使用 nftables 的组件拥有自己的私有表，因此不会像 iptables 那样在组件之间产生全局锁竞争。结果是，kube-proxy 在 nftables 模式下的更新可以比 iptables 模式下高效得多。

（不幸的是，这部分我没有酷炫的图表。）

不选择 nftables 的理由有哪些？

尽管如此，仍有几个原因可能让你目前不希望立即使用 nftables 后端。

首先，该代码仍然相对较新。虽然它拥有大量的单元测试，在我们的 CI 系统中表现正确，并且已经在现实世界中被多个用户使用，但其实际使用量远远不及 iptables 后端，因此我们无法保证它同样稳定且无缺陷。

其次，nftables 模式无法在较旧的 Linux 发行版上工作；目前它需要 5.13 或更高版本的内核。此外，由于早期版本的 nft 命令行工具存在缺陷，不应在运行旧版本（早于 1.0.0） nft 的节点主机文件系统中上以 nftables 模式运行 kube-proxy（否则 kube-proxy 对 nftables 的使用可能会影响系统上其他程序对 nftables 的使用）。

第三，你的集群中可能还存在其他网络组件，例如 Pod 网络或 NetworkPolicy 实现，这些组件可能尚不支持以 nftables 模式运行的 kube-proxy。你应查阅相关组件的文档（或论坛、问题跟踪系统等），以确认它们是否与 nftables 模式存在兼容性问题。（在许多情况下，它们并不会受到影响；只要它们不尝试直接操作或覆盖 kube-proxy 的 iptables 规则，就不在乎 kube-proxy 使用的是 iptables 还是 nftables。）此外，相较于 iptables 模式下，尚未更新的可观测性和监控工具在 nftables 模式下可能会为 kube-proxy 提供更少的数据。

最后，以 nftables 模式运行的 kube-proxy 有意不与以 iptables 模式运行的 kube-proxy 完全兼容。有一些较旧的 kube-proxy 功能，默认行为不如我们期望的那样安全、高效或直观，但我们认为更改默认行为会导致兼容性问题。由于 nftables 模式是可选的，这为我们提供了一个机会，在不影响期望稳定性的用户的情况下修复这些不良默认设置。（特别是，在 nftables 模式下，NodePort 类型的 Service 现在仅在其节点的默认 IP 上可访问，而在 iptables 模式下，它们在所有 IP 上均可访问，包括 127.0.0.1。）kube-proxy 文档提供了更多关于此方面的信息，包括如何通过查看某些指标来判断你是否依赖于任何已更改的特性，以及有哪些配置选项可用于实现更向后兼容的行为。

尝试使用 nftables 模式

准备尝试了吗？在 Kubernetes 1.31 及更高版本中，你只需将 --proxy-mode nftables 参数传递给 kube-proxy（或在 kube-proxy 配置文件中设置 mode: nftables）。

如果你使用 kubeadm 部署集群，kubeadm 文档解释了如何向 kubeadm init 传递 KubeProxyConfiguration。你还可以通过 kind 部署基于 nftables 的集群。

你还可以通过更新 kube-proxy 配置并重启 kube-proxy Pod，将现有集群从 iptables（或 ipvs）模式转换为 nftables 模式。（无需重启节点：在以 nftables 模式重新启动时，kube-proxy 会删除现有的所有 iptables 或 ipvs 规则；同样，如果你之后切换回 iptables 或 ipvs 模式，它将删除现有的所有 nftables 规则。）

未来计划

如上所述，虽然 nftables 现在是的 kube-proxy 的最佳模式，但它还不是默认模式，我们目前还没有更改这一设置的计划。我们将继续长期支持 iptables 模式。

kube-proxy 的 IPVS 模式的未来则不太确定：它相对于 iptables 的主要优势在于速度更快，但 IPVS 的架构和 API 在某些方面对 kube-proxy 来说不够理想（例如，kube-ipvs0 设备需要被分配所有 Service IP 地址），并且 Kubernetes Service 代理的部分语义使用 IPVS 难以实现（特别是某些 Service 根据连接的客户端是本地还是远程，需要有不同的端点）。现在，nftables 模式的性能与 IPVS 模式相同（实际上略胜一筹），而且没有任何缺点：

（理论上，IPVS 模式还具有可以使用其他 IPVS 功能的优势，例如使用替代的"调度器"来平衡端点。但实际上，这并不太有用，因为 kube-proxy 在每个节点上独立运行，每个节点上的 IPVS 调度器无法与其他节点上的代理共享状态，从而无法实现更智能的流量均衡。）

虽然 Kubernetes 项目目前没有立即放弃 IPVS 后端的计划，但从长远来看，IPVS 可能难逃被淘汰的命运。目前使用 IPVS 模式的用户应尝试使用 nftables 模式（如果发现 nftables 模式中缺少某些无法绕过的功能，请提交问题报告）。

进一步了解

"KEP-3866: Add an nftables-based kube-proxy backend" 记录了此新特性的历史。
"How the Tables Have Turned: Kubernetes Says Goodbye to IPTables"，来自 2024 年 KubeCon/CloudNativeCon 北美大会，讨论了将 kube-proxy 和 Calico 从 iptables 迁移到 nftables 的过程。
"From Observability to Performance"，同样来自 2024 年 KubeCon/CloudNativeCon 北美大会。（kube-proxy 延迟数据来源于此；raw data for the charts 也可用。）

云控制器管理器（Cloud Controller Manager）'鸡与蛋'的问题

Fri, 14 Feb 2025 00:00:00 +0000

Kubernetes 1.31
完成了 Kubernetes 历史上最大的迁移，移除了树内云驱动（in-tree cloud provider）。虽然组件迁移已经完成，但这为用户和安装项目（例如 kOps 或 Cluster API）带来了一些额外的复杂性。我们将回顾这些额外的步骤和可能的故障点，并为集群所有者提供改进建议。
此次迁移非常复杂，必须从核心组件中提取部分逻辑，构建四个新的子系统。

云控制器管理器 (KEP-2392)
API 服务器网络代理 (KEP-1281)
kubelet 凭证提供程序插件 (KEP-2133)
存储迁移到使用 CSI (KEP-625)

云控制器管理器是控制平面的一部分。这是一个关键组件，替换了之前存在于 kube-controller-manager 和 kubelet 中的某些特性。

Kubernetes 组件

云控制器管理器最重要的功能之一是节点控制器，它负责节点的初始化。

从下图可以看出，当 kubelet 启动时，它会向 apiserver 注册 Node 对象，并对节点设置污点，以便云控制器管理器可以先处理该节点。初始的 Node 缺少与云提供商相关的信息，例如节点地址和包含云提供商特定信息的标签，如节点、区域和实例类型信息。

鸡和蛋问题时序图

这一新的初始化过程会增加节点就绪的延迟。以前，kubelet 可以在创建节点的同时初始化节点。对于某些 Kubernetes 架构而言，其控制平面其他组件以静态 Pod、独立二进制文件或具有容忍污点功能的、用 hostNetwork DaemonSet/Deployment 部署，由于节点初始化逻辑已移至云控制管理器中，如果不将控制器管理器作为控制平面的一部分，则可能会导致集群引导过程中出现鸡和蛋问题（更多内容见下文）。

依赖问题的示例

如上所述，在引导过程中，云控制器管理器可能无法被调度，因此集群将无法正确初始化。以下几个具体示例说明此问题的可能表现形式及其根本原因。

这些示例假设你使用 Kubernetes 资源（例如 Deployment、DaemonSet 或类似资源）来控制云控制器管理器的生命周期。由于这些方法依赖于 Kubernetes 来调度云控制器管理器，因此必须确保其能够正确调度。

示例：由于未初始化的污点导致云控制器管理器无法调度

如 Kubernetes 文档中所述，当 kubelet 使用命令行标志 --cloud-provider=external 启动时，其对应的 Node 对象将添加一个名为 node.cloudprovider.kubernetes.io/uninitialized 的不可调度污点。由于云控制器管理器负责移除该不可调度污点，这可能会导致由某个 Kubernetes 资源（例如 Deployment 或 DaemonSet）管理的云控制器管理器无法被调度的情况。

如果在控制平面初始化期间云控制器管理器无法被调度，那么生成的 Node 对象将全部带有 node.cloudprovider.kubernetes.io/uninitialized 不可调度污点。这也意味着该污点不会被移除，因为云控制器管理器负责其移除工作。如果不可调度污点未被移除，关键工作负载（例如容器网络接口控制器）将无法被调度，集群将处于不健康状态。

示例：由于未就绪污点导致云控制器管理器无法调度

下一个示例可能出现在容器网络接口（CNI）正在等待来自云控制器管理器（CCM）的 IP 地址信息，而 CCM 未容忍将由 CNI 移除的污点的情况下。

Kubernetes 文档对 node.kubernetes.io/not-ready 污点的描述如下：

"节点控制器通过监控节点的健康状态来检测节点是否已准备好，并据此添加或移除此污点。"

当容器网络尚未在某节点上初始化时，可能导致 Node 资源具有此污点。由于云控制器管理器负责为 Node 资源添加 IP 地址，而容器网络控制器需要这些 IP 地址来正确配置容器网络，因此在某些情况下，节点可能会永久处于未就绪且未初始化的状态。

这种情况的发生原因与第一个示例类似，但在此情况下，node.kubernetes.io/not-ready 污点使用了 NoExecute 效果，从而导致云控制器管理器无法在带有该污点的节点上运行。如果云控制器管理器无法执行，则它将无法初始化节点。这将进一步导致容器网络控制器无法正常运行，节点最终会同时携带 node.cloudprovider.kubernetes.io/uninitialized 和 node.kubernetes.io/not-ready 两个污点，从而使集群处于不健康状态。

我们的建议

运行云控制器管理器并没有唯一的“正确方式”。具体细节将取决于集群管理员和用户的特定需求。在规划你的集群以及云控制器管理器的生命周期时，请考虑以下指导。

对于在同一集群中运行的云控制器管理器，它们所管理的集群也是这一集群，需要特别注意。

使用主机网络模式，而不是 Pod 网络：在大多数情况下，云控制器管理器需要与基础设施相关的 API 服务端点进行通信。将 "hostNetwork" 设置为 true 可确保云控制器使用主机网络而非容器网络，从而拥有与主机操作系统相同的网络访问权限。这还将消除对网络插件的依赖。这可以确保云控制器能够访问基础设施端点（你应该始终检查网络配置是否与基础设施提供商所给的指导相符）。
使用规模可扩缩的资源类型。Deployment 和 DaemonSet 对于控制云控制器的生命周期非常有用。它们支持轻松地运行多个副本以实现冗余，并利用 Kubernetes 调度来确保在集群中的正确放置。当使用这些原语控制云控制器的生命周期并运行多个副本时，请务必启用领导者选举，否则控制器之间可能会发生冲突，导致集群中的节点无法初始化。

将控制器管理器容器定位到控制平面。可能存在一些需要在控制平面之外运行的其他控制器（例如，Azure 的节点管理器控制器），但云控制器管理器本身应部署到控制平面。使用节点选择算符或亲和性配置将云控制器管理器定向调度到控制平面节点，以确保它们运行在受保护的空间中。云控制器管理器在集群中添加和移除节点时至关重要，因为它们构成了 Kubernetes 与物理基础设施之间的桥梁。
1. 值得注意的是，使用反亲和性配置以防止多个云控制器管理器运行在同一主机上也非常有用，这可以确保单个节点故障不会影响云控制器管理器的性能。

确保污点容忍规则允许操作。在云控制器管理器容器的清单中使用污点容忍规则，以确保其能够被调度到正确的节点，并能够在节点初始化时运行。这意味着云控制器应容忍 node.cloudprovider.kubernetes.io/uninitialized 污点，还应容忍与控制平面相关的任何污点（例如，node-role.kubernetes.io/control-plane 或 node-role.kubernetes.io/master）。容忍 node.kubernetes.io/not-ready 污点也可能很有用，以确保即使节点尚未准备好进行健康监控时，云控制器仍能运行。

对于不在其所管理的集群上（例如，在其他集群上的托管控制平面上）运行的云控制器管理器，其规则将更多地受限于运行云控制器管理器的集群环境的依赖项。针对自管集群的运行建议可能不适用，因为冲突类型和网络约束会有所不同。请根据这些场景咨询你的拓扑结构的架构和需求。

示例

这是一个 Kubernetes Deployment 的示例，突显了上述指导原则。需要注意的是，此示例仅用于演示目的，对于生产环境的使用，请参考你的云提供商的文档。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: cloud-controller-manager
  name: cloud-controller-manager
  namespace: kube-system
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: cloud-controller-manager
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app.kubernetes.io/name: cloud-controller-manager
      annotations:
        kubernetes.io/description: Cloud controller manager for my infrastructure
    spec:
      containers: # 容器的详细信息将取决于你具体的云控制器管理器
      - name: cloud-controller-manager
        command:
        - /bin/my-infrastructure-cloud-controller-manager
        - --leader-elect=true
        - -v=1
        image: registry/my-infrastructure-cloud-controller-manager@latest
        resources:
          requests:
            cpu: 200m
            memory: 50Mi
      hostNetwork: true # 这些 Pod 是控制平面的一部分
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - topologyKey: "kubernetes.io/hostname"
            labelSelector:
              matchLabels:
                app.kubernetes.io/name: cloud-controller-manager
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
      - effect: NoExecute
        key: node.kubernetes.io/unreachable
        operator: Exists
        tolerationSeconds: 120
      - effect: NoExecute
        key: node.kubernetes.io/not-ready
        operator: Exists
        tolerationSeconds: 120
      - effect: NoSchedule
        key: node.cloudprovider.kubernetes.io/uninitialized
        operator: Exists
      - effect: NoSchedule
        key: node.kubernetes.io/not-ready
        operator: Exists

在决定如何部署云控制器管理器时，需要注意的是，不建议使用与集群规模成比例的或基于资源的 Pod 自动规模扩缩。运行多个云控制器管理器副本是确保高可用性和冗余的良好实践，但这并不会提高性能。通常情况下，任何时候只有一个云控制器管理器实例会负责协调集群。

聚焦 SIG Architecture: Enhancements

Tue, 21 Jan 2025 00:00:00 +0000

这是 SIG Architecture 聚光灯系列的第四次采访，我们将介绍 SIG Architecture: Enhancements。

在本次 SIG Architecture 专题采访中，我们访谈了 Enhancements 子项目的负责人 Kirsten Garrison。

Enhancements 子项目

Frederico (FSM)：你好 Kirsten，很高兴有机会讨论 Enhancements 子项目。开始请先介绍一下你自己和所承担的职责。

Kirsten Garrison (KG)：我是 SIG-Architecture 的 Enhancements 子项目的负责人，目前就职于 Google。我最初在 Carolyn Van Slyck 的帮助下，为 service-catalog 项目贡献代码，后来加入了 Release 团队，最终成为 Enhancements Lead 和 Release Lead 影子。在发布团队工作期间，我根据团队的经验为 SIG 和 Enhancements 团队提出了一些改进流程的想法（如参与其中的流程）。之后，我开始参加子项目会议，并为这个子项目的工作做贡献。

FSM：你提到了 Enhancements 子项目，你如何描述它的主要目标和干预范围？

KG：Enhancements 子项目的核心是管理 Kubernetes 增强提案（KEP），这是 Kubernetes 项目所有特性和重大变更的“设计”文档。

KEP 及其影响

FSM：KEP 流程的改进一直是 SIG Architecture 深度参与的工作之一。你能为不了解的人介绍一下这个流程吗？

KG：在每次发布版本时，各个 SIG 需要告知 Release Team 各自计划将哪些特性放到当前的版本发布中。正如前面提到的，所有变更的前提是有一个 KEP，这是一种标准化的设计文档，所有 KEP 的作者必须在发布周期的最初几周内填写完并获得批准。大多数特性会经历三个阶段： Alpha、Beta，最终进入 GA，因此批准一个特性对 SIG 来说是一项重大承诺。

KEP 作为某个特性真实、完整的信息来源。 KEP 模板对处于不同阶段的特性具有不同的要求，但通常需要详细讨论其设计、影响，并提供稳定性和性能的证明材料。 KEP 通常会在作者、SIG 审查人员、API 审查团队和 Production Readiness Review 团队¹之间进行多轮迭代后才能获批。每组审查者都会确保提案符合其标准，以保证 Kubernetes 版本的稳定性和性能。只有在所有审批完成后，作者才能将其特性合并到 Kubernetes 代码库。

FSM：我懂了，新增了一些结构。回顾来看，你认为这种流程方法最重要的改进是什么？

KG：总体而言，我认为最有影响力的改进在于聚焦 KEP 的核心意图。 KEP 不仅仅是设计的存档文件，更是提供了一种结构化的方式来讨论和达成共识。 KEP 流程的核心是沟通和审慎考虑。

为此，一些重要的改进围绕着更详细且更易于访问的 KEP 模板展开。我们投入了大量时间，使 k/enhancements 仓库发展成当前的形式：目录结构按 SIG 小组划分，附带现代 KEP 模板文件，其中包含 Proposal/Motivation/Design Details（提案/动机/设计细节）等小节。我们今天可能认为这种基本结构是理所当然的，但它实际上代表付出了许多人力和时间努力工作才奠定了这一流程基础。

随着 Kubernetes 的发展和成熟，我们需要考虑的不仅仅是如何合并单个特性，还需要关注稳定性、性能、设置和用户期望等问题。因此随着我们的思考深入，KEP 模板变得更详细。例如增加了 Production Readiness Review 机制，同时对测试要求进行了强化（这些要求会随着 KEP 生命周期的不同阶段动态调整）。

当前关注领域

FSM：说到发展，我们最近发布了 Kubernetes v1.31，而 v1.32 版本的开发工作已经开始。 Enhancements 子项目目前有哪些领域正在推进以改进这个流程？

KG：我们目前正在进行两项工作：

创建一个 Process KEP 模板。有时，人们希望使用 KEP 流程来记录重要的流程变更，而不是特性变更。我们希望支持这一点，因为记录变更很重要，为此提供更好的工具将鼓励更多的讨论和更透明。
KEP 版本化。虽然我们的模板变更旨在尽量减少破坏性影响，但我们认为引入 KEP 版本化及相应的策略，可以让变更更易于追踪并更好地与社区沟通。

这两项改进都需要时间来完善和推广（就像 KEP 特性本身一样），但我们相信它们最终会给社区带来很大的好处。

FSM：你提到了改进：我记得最近的发布引入了用于 Enhancement 追踪的项目看板（Project Board），发布团队成员对此表示一致好评。这是 Enhancements 子项目的一个重点方向吗？

KG：Enhancements 子项目为 Release Team 的 Enhancement 团队提供支持，从使用电子表格迁移到一个项目看板。增强提案的收集和跟踪一直是后勤支持的一项挑战。在我担任 Release Team 成员期间，我帮助推动了增强的“选择加入”机制，即 SIG 负责人需要主动“选择加入” KEP 进行发布追踪。这有助于在对 KEP 实施重大工作之前，加强作者与 SIG 之间的沟通，并减少 Enhancements 团队的重复工作。这一变更利用了现有工具，以避免一次性向社区引入过多变化。后来，Release Team 向子项目提出了利用 GitHub 项目看板进一步改进收集流程的想法。这一举措旨在从使用复杂的电子表格转为使用 k/enhancement Issues 和项目看板上的原生仓库标签。

FSM：这无疑简化了工作流程...

KG：减少摩擦来源、促进清晰沟通对 Enhancements 子项目至关重要。同时，我们也需要谨慎考虑影响整个社区的决策。我们希望确保变更既带来好处，又不会在推广过程中造成回归或额外负担。我们支持 Release Team 进行头脑风暴，并协助完成迁移到项目看板的工作。这次变更取得了巨大成功，很高兴看到团队做出了高影响力的改进，使所有参与 KEP 流程的每个人受益！

如何参与

FSM：如果有人想要参与 Enhancements 子项目，你认为需要具备哪些技能？

KG：熟悉 KEP 机制，无论是通过体验，还是花时间阅读 kubernetes/enhancements 仓库都会有所帮助。我们欢迎所有感兴趣的人参与，我们可以一步步引导他们。

FSM：太棒了！非常感谢你的时间和分享——最后你有什么想对读者们说的吗？

KG：Enhancements 流程是 Kubernetes 生态中最重要组成部分之一，需要各个团队的密切协作才能成功。我很感激并敬佩大家持续不断的努力工作和奉献，让这个项目越来越好。这真是一个很棒的社区。

更多信息参考 Production Readiness Review 专题采访。 ↩︎

使用 API 流式传输来增强 Kubernetes API 服务器效率

Tue, 17 Dec 2024 00:00:00 +0000

高效管理 Kubernetes 集群至关重要，特别是在集群规模不断增长的情况下更是如此。大型集群面临的一个重大挑战是 list 请求所造成的内存开销。

在现有的实现中，kube-apiserver 在处理 list 请求时，先在内存中组装整个响应，再将所有数据传输给客户端。但如果响应体非常庞大，比如数百兆字节呢？另外再想象这样一种场景，有多个 list 请求同时涌入，可能是在短暂的网络中断后涌入。虽然 API 优先级和公平性已经证明可以合理地保护 kube-apiserver 免受 CPU 过载，但其对内存保护的影响却明显较弱。这可以解释为各个 API 请求的资源消耗性质有所不同。在任何给定时间，CPU 使用量都会受到某个常量的限制，而内存由于不可压缩，会随着处理对象数量的增加而成比例增长，且没有上限。这种情况会带来真正的风险，kube-apiserver 可能会在几秒钟内因内存不足（OOM）状况而淹没和崩溃。为了更直观地查验这个问题，我们看看下面的图表。

以上图表显示了 kube-apiserver 在一次模拟测试中的内存使用情况。（有关更多细节，参见模拟测试一节）。结果清楚地表明，增加 informer 的数量显著提高了服务器的内存消耗量。值得注意的是，在大约 16:40 时，服务器在仅提供了 16 个 informer 时就崩溃了。

为什么 kube-apiserver 为 list 请求分配这么多内存？

我们的调查显示，这种大量内存分配的发生是因为在向客户端发送第一个字节之前，服务器必须：

从数据库中获取数据
对数据执行从其存储格式的反序列化
最后通过将数据转换和序列化为客户端所请求的格式来构造最终的响应。

这个序列导致了显著的临时内存消耗。实际使用量取决于许多因素，比如分页大小、所施加的过滤器（例如标签选择算符）、查询参数和单个对象的体量。

不巧的是，无论是 API 优先级和公平性，还是 Golang 的垃圾收集或 Golang 的内存限制，都无法在这些状况下防止系统耗尽内存。内存是被突然且快速分配的，仅仅几个请求就可能迅速耗尽可用内存，导致资源耗尽。

取决于 API 服务器在节点上的运行方式，API 服务器可能在这些不受控制的峰值期间因为超过所配置的内存限制而被内核通过 OOM 杀死，或者如果没有为服务器配置限制值，则其可能对控制平面节点产生更糟糕的影响。最糟糕的是，在第一个 API 服务器出现故障后，相同的请求将很可能会影响高可用（HA）部署中的另一个控制平面节点，并可能产生相同的影响。这可能是一个难以诊断和难以恢复的情况。

流式处理 list 请求

今天，我们很高兴地宣布一项重大改进。随着 Kubernetes 1.32 中 watch list 特性进阶至 Beta， client-go 用户可以选择（在显式启用 WatchListClient 特性门控后）通过将 list 请求切换为（某种特殊类别的） watch 请求来进行流式处理。

watch 请求使用 监视缓存（watch cache） 提供服务，监视缓存是设计来提高读操作扩缩容能力的一个内存缓存。通过逐个流式传输每一项，而不是返回整个集合，这种新方法保持了恒定的内存开销。 API 服务器受限于 etcd 中对象的最大允许体量加上少量额外分配的内存。与传统的 list 请求相比，尤其是在分页情况下内存消耗仍较高的、具有大量特定类别的对象或对象体量平均较大的集群中，这种方法大幅降低了临时内存使用量，确保了系统更高效和更稳定。

基于模拟测试所了解的情况（参见模拟测试），我们开发了一种自动化的性能测试，以系统地评估 watch list 特性的影响。此测试能够重现相同的场景，生成大量载荷较大的 Secret，并扩缩容 informer 的数量以模拟高频率的 list 请求模式。这种自动化测试被定期执行，以监控启用和禁用此特性后服务器的内存使用情况。

结果表明，启用 watch list 特性后有显著改善。启用此特性时，kube-apiserver 的内存消耗稳定在大约 2 GB。相比之下，禁用此特性时，内存使用量增加到约 20 GB，增长了 10 倍！这些结果证实了新的流式 API 的有效性，减少了临时内存占用。

为你的组件启用 API 流式传输

升级到 Kubernetes 1.32。确保你的集群使用 etcd v3.4.31+ 或 v3.5.13+。将你的客户端软件更改为使用 watch list。如果你的客户端代码是用 Golang 编写的，你将需要为 client-go 启用 WatchListClient。有关启用该特性的细节，参阅为 client-go 引入特性门控：增强灵活性和控制。

接下来

在 Kubernetes 1.32 中，尽管此特性处于 Beta 状态，但在 kube-controller-manager 中默认被启用。一旦此特性进阶至正式发布（GA），或许更早，此特性最终将被扩展到 kube-scheduler 或 kubelet 这类其他核心组件。我们鼓励其他第三方组件在此特性处于 Beta 阶段时选择使用此特性，特别是这些组件在有可能访问大量资源或对象体量较大的情况下。

目前，API 优先级和公平性为 list 请求带来了少量但合理的开销。这是必要的，以允许在通常 list 请求开销足够低的情况下实现足够的并行性。但这并不适用于对象数量众多、体量巨大的峰值异常情形。一旦大多数 Kubernetes 生态体系切换到 watch list ，就可以将 list 开销估算调整为更大的值，而不必担心在平均情况下出现性能下降，从而提高对未来可能仍会影响 API 服务器的此类请求的保护。

模拟测试

为了重现此问题，我们实施了手动测试，以了解 list 请求对 kube-apiserver 内存使用量的影响。在测试中，我们创建了 400 个 Secret，每个 Secret 包含 1 MB 的数据，并使用 informer 检索所有 Secret。

结果令人担忧，仅需 16 个 informer 就足以导致测试服务器内存耗尽并崩溃，展示了在这些状况下内存消耗快速增长的方式。

特别感谢 @deads2k 在构造此特性所提供的帮助。

Kubernetes 1.33 更新

自该功能启动以来，Marek Siarkowicz 在 Kubernetes API 服务器中加入了一项新技术：流式集合编码。在 Kubernetes v1.33 中，引入了两个相关的特性门控： StreamingCollectionEncodingToJSON 和 StreamingCollectionEncodingToProtobuf。它们通过流的方式进行编码，避免一次性分配所有内存。该功能与现有的 list 编码实现了比特级完全兼容，不仅能更显著地节省服务器端内存，而且无需修改任何客户端代码。在 1.33 版本中，WatchList 特性门控默认是禁用的。

Kubernetes v1.32 增加了新的 CPU Manager 静态策略选项用于严格 CPU 预留

Mon, 16 Dec 2024 00:00:00 +0000

在 Kubernetes v1.32 中，经过社区多年的讨论，我们很高兴地引入了 CPU Manager 静态策略的 strict-cpu-reservation 选项。此特性当前处于 Alpha 阶段，默认情况下关联的策略是隐藏的。只有在你的集群中明确启用了此 Alpha 行为后，才能使用此策略。

理解此特性

CPU Manager 静态策略用于减少延迟或提高性能。reservedSystemCPUs 定义了一个明确的 CPU 集合，供操作系统系统守护进程和 Kubernetes 系统守护进程使用。此选项专为 Telco/NFV 类型的使用场景设计，在这些场景中，不受控制的中断/计时器可能会影响工作负载的性能。你可以使用此选项为系统/Kubernetes 守护进程以及中断/计时器定义明确的 CPU 集合，从而使系统上的其余 CPU 可以专用于工作负载，并减少不受控制的中断/计时器带来的影响。有关此参数的更多详细信息，请参阅显式预留的 CPU 列表页面。

如果你希望保护系统守护进程和中断处理，显而易见的方法是使用 reservedSystemCPUs 选项。

然而，在 Kubernetes v1.32 发布之前，这种隔离仅针对请求整数个 CPU 的 Guaranteed 类型 Pod 实现。在 Pod 准入时，kubelet 仅将 CPU 请求量与可分配的 CPU 进行比较。在 Kubernetes 中，限制值可以高于请求值；之前的实现允许 Burstable 和 BestEffort 类型的 Pod 使用 reservedSystemCPUs 的容量，这可能导致主机操作系统服务缺乏足够的 CPU 资源 —— 并且我们已经知道在实际部署中确实发生过这种情况。现有的行为还导致基础设施和工作负载的基准测试结果不准确。

当启用这个新的 strict-cpu-reservation 策略选项后，CPU Manager 静态策略将不允许任何工作负载使用预留的系统 CPU 核心。

启用此特性

要启用此特性，你需要同时开启 CPUManagerPolicyAlphaOptions 特性门控和 strict-cpu-reservation 策略选项。并且如果存在 /var/lib/kubelet/cpu_manager_state 文件，则需要删除该文件并重启 kubelet。

使用以下 kubelet 配置：

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
featureGates:
  ...
  CPUManagerPolicyOptions: true
  CPUManagerPolicyAlphaOptions: true
cpuManagerPolicy: static
cpuManagerPolicyOptions:
  strict-cpu-reservation: "true"
reservedSystemCPUs: "0,32,1,33,16,48"
...

当未设置 strict-cpu-reservation 或将其设置为 false 时：

# cat /var/lib/kubelet/cpu_manager_state
{"policyName":"static","defaultCpuSet":"0-63","checksum":1058907510}

当 strict-cpu-reservation 设置为 true 时：

# cat /var/lib/kubelet/cpu_manager_state
{"policyName":"static","defaultCpuSet":"2-15,17-31,34-47,49-63","checksum":4141502832}

监控此特性

你可以通过检查以下 CPU Manager 计数器来监控该特性的影响：

cpu_manager_shared_pool_size_millicores：报告共享池大小，以毫核为单位（例如 13500m）
cpu_manager_exclusive_cpu_allocation_count：报告独占分配的核心数，按完整核心计数（例如 16）

如果 cpu_manager_shared_pool_size_millicores 计数在长时间内为零，你的 BestEffort 类型工作负载可能会因资源匮乏而受到影响。

我们建议，任何用于操作目的的 Pod（如日志转发器）都不应以 BestEffort 方式运行，但你可以根据需要审查并调整预留的 CPU 核心数量。

总结

严格的 CPU 预留对于 Telco/NFV 使用场景至关重要。它也是启用一体化部署类型（其中工作负载被放置在同时担任控制面节点、工作节点和存储角色的节点上）的前提条件。

我们希望你开始使用该特性，并期待你的反馈。

进一步阅读

请查看节点上的控制 CPU 管理策略任务页面，以了解更多关于 CPU Manager 的信息，以及它如何与其他节点级资源管理器相关联。

参与其中

此特性由 SIG Node 推动。如果你有兴趣帮助开发此特性、分享反馈或参与任何其他正在进行的 SIG Node 项目，请参加 SIG Node 会议以获取更多详情。

Kubernetes v1.32：内存管理器进阶至 GA

Fri, 13 Dec 2024 00:00:00 +0000

随着 Kubernetes 1.32 的发布，内存管理器已进阶至正式发布（GA），这标志着在为容器化应用实现高效和可预测的内存分配的旅程中迈出了重要的一步。内存管理器自 Kubernetes v1.22 进阶至 Beta 后，其可靠性、稳定性已得到证实，是 CPU 管理器的一个良好补充特性。

作为 kubelet 的工作负载准入过程的一部分，内存管理器提供拓扑提示以优化内存分配和对齐。这使得用户能够为 Guaranteed QoS 类的 Pod 分配独占的内存。有关此过程的细节，参见博客：内存管理器进阶至 Beta。

自 Beta 以来引入的大部分变更是修复 Bug、内部重构以及改进可观测性（例如优化指标和日志）。

改进可观测性

作为提高内存管理器可观测性工作的一部分，新增了一些指标以提供关于内存分配模式的某些统计信息。

memory_manager_pinning_requests_total - 跟踪 Pod 规约要求内存管理器锁定内存页的次数。
memory_manager_pinning_errors_total - 跟踪 Pod 规约要求内存管理器锁定内存页但分配失败的次数。

提高内存管理器可靠性和一致性

kubelet 不保证在 Pod 重启或重新引导后准入 Pod 的顺序。

在某些边缘情况下，这种行为可能导致内存管理器拒绝某些 Pod，在更极端的情况下，可能导致 kubelet 在重启时失败。

以前，Beta 实现缺乏某些检查和逻辑来防止这些问题的发生。

为了使内存管理器更为稳定，以便为进阶至正式发布（GA）做好准备，我们对算法进行了小而美的改进，提高了其稳健性和对边缘场景的处理能力。

未来发展

总体而言，未来对拓扑管理器（Topology Manager），特别是内存管理器，会有更多特性推出。值得一提的是，目前的工作重心是将内存管理器支持扩展到 Windows，使得在 Windows 操作系统上实现 CPU 和内存亲和性成为可能。

参与其中

此特性由 SIG Node 社区推动。请加入我们，与社区建立联系，分享你对上述特性及其他方面的想法和反馈。我们期待听到你的声音！

Kubernetes Blog

Headlamp 2025 年度项目亮点

更新

加入 Kubernetes SIG UI

Linux Foundation 导师计划

新变更

多集群视图

项目

导航和活动

搜索和映射

OIDC 和身份认证

应用目录和 Helm

性能、可访问性和用户体验

插件和可扩展性

Headlamp AI 助手

新增插件

其他插件更新

插件开发

安全升级

结论

Kubernetes v1.35：云控制器管理器中的基于监视的路由协调

新特性

关于此特性门控

如何了解更多？

Kubernetes v1.35: 通过就地重启 Pod 实现更高的效率

问题：当单个容器重启不足以解决问题，而重新创建 Pod 成本过高时

引入 RestartAllContainers 操作

应用案例

1. 高效重启机器学习/批处理作业

2. 重新运行初始化容器以确保干净状态

3. 处理高频率的类似任务执行

使用方法

观察重启

了解更多

我们期待你的反馈！

Kubernetes v1.35：扩展容忍度运算符以支持数值比较（Alpha）

容忍度的演进

为什么要扩展容忍度，而不是用节点亲和性（NodeAffinity）？

引入 Gt 与 Lt 运算符

说明：

使用场景与示例

示例 1：用 SLA 阈值限制 spot 实例的使用

示例 2：基于 GPU 分层的 AI 工作负载放置

示例 3：面向成本优化的工作负载放置

示例 4：基于性能的放置

如何使用该特性

说明：

下一步计划是什么？

参与其中

如何了解更多？

Kubernetes v1.35：Job Managed By 特性正式发布（GA）

为何要委派 Job 调谐？

.spec.managedBy 的工作机制

生态采纳情况

如何进一步了解？

致谢

参与其中

Kubernetes v1.35：Timbernetes（世界树版本）

发布主题与徽标

重点更新速览

稳定（GA）阶段：Pod 资源原地更新

Beta：用于工作负载身份与安全的 Pod 证书

Alpha：调度前节点声明式特性

进入稳定（GA）阶段的特性

PreferSameNode 流量分配

Job API 的 managed-by 机制

使用 .metadata.generation 可靠跟踪 Pod 更新

为拓扑管理器提供可配置 NUMA 节点上限

Beta 中的新特性

通过 Downward API 暴露节点拓扑标签

存储版本迁移的原生支持

可变更的卷挂接上限

机会式批处理

StatefulSet 的 maxUnavailable

kuberc 中可配置的凭据插件策略

KYAML

可配置的 HorizontalPodAutoscalers 容忍度

Pod 中的用户命名空间支持

VolumeSource：OCI 工件和/或镜像

对缓存镜像强制执行 kubelet 凭据校验

引入 `RestartAllContainers` 操作

`.spec.managedBy` 的工作机制

使用 `.metadata.generation` 可靠跟踪 Pod 更新

StatefulSet 的 `maxUnavailable`

`kuberc` 中可配置的凭据插件策略

对缓存镜像强制执行 `kubelet` 凭据校验

`kubelet` 重启期间的 Pod 稳定性改进

除非绝对必要，否则避免使用 `hostPort` 和 `hostNetwork`