Kubernetes Blog

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 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 v1.32：QueueingHint 为优化 Pod 调度带来了新的可能

Thu, 12 Dec 2024 00:00:00 +0000

Kubernetes 调度器是为新 Pod 选择运行节点的核心组件，调度器会逐一处理这些新 Pod。因此，集群规模越大，调度器的吞吐量就越重要。

多年来，Kubernetes SIG Scheduling 通过多次增强改进了调度器的吞吐量。本博客文章描述了 Kubernetes v1.32 中对调度器的一项重大改进：一个名为 QueueingHint 的调度上下文元素。本页面提供了关于调度器的背景知识，并解释了 QueueingHint 如何提升调度吞吐量。

调度队列

调度器将所有未调度的 Pod 存储在一个名为调度队列的内部组件中。

调度队列由以下数据结构组成：

ActiveQ：保存新创建的 Pod 或准备重试调度的 Pod。
BackoffQ：保存准备重试但正在等待退避期结束的 Pod。退避期取决于调度器对该 Pod 执行的不成功调度尝试次数。
无法调度的 Pod 池：保存调度器不会尝试调度的 Pod，原因可能包括以下几点：
- 调度器之前尝试调度这些 Pod 但未能成功。自那次尝试以来，集群没有发生任何使得这些 Pod 可以被调度的变化。
- 这些 Pod 被 PreEnqueue 插件阻止进入调度周期，例如，它们具有一个调度门控，并被调度门控插件阻止。

调度框架和插件

Kubernetes 调度器的实现遵循 Kubernetes 的调度框架。

并且，所有的调度特性都是以插件的形式实现的（例如，Pod 亲和性是在 InterPodAffinity 插件中实现的。）

调度器按照称为周期的阶段来处理待调度的 Pod，具体如下：

调度周期（Scheduling cycle）：调度器从调度队列的 activeQ 组件中逐一取出待调度的 Pod。对于每个 Pod，调度器会运行来自每个调度插件的过滤/评分逻辑。然后，调度器决定最适合该 Pod 的节点，或者决定当前无法调度该 Pod。

如果调度器决定一个 Pod 无法被调度，该 Pod 将进入调度队列的无法调度的 Pod 池（Unschedulable Pod Pool）组件。然而，如果调度器决定将 Pod 放置到某个节点上，该 Pod 将进入绑定周期（Binding cycle）。
绑定周期（Binding cycle）：调度器将节点分配决策传达给 Kubernetes API 服务器。这一操作将 Pod 绑定到选定的节点。

除了少数例外情况，大多数未调度的 Pod 在每次调度周期后都会进入无法调度的 Pod 池。无法调度的 Pod 池组件至关重要，因为调度周期是逐个处理 Pod 的。如果调度器需要不断重试放置那些无法调度的 Pod，而不是将这些 Pod 分载到无法调度的 Pod 池中，将会在这些 Pod 上浪费很多调度周期。

使用 QueueingHint 改进 Pod 调度重试

无法调度的 Pod 仅在集群发生可能允许调度器将这些 Pod 放置到节点上的变化时，才会重新移入调度队列的 ActiveQ 或 BackoffQ 组件。

在 v1.32 之前，每个插件通过 EnqueueExtensions（EventsToRegister）注册哪些集群变化（称为集群事件，即集群中的对象创建、更新或删除）可以解决其失败情况。当某个插件在之前的调度周期中拒绝了某个 Pod 后，调度队列会在出现该插件注册的事件时重试该 Pod 的调度。

此外，我们还拥有一个名为 preCheck 的内部特性，它基于 Kubernetes 核心调度约束进一步过滤事件以提高效率；例如，preCheck 可以在节点状态为 NotReady 时过滤掉与节点相关的事件。

然而，这些方法存在两个问题：

基于事件的重新排队过于宽泛，可能会导致毫无来由的调度重试。
- 新调度的 Pod 可能解决 InterPodAffinity 失败的问题，但并非所有新 Pod 都能做到。例如，如果创建了一个新的 Pod，但该 Pod 没有与无法调度的 Pod 的 InterPodAffinity 匹配的标签，则该 Pod 仍然无法被调度。
preCheck 依赖于 in-tree 插件的逻辑，并且不适用于自定义插件，如在问题 #110175 中所述。

在这里，QueueingHints 发挥了作用；QueueingHint 订阅特定类型的集群事件，并决定每个传入的事件是否可以使 Pod 变得可调度。

例如，考虑一个名为 pod-a 的 Pod，它具有必需的 Pod 亲和性。pod-a 在调度周期中被 InterPodAffinity 插件拒绝，因为没有节点上有现有的 Pod 符合 pod-a 的 Pod 亲和性规约。

显示调度队列和被 InterPodAffinity 插件拒绝的 pod-a 的图示

pod-a 移入无法调度的 Pod 池 (Unschedulable Pod Pool)。调度队列记录了导致 Pod 调度失败的插件。对于 pod-a，调度队列记录了 InterPodAffinity 插件拒绝了该 Pod。

pod-a 在 InterPodAffinity 失败被解决之前将永远不会被调度。有一些情景可以解决这一失败，例如，一个现有的运行中的 Pod 获取了标签更新并符合 Pod 亲和性要求。在这种情况下，InterPodAffinity 插件的 QueuingHint 回调函数会检查集群中发生的每一个 Pod 标签更新。然后，如果一个 Pod 的标签更新符合 pod-a 的 Pod 亲和性要求，InterPodAffinity 插件的 QueuingHint 会提示调度队列将 pod-a 重新移入 ActiveQ 或 BackoffQ 组件。

显示调度队列和由 InterPodAffinity QueuingHint 移动的 pod-a 的图示

QueueingHint 的历史及 v1.32 中的新变化

在 SIG Scheduling，我们自 Kubernetes v1.28 开始就致力于 QueueingHint 的开发。

尽管 QueueingHint 并不是面向用户的特性，我们在最初添加此特性时还是实现了 SchedulerQueueingHints 特性门控作为安全措施。在 v1.28 中，我们实验性地为几个 in-tree 插件实现了 QueueingHints，并将该特性门控默认启用。

然而，用户报告了一个内存泄漏问题，因此我们在 v1.28 的一个补丁版本中禁用了该特性门控。从 v1.28 到 v1.31，我们一直在其余的 in-tree 插件中继续开发 QueueingHint，并修复相关 bug。

在 v1.32 中，我们再次默认启用了这一特性。我们完成了所有插件中 QueueingHints 的实现，并且找到了内存泄漏的原因！

我们感谢所有参与此特性开发的贡献者，以及那些报告和调查早期问题的用户。

参与其中

这些特性由 Kubernetes SIG Scheduling 管理。

请加入我们并分享你的反馈。

如何了解更多？

KEP-4247：为调度队列中的高效重新排队实现每插件回调函数

Kubernetes v1.32 预览

Fri, 08 Nov 2024 00:00:00 +0000

随着 Kubernetes v1.32 发布日期的临近，Kubernetes 项目继续发展和成熟。在这个过程中，某些特性可能会被弃用、移除或被更好的特性取代，以确保项目的整体健康与发展。

本文概述了 Kubernetes v1.32 发布的一些计划变更，发布团队认为你应该了解这些变更，以确保你的 Kubernetes 环境得以持续维护并跟上最新的变化。以下信息基于 v1.32 发布的当前状态，实际发布日期前可能会有所变动。

Kubernetes API 的移除和弃用流程

Kubernetes 项目对功能特性有一个文档完备的弃用策略。该策略规定，只有当较新的、稳定的相同 API 可用时，原有的稳定 API 才可能被弃用，每个稳定级别的 API 都有一个最短的生命周期。弃用的 API 指的是已标记为将在后续发行某个 Kubernetes 版本时移除的 API；移除之前该 API 将继续发挥作用（从弃用起至少一年时间），但使用时会显示一条警告。移除的 API 将在当前版本中不再可用，此时你必须迁移以使用替换的 API。

正式发布的（GA）或稳定的 API 版本可被标记为已弃用，但不得在 Kubernetes 主要版本未变时删除。
Beta 或预发布 API 版本，必须保持在被弃用后 3 个发布版本中仍然可用。
Alpha 或实验性 API 版本可以在任何版本中删除，不必提前通知；如果同一特性已有不同实施方案，则此过程可能会成为撤销。

无论 API 是因为特性从 Beta 升级到稳定状态还是因为未能成功而被移除，所有移除操作都遵守此弃用策略。每当 API 被移除时，迁移选项都会在弃用指南中进行说明。

关于撤回 DRA 的旧的实现的说明

增强特性 #3063 在 Kubernetes 1.26 中引入了动态资源分配（DRA）。

然而，在 Kubernetes v1.32 中，这种 DRA 的实现方法将发生重大变化。与原来实现相关的代码将被删除，只留下 KEP #4381 作为"新"的基础特性。

改变现有方法的决定源于其与集群自动伸缩的不兼容性，因为资源可用性是不透明的，这使得 Cluster Autoscaler 和控制器的决策变得复杂。新增的结构化参数模型替换了原有特性。

这次移除将使 Kubernetes 能够更可预测地处理新的硬件需求和资源声明，避免了与 kube-apiserver 之间复杂的来回 API 调用。

请参阅增强问题 #3063 以了解更多信息。

API 移除

在 Kubernetes v1.32 中，计划仅移除一个 API：

flowcontrol.apiserver.k8s.io/v1beta3 版本的 FlowSchema 和 PriorityLevelConfiguration 已被移除。为了对此做好准备，你可以编辑现有的清单文件并重写客户端软件，使用自 v1.29 起可用的 flowcontrol.apiserver.k8s.io/v1 API 版本。所有现有的持久化对象都可以通过新 API 访问。flowcontrol.apiserver.k8s.io/v1beta3 中的重要变化包括：当未指定时，PriorityLevelConfiguration 的 spec.limited.nominalConcurrencyShares 字段仅默认为 30，而显式设置的 0 值不会被更改为此默认值。

有关更多信息，请参阅 API 弃用指南。

Kubernetes v1.32 的抢先预览

以下增强特性有可能会被包含在 v1.32 发布版本中。请注意，这并不是最终承诺，发布内容可能会发生变化。

Windows 工作继续

KEP #4802 为 Kubernetes 集群中的 Windows 节点添加了体面关机支持。在此之前，Kubernetes 为 Linux 节点提供了体面关机特性，但缺乏对 Windows 节点的同等支持。这一增强特性使 Windows 节点上的 kubelet 能够正确处理系统关机事件，确保在 Windows 节点上运行的 Pod 能够体面终止，从而允许工作负载在不受干扰的情况下重新调度。这一改进提高了包含 Windows 节点的集群的可靠性和稳定性，特别是在计划维护或系统更新期间。

允许环境变量中使用特殊字符

随着这一增强特性升级到 Beta 阶段， Kubernetes 现在允许几乎所有的可打印 ASCII 字符（不包括 =）作为环境变量名称。这一变化解决了此前对变量命名的限制，通过适应各种应用需求，促进了 Kubernetes 的更广泛采用。放宽的验证将通过 RelaxedEnvironmentVariableValidation 特性门控默认启用，确保用户可以轻松使用环境变量而不受严格限制，增强了开发者在处理需要特殊字符配置的应用（如 .NET Core）时的灵活性。

使 Kubernetes 感知到 LoadBalancer 的行为

KEP #1860 升级到 GA 阶段，为 type: LoadBalancer 类型的 Service 引入了 ipMode 字段，该字段可以设置为 "VIP" 或 "Proxy"。这一增强旨在改善云提供商负载均衡器与 kube-proxy 的交互方式，对最终用户来说是透明的。使用 "VIP" 时，kube-proxy 会继续处理负载均衡，保持现有的行为。使用 "Proxy" 时，流量将直接发送到负载均衡器，提供云提供商对依赖 kube-proxy 的更大控制权；这意味着对于某些云提供商，你可能会看到负载均衡器性能的提升。

为资源生成名称时重试

这一增强特性改进了使用 generateName 字段创建 Kubernetes 资源时的名称冲突处理。此前，如果发生名称冲突， API 服务器会返回 409 HTTP 冲突错误，客户端需要手动重试请求。通过此次更新， API 服务器在发生冲突时会自动重试生成新名称，最多重试七次。这显著降低了冲突的可能性，确保生成多达 100 万个名称时冲突的概率低于 0.1%，为大规模工作负载提供了更高的弹性。

想了解更多？

新特性和弃用特性也会在 Kubernetes 发布说明中宣布。我们将在此次发布的 Kubernetes v1.32 的 CHANGELOG 中正式宣布新内容。

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

关于日本的 Kubernetes 上游培训的特别报道

Mon, 28 Oct 2024 00:00:00 +0000

我们是日本 Kubernetes 上游培训的组织者。我们的团队由积极向 Kubernetes 做贡献的成员组成，他们在社区中担任了 Member、Reviewer、Approver 和 Chair 等角色。

我们的目标是增加 Kubernetes 贡献者的数量，并促进社区的成长。虽然 Kubernetes 社区友好协作，但新手可能会发现迈出贡献的第一步有些困难。我们的培训项目旨在降低壁垒，创造一个即使是初学者也能顺利参与的环境。

日本 Kubernetes 上游培训是什么？

我们的培训始于 2019 年，每年举办 1 到 2 次。最初，Kubernetes 上游培训曾作为 KubeCon（Kubernetes 贡献者峰会）的同场地活动进行，后来我们在日本推出了 Kubernetes 上游培训，目的是通过在日本举办类似活动来增加日本的贡献者。

在疫情之前，培训是面对面进行的，但自 2020 年以来，我们已转为在线上进行。培训为尚未参与过 Kubernetes 贡献的学员提供以下内容：

Kubernetes 社区简介
Kubernetes 代码库概述以及如何创建你的第一个 PR
各种降低参与壁垒（如语言）的提示和鼓励
如何搭建开发环境
使用 kubernetes-sigs/contributor-playground 开展实践课程

在培训开始时，我们讲解为什么贡献 Kubernetes 很重要以及谁可以做贡献。我们强调，贡献 Kubernetes 可以让你产生全球影响，而 Kubernetes 社区期待着你的贡献！

我们还讲解 Kubernetes 社区、SIG（特别兴趣小组）和 WG（工作组）。接下来，我们讲解 Member、Reviewer、Approver、Tech Lead 和 Chair 的角色与职责。此外，我们介绍大家所使用的主要沟通工具，如 Slack、GitHub 和邮件列表。一些讲日语的人可能会觉得用英语沟通是一个障碍。此外，社区的新人需要理解在哪儿以及如何与人交流。我们强调迈出第一步的重要性，这是我们培训中最关注的方面！

然后，我们讲解 Kubernetes 代码库的结构、主要的仓库、如何创建 PR 以及使用 Prow 的 CI/CD 流程。我们详细讲解从创建 PR 到合并 PR 的过程。

经过几节课后，参与者将体验使用 kubernetes-sigs/contributor-playground 开展实践工作，在那里他们可以创建一个简单的 PR。目标是让参与者体验贡献 Kubernetes 的过程。

在项目结束时，我们还提供关于为贡献 kubernetes/kubernetes 仓库搭建开发环境的详细说明，包括如何在本地构建代码、如何高效运行测试以及如何搭建集群。

与参与者的访谈

我们对参与我们培训项目的人进行了访谈。我们询问了他们参加的原因、印象和未来目标。

Keita Mochizuki（NTT DATA 集团公司）

Keita Mochizuki 是一位持续为 Kubernetes 及相关项目做贡献的贡献者。他还是容器安全领域的专业人士，他最近出版了一本书。此外，他还发布了一份新贡献者路线图，对新贡献者非常有帮助。

Junya： 你为什么决定参加 Kubernetes 上游培训？

Keita： 实际上，我分别在 2020 年和 2022 年参加过两次培训。在 2020 年，我刚开始学习 Kubernetes，想尝试参与工作以外的活动，所以在 Twitter 上偶然看到活动后报了名参加了活动。然而，那时我的知识积累还不多，贡献 OSS 感觉超出了我的能力。因此，在培训后的理解比较肤浅，离开时更多是“嗯，好吧”的感觉。

在 2022 年，我再次参加，那时我认真考虑开始贡献。我事先进行了研究，并能够在讲座中解决我的问题，那次经历非常有成效。

Junya： 参加后你有什么感受？

Keita： 我觉得培训的意义很大程度上取决于参与者的心态。培训本身包括常规的讲解和简单的实践练习，但这并不意味着参加培训就会立即会去做贡献。

Junya： 你贡献的目的是什么？

Keita： 我最初的动机是“深入理解 Kubernetes 并生成成绩记录”，也就是说“贡献本身就是目标”。如今，我还会通过贡献来解决我在工作中发现的 Bug 或约束。此外，通过贡献，我变得不再那么犹豫，会去直接基于源代码分析了解没有文档记录的特性。

Junya： 贡献中遇到的挑战是什么？

Keita： 最困难的部分是迈出第一步。贡献 OSS 需要一定的知识水平，利用像这样的培训和他人的支持至关重要。一句让我印象深刻的话是，“一旦你迈出第一步，后续就会变得更容易。”
此外，在作为工作的一部分继续贡献时，最具挑战性的是将输出的结果变为成就感。要保持长期贡献，将贡献与业务目标和策略对齐非常重要，但上游贡献并不总是能直接产生与表现相关的即时结果。因此，确保与管理人员的相互理解并获得他们的支持至关重要。

Junya： 你未来的目标是什么？

Keita： 我的目标是对影响更大的领域做出贡献。到目前为止，我主要通过修复较小的 Bug 来做贡献，因为我的主要关注是生成一份成绩单，但未来，我希望挑战自己对 Kubernetes 用户产生更大影响的贡献，或解决与我工作相关的问题。最近，我还在努力将我对代码库所做的更改反映到官方文档中，我将这视为实现我目标的一步。

Junya： 非常感谢！

Yoshiki Fujikane（CyberAgent, Inc.）

Yoshiki Fujikane 是 CNCF 沙盒项目 PipeCD 的维护者之一。除了在 PipeCD 中开发对 Kubernetes 支持的新特性外， Yoshiki 还积极参与社区管理，并在各种技术会议上发言。

Junya： 你为什么决定参加 Kubernetes 上游培训？

Yoshiki： 当我参与培训时，我还是一名学生。我只简短地接触过 EKS，我觉得 Kubernetes 看起来复杂但很酷，我对此有一种随意的兴趣。当时，OSS 对我来说感觉像是遥不可及，而 Kubernetes 的上游开发似乎非常令人生畏。虽然我一直对 OSS 感兴趣，但我不知道从哪里开始。也就在那个时候，我了解到 Kubernetes 上游培训，并决定挑战自己为 Kubernetes 做贡献。

Junya： 参加后你的印象是什么？

Yoshiki： 我发现对于了解如何成为 OSS 社区的一部分，这种培训是一种非常有价值的方式。当时，我的英语水平不是很好，所以获取主要信息源对我来说是一个很大的障碍。 Kubernetes 是一个非常大的项目，我对整体结构没有清晰的理解，更不用说贡献所需的内容了。上游培训提供了对社区结构的日文解释，并让我获得了实际贡献的实践经验。得益于我所得到的指导，我学会了如何接触主要信息源，并将其作为进一步研究的切入点，这对我帮助很大。这次经历让我意识到组织和评审主要信息源的重要性，现在我经常在 GitHub Issue 和文档中深入研究我感兴趣的内容。因此，虽然我不再直接向 Kubernetes 做贡献，但这次经历为我在其他项目中做贡献奠定了很好的基础。

Junya： 你目前在哪些领域做贡献？你参与了哪些其他项目？

Yoshiki： 目前，我不再从事 Kubernetes 的工作，而是担任 CNCF 沙盒项目 PipeCD 的维护者。 PipeCD 是一个支持各种应用平台的 GitOps 式部署的 CD 工具。此工具最初作为 CyberAgent 的内部项目启动。随着不同团队采用不同的平台，PipeCD 设计为提供一个统一的 CD 平台，确保用户体验一致。目前，它支持 Kubernetes、AWS ECS、Lambda、Cloud Run 和 Terraform。

Junya： 你在 PipeCD 团队中扮演什么角色？

Yoshiki： 我全职负责团队中与 Kubernetes 相关特性的改进和开发。由于我们将 PipeCD 作为内部 SaaS 提供，我的主要关注点是添加新特性和改进现有特性，确保 PipeCD 能够持续良好支持 Kubernetes 等平台。除了代码贡献外，我还通过在各种活动上发言和管理社区会议来帮助发展 PipeCD 社区。

Junya： 你能讲解一下你对于 Kubernetes 正在进行哪些改进或开发吗？

Yoshiki： PipeCD 支持 Kubernetes 的 GitOps 和渐进式交付，因此我参与这些特性的开发。最近，我一直在开发简化跨多个集群部署的特性。

Junya： 在贡献 OSS 的过程中，你遇到过哪些挑战？

Yoshiki： 一个挑战是开发在满足用户用例的同时保持通用性的特性。当我们在运营内部 SaaS 期间收到特性请求时，我们首先考虑添加特性来解决这些问题。与此同时，我们希望 PipeCD 作为一个 OSS 工具被更广泛的受众使用。因此，我总是思考为一个用例设计的特性是否可以应用于其他用例，以确保 PipeCD 这个软件保持灵活且广泛可用。

Junya： 你未来的目标是什么？

Yoshiki： 我希望专注于扩展 PipeCD 的功能。目前，我们正在以“普遍可用的持续交付”（One CD for All）的口号开发 PipeCD。正如我之前提到的，它支持 Kubernetes、AWS ECS、Lambda、Cloud Run 和 Terraform，但还有许多其他平台，以及未来可能会出现的新平台。因此，我们目前正在开发一个插件系统，允许用户自行扩展 PipeCD，我希望将这一努力向前推进。我也在处理 Kubernetes 的多集群部署特性，目标是继续做出有影响力的贡献。

Junya： 非常感谢！

Kubernetes 上游培训的未来

我们计划继续在日本举办 Kubernetes 上游培训，并期待欢迎更多的新贡献者。我们的下一次培训定于 11 月底在 CloudNative Days Winter 2024 期间举行。

此外，我们的目标不仅是在日本推广这些培训项目，还希望推广到全球。今年的 Kubernetes 十周年庆，以及为了使社区更加活跃，让全球各地的人们持续贡献至关重要。虽然上游培训已经在多个地区举行，但我们希望将其带到更多地方。

我们希望随着越来越多的人加入 Kubernetes 社区并做出贡献，我们的社区将变得更加生机勃勃！

公布 2024 年指导委员会选举结果

Wed, 02 Oct 2024 15:10:00 -0500

2024 年指导委员会选举现已完成。 Kubernetes 指导委员会由 7 个席位组成，其中 3 个席位于 2024 年进行选举。新任委员会成员的任期为 2 年，所有成员均由 Kubernetes 社区选举产生。

这个社区机构非常重要，因为它负责监督整个 Kubernetes 项目的治理。权力越大责任越大，你可以在其章程中了解有关指导委员会角色的更多信息。

感谢所有在选举中投票的人；你们的参与有助于支持社区的持续健康和成功。

结果

祝贺当选的委员会成员，其两年任期立即开始（按 GitHub 句柄按字母顺序列出）：

Antonio Ojea (@aojea), Google
Benjamin Elder (@BenTheElder), Google
Sascha Grunert (@saschagrunert), Red Hat

他们将与以下连任成员一起工作：

Stephen Augustus (@justaugustus), Cisco
Paco Xu 徐俊杰 (@pacoxu), DaoCloud
Patrick Ohly (@pohly), Intel
Maciej Szulik (@soltysh), Defense Unicorns

Benjamin Elder 是一位回归的指导委员会成员。

十分感谢！

感谢并祝贺本轮选举官员成功完成选举工作：

Bridget Kromhout (@bridgetkromhout)
Christoph Blecker (@cblecker)
Priyanka Saggu (@Priyankasaggu11929)

感谢名誉指导委员会成员，你们的服务受到社区的赞赏：

Bob Killen (@mrbobbytables)
Nabarun Pal (@palnabarun)

感谢所有前来竞选的候选人。

参与指导委员会

这个管理机构与所有 Kubernetes 一样，向所有人开放。你可以关注指导委员会会议记录，并通过提交 Issue 或针对其 repo 创建 PR 来参与。他们在太平洋时间每月第一个周一上午 8:00 举行开放的会议。你还可以通过其公共邮件列表 steering@kubernetes.io 与他们联系。

你可以通过在 YouTube 播放列表上观看过去的会议来了解指导委员会会议的全部内容。

如果你想认识一些新当选的指导委员会成员，欢迎参加在盐湖城举行的 2024 年北美 Kubernetes 贡献者峰会上的 Steering AMA。

这篇文章是由贡献者通信子项目撰写的。如果你想撰写有关 Kubernetes 社区的故事，请了解有关我们的更多信息。

SIG Scheduling 访谈

Tue, 24 Sep 2024 00:00:00 +0000

在本次 SIG Scheduling 的访谈中，我们与 Kensei Nakada 进行了交流，他是 SIG Scheduling 的一名 Approver。

介绍

Arvind: 你好，感谢你让我们有机会了解 SIG Scheduling！你能介绍一下自己，告诉我们你的角色以及你是如何参与 Kubernetes 的吗？

Kensei: 嗨，感谢你给我这个机会！我是 Kensei Nakada (@sanposhiho)，是来自 Tetrate.io 的一名软件工程师。我在业余时间为 Kubernetes 贡献了超过 3 年的时间，现在我是 Kubernetes 中 SIG Scheduling 的一名 Approver。同时，我还是两个 SIG 子项目的创始人/负责人： kube-scheduler-simulator 和 kube-scheduler-wasm-extension。

关于 SIG Scheduling

AP: 太棒了！你参与这个项目已经很久了。你能简要概述一下 SIG Scheduling，并说明它在 Kubernetes 生态系统中的角色吗？

KN: 正如名字所示，我们的责任是增强 Kubernetes 中的调度特性。具体来说，我们开发了一些组件，将每个 Pod 调度到最合适的 Node。在 Kubernetes 中，我们的主要关注点是维护 kube-scheduler，以及其他调度相关的组件，这些组件是 SIG Scheduling 的子项目。

AP: 明白了！我有点好奇，SIG Scheduling 最近为 Kubernetes 调度引入了哪些创新或发展？

KN: 从特性的角度来看，最近对 PodTopologySpread 进行了几项增强。 PodTopologySpread 是调度器中一个相对较新的特性，我们仍在收集反馈并进行改进。

最近，我们专注于一个内部增强特性，称为 QueueingHint，这个特性旨在提高调度的吞吐量。吞吐量是我们调度中的关键指标之一。传统上，我们主要关注优化每个调度周期的延迟。而 QueueingHint 采取了一种不同的方法，它可以优化何时重试调度，从而减少浪费调度周期的可能性。

A: 听起来很有趣！你目前在 SIG Scheduling 中还有其他有趣的主题或项目吗？

KN: 我正在牵头刚刚提到的 QueueingHint 的开发。考虑到这是我们面临的一项重大新挑战，我们遇到了许多意想不到的问题，特别是在可扩展性方面，我们正在努力解决每一个问题，使这项特性最终能够默认启用。

此外，我认为我去年启动的 kube-scheduler-wasm-extension（SIG 子项目）对许多人来说也会很有趣。Kubernetes 有各种扩展来自许多组件。传统上，扩展通过 Webhook （调度器中的 extender）或 Go SDK（调度器中的调度框架）提供。然而，这些方法存在缺点，首先是 Webhook 的性能问题以及需要重建和替换调度器的 Go SDK，这就给那些希望扩展调度器但对其不熟悉的人带来了困难。此项目尝试引入一种新的解决方案来应对这一普遍挑战，即基于 WebAssembly 的扩展。 Wasm 允许用户轻松构建插件，而无需担心重新编译或替换调度器，还能规避性能问题。

通过这个项目，SIG Scheduling 正在积累 WebAssembly 与大型 Kubernetes 对象交互的宝贵洞察。我相信我们所获得的经验应该对整个社区都很有用，而不仅限于 SIG Scheduling 的范围。

A: 当然！目前 SIG Scheduling 有 8 个子项目。你想谈谈它们吗？有没有一些你想强调的有趣贡献？

KN: 让我挑选三个子项目：Kueue、KWOK 和 Descheduler。

Kueue:: 最近，许多人尝试使用 Kubernetes 管理批处理工作负载，2022 年，Kubernetes 社区成立了 WG-Batch，以更好地支持 Kubernetes 中的此类批处理工作负载。 Kueue 是一个在其中扮演关键角色的项目。它是一个作业队列控制器，决定何时一个作业应该等待，何时一个作业应该被准许启动，以及何时一个作业应该被抢占。 Kueue 旨在安装在一个普通的 Kubernetes 集群上，同时与现有的成熟控制器（调度器、cluster-autoscaler、kube-controller-manager 等）协作。

KWOK: KWOK 这个组件可以在几秒钟内创建一个包含数千个节点的集群。它主要用于模拟/测试轻量级集群，实际上另一个 SIG 子项目 kube-scheduler-simulator 就在后端使用了 KWOK。
Descheduler: Descheduler 这个组件可以将运行在不理想的节点上的 Pod 重新创建。在 Kubernetes 中，调度约束（PodAffinity、NodeAffinity、PodTopologySpread 等）仅在 Pod 调度时被考虑，但不能保证这些约束在之后仍然被满足。Descheduler 会驱逐违反其调度约束（或其他不符合预期状况）的 Pod，以便这些 Pod 被重新创建和重新调度。

Descheduling Framework:: 一个非常有趣的正在进行的项目，类似于调度器中的调度框架，旨在使去调度逻辑可扩展，并允许维护者们专注于构建 Descheduler 的核心引擎。

AP: 感谢你告诉我们这些！我想问一下，你最喜欢这个 SIG 的哪些方面？

KN: 我真正喜欢这个 SIG 的地方在于每个人都积极参与。我们来自不同的公司和行业，带来了多样的视角。这些差异并没有造成分歧，实际上产生了丰富的观点。每种观点都会受到尊重，这使我们的讨论既丰富又富有成效。

我非常欣赏这种协作氛围，我相信这对我们多年来不断改进组件至关重要。

给 SIG Scheduling 做贡献

AP: Kubernetes 是一个社区驱动的项目。你对新贡献者或希望参与并为 SIG Scheduling 做出贡献的初学者有什么建议？他们应该从哪里开始？

KN: 让我先给出一个关于为任何 SIG 贡献的通用建议：一种常见的方法是寻找 good-first-issue。然而，你很快就会意识到，世界各地有很多人正在尝试为 Kubernetes 仓库做贡献。

我建议先查看你感兴趣的某个组件的实现。如果你对该组件有任何疑问，可以在相应的 Slack 频道中提问（例如，调度器的 #sig-scheduling，kubelet 的 #sig-node 等）。一旦你对实现有了大致了解，就可以查看 SIG 中的 Issue （例如，sig-scheduling），相比 good-first-issue，在这里你会发现更多未分配的 Issue。你可能还想过滤带有 kind/cleanup 标签的 Issue，这通常表示较低优先级的任务，可以作为起点。

具体对于 SIG Scheduling 而言，你应该先了解调度框架，这是 kube-scheduler 的基本架构。大多数实现都可以在 pkg/scheduler中找到。我建议从 ScheduleOne 函数开始，然后再深入探索。

此外，除了 kubernetes/kubernetes 主仓库外，还可以考虑查看一些子项目。这些子项目的维护者通常比较少，你有更多的机会来对其产生重大影响。尽管被称为“子”项目，但许多项目实际上有大量用户，并对社区产生了相当大的影响。

最后但同样重要的是，记住为社区做贡献不仅仅是编写代码。虽然我谈到了很多关于实现的贡献，但还有许多其他方式可以做贡献，每一种都很有价值。对某个 Issue 的一条评论，对现有特性的一个反馈，对 PR 的一个审查建议，对文档的一个说明阐述；每一个小贡献都有助于推动 Kubernetes 生态系统向前发展。

AP: 这些建议非常有用！冒昧问一下，你是如何帮助新贡献者入门的，参与 SIG Scheduling 的贡献者可能会学习到哪些技能？

KN: 我们的维护者在 #sig-scheduling Slack 频道中随时可以回答你的问题。多多参与，你将深入了解 Kubernetes 的调度，并有机会与来自不同背景的维护者合作和建立联系。你将学习到的不仅仅是如何编写代码，还有如何维护大型项目、设计和讨论新特性、解决 Bug 等等。

未来方向

AP: 在调度方面，Kubernetes 特有的挑战有哪些？有没有特别的痛点？

KN: 在 Kubernetes 中进行调度可能相当具有挑战性，因为不同组织有不同的业务要求。在 kube-scheduler 中支持所有可能的使用场景是不可能的。因此，可扩展性是我们关注的核心焦点。几年前，我们使用调度框架为 kube-scheduler 重新设计了架构，为用户通过插件实现各种调度需求提供了灵活的可扩展性。这使得维护者们能够专注于核心调度特性和框架运行时。

另一个主要问题是保持足够的调度吞吐量。通常，一个 Kubernetes 集群只有一个 kube-scheduler，因此其吞吐量直接影响整体调度的可扩展性，从而影响集群的可扩展性。尽管我们有一个内部性能测试 (scheduler_perf)，但不巧的是，我们有时会忽视在不常见场景下的性能下降。即使是与性能无关的小改动也有难度，可能导致性能下降。

AP: 接下来 SIG Scheduling 有哪些即将实现的目标或计划？你如何看待 SIG 的未来发展？

KN: 我们的主要目标始终是构建和维护可扩展的和稳定的调度运行时，我敢打赌这个目标将永远不会改变。

正如之前所提到的，可扩展性是解决调度多样化需求挑战的关键。我们不会尝试直接在 kube-scheduler 中支持每种不同的使用场景，而是将继续专注于增强可扩展性，以便能够适应各种用例。我提到的 kube-scheduler-wasm-extension 也是这一计划的一部分。

关于稳定性，引入 QueueHint 这类新的优化是我们的一项策略。此外，保持吞吐量也是面向未来的关键目标。我们计划增强我们的吞吐量监控 (参考)，以便在发布之前尽可能多地发现性能下降问题。但实际上，我们无法覆盖每个可能的场景。我们非常感谢社区对调度吞吐量的关注，鼓励大家提出反馈，就性能问题提出警示！

结束语

AP: 最后，你想对那些有兴趣了解 SIG Scheduling 的人说些什么？

KN: 调度是 Kubernetes 中最复杂的领域之一，你可能一开始会觉得很困难。但正如我之前分享的，你可以找到许多贡献的机会，许多维护者愿意帮助你理解各事项。我们知道你独特的视角和技能是我们的开源项目能够如此强大的源泉 😊

随时可以通过 Slack (#sig-scheduling) 或会议联系我们。我希望这篇文章能引起大家的兴趣，希望能吸引到新的贡献者！

AP: 非常感谢你抽出时间进行这次访谈！我相信很多人会发现这些信息对理解 SIG Scheduling 和参与 SIG 的贡献非常有价值。

Kubernetes v1.31：kubeadm v1beta4

Fri, 23 Aug 2024 00:00:00 +0000

作为 Kubernetes v1.31 发布的一部分，kubeadm 采用了全新版本（v1beta4）的配置文件格式。之前 v1beta3 格式的配置现已正式弃用，这意味着尽管之前的格式仍然受支持，但你应迁移到 v1beta4 并停止使用已弃用的格式。对 v1beta3 配置的支持将在至少 3 次 Kubernetes 次要版本发布后被移除。

在本文中，我将介绍关键的变更；我将解释 kubeadm v1beta4 配置格式，以及如何从 v1beta3 迁移到 v1beta4。

你可以参阅 v1beta4 配置格式的参考文档： kubeadm 配置 (v1beta4)。

自 v1beta3 以来的变更列表

此版本通过修复一些小问题并添加一些新字段来改进 v1beta3 格式。

简单而言，

增加了两个新的配置元素：ResetConfiguration 和 UpgradeConfiguration
对于 InitConfiguration 和 JoinConfiguration，支持 dryRun 模式和 nodeRegistration.imagePullSerial
对于 ClusterConfiguration，新增字段包括 certificateValidityPeriod、caCertificateValidityPeriod、 encryptionAlgorithm、dns.disabled 和 proxy.disabled
所有控制平面组件支持 extraEnvs
extraArgs 从映射变更为支持重复的结构化额外参数
为 init、join、upgrade 和 reset 添加了 timeouts 结构

有关细节请参阅以下官方文档：

在 ClusterConfiguration 下支持控制平面组件的自定义环境变量。可以使用 apiServer.extraEnvs、controllerManager.extraEnvs、scheduler.extraEnvs、etcd.local.extraEnvs。
ResetConfiguration API 类型现在在 v1beta4 中得到支持。用户可以通过将 --config 文件传递给 kubeadm reset 来重置节点。
dryRun 模式现在在 InitConfiguration 和 JoinConfiguration 中可配置。

用支持重复的结构化额外参数替换现有的 string/string 额外参数映射。此变更适用于 ClusterConfiguration - apiServer.extraArgs、controllerManager.extraArgs、 scheduler.extraArgs、etcd.local.extraArgs。也适用于 nodeRegistrationOptions.kubeletExtraArgs。
添加了 ClusterConfiguration.encryptionAlgorithm，可用于设置此集群的密钥和证书所使用的非对称加密算法。可以是 "RSA-2048"（默认）、"RSA-3072"、"RSA-4096" 或 "ECDSA-P256" 之一。
添加了 ClusterConfiguration.dns.disabled 和 ClusterConfiguration.proxy.disabled，可用于在集群初始化期间禁用 CoreDNS 和 kube-proxy 插件。在集群创建期间跳过相关插件阶段将把相同的字段设置为 true。

在 InitConfiguration 和 JoinConfiguration 中添加了 nodeRegistration.imagePullSerial 字段，可用于控制 kubeadm 是顺序拉取镜像还是并行拉取镜像。
当将 --config 传递给 kubeadm upgrade 子命令时，现已在 v1beta4 中支持 UpgradeConfiguration kubeadm API。对于升级子命令，kubelet 和 kube-proxy 的组件配置以及 InitConfiguration 和 ClusterConfiguration 的用法现已弃用，并将在传递 --config 时被忽略。
在 InitConfiguration、JoinConfiguration、ResetConfiguration 和 UpgradeConfiguration 中添加了 timeouts 结构，可用于配置各种超时。 ClusterConfiguration.timeoutForControlPlane 字段被 timeouts.controlPlaneComponentHealthCheck 替换。 JoinConfiguration.discovery.timeout 被 timeouts.discovery 替换。

向 ClusterConfiguration 添加了 certificateValidityPeriod 和 caCertificateValidityPeriod 字段。这些字段可用于控制 kubeadm 在 init、join、upgrade 和 certs 等子命令中生成的证书的有效期。默认值继续为非 CA 证书 1 年和 CA 证书 10 年。另请注意，只有非 CA 证书可以通过 kubeadm certs renew 进行续期。

这些变更简化了使用 kubeadm 的工具的配置，并提高了 kubeadm 本身的可扩展性。

如何将 v1beta3 配置迁移到 v1beta4？

如果你的配置未使用最新版本，建议你使用 kubeadm config migrate 命令进行迁移。

此命令读取使用旧格式的现有配置文件，并写入一个使用当前格式的新文件。

示例

使用 kubeadm v1.31，运行 kubeadm config migrate --old-config old-v1beta3.yaml --new-config new-v1beta4.yaml

我该如何参与？

衷心感谢在此特性的设计、实现和评审中提供帮助的所有贡献者：

Lubomir I. Ivanov (neolit123)
Dave Chen (chendave)
Paco Xu (pacoxu)
Sata Qiu (sataqiu)
Baofa Fan (carlory)
Calvin Chen (calvin0327)
Ruquan Zhao (ruquanzhao)

如果你有兴趣参与 kubeadm 配置的后续讨论，可以通过多种方式与 kubeadm 或 SIG-cluster-lifecycle 联系：

v1beta4 相关事项在 kubeadm issue #2890 中跟踪。
Slack: #kubeadm 或 #sig-cluster-lifecycle
邮件列表

Kubernetes 1.31：kubectl debug 中的自定义模板化配置特性已进入 Beta 阶段

Thu, 22 Aug 2024 00:00:00 +0000

有很多方法可以对集群中的 Pod 和节点进行故障排查，而 kubectl debug 是最简单、使用最广泛、最突出的方法之一。它提供了一组静态配置，每个配置适用于不同类型的角色。例如，从网络管理员的视角来看，调试节点应该像这样简单：

$ kubectl debug node/mynode -it --image=busybox --profile=netadmin

另一方面，静态配置也存在固有的刚性，对某些 Pod 所产生的影响与其易用性是相悖的。因为各种类型的 Pod（或节点）都有其特定的需求，不幸的是，有些问题仅通过静态配置是无法调试的。

以一个简单的 Pod 为例，此 Pod 由一个容器组成，其健康状况依赖于环境变量：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: customapp:latest
    env:
    - name: REQUIRED_ENV_VAR
      value: "value1"

目前，复制 Pod 是使用 kubectl debug 命令调试此 Pod 的唯一机制。此外，如果用户需要将 REQUIRED_ENV_VAR 环境变量修改为其他不同值来进行高级故障排查，当前并没有机制能够实现这一需求。

自定义模板化配置

自定义模板化配置使用 --custom 标志提供的一项新特性，在 kubectl debug 中引入以提供可扩展性。它需要以 YAML 或 JSON 格式的内容填充 container 规约，为了通过创建临时容器来调试上面的示例容器，我们只需定义此 YAML：

# partial_container.yaml
env:
  - name: REQUIRED_ENV_VAR
    value: value2

并且执行：

kubectl debug example-pod -it --image=customapp --custom=partial_container.yaml

下面是另一个在 JSON 中一次修改多个字段（更改端口号、添加资源限制、修改环境变量）的示例：

{
  "ports": [
    {
      "containerPort": 80
    }
  ],
  "resources": {
    "limits": {
      "cpu": "0.5",
      "memory": "512Mi"
    },
    "requests": {
      "cpu": "0.2",
      "memory": "256Mi"
    }
  },
  "env": [
    {
      "name": "REQUIRED_ENV_VAR",
      "value": "value2"
    }
  ]
}

约束

不受控制的扩展性会损害可用性。因此，某些字段（例如命令、镜像、生命周期、卷设备和容器名称）不允许进行自定义模版化配置。将来如果需要，可以将更多字段添加到禁止列表中。

限制

kubectl debug 命令有 3 个方面：使用临时容器进行调试、Pod 复制和节点调试。这些方面最大的交集是 Pod 内的容器规约，因此自定义模版化配置仅支持修改使用 containers 下定义的字段。这导致了一个限制，如果用户需要修改 Pod 规约中的其他字段，则不受支持。

致谢

特别感谢所有审查和评论此特性（从最初的概念到实际实施）的贡献者（按字母顺序排列）：

Kubernetes 1.31：细粒度的 SupplementalGroups 控制

Thu, 22 Aug 2024 00:00:00 +0000

本博客讨论了 Kubernetes 1.31 中的一项新特性，目的是改善处理 Pod 中容器内的附加组。

动机：容器镜像中 `/etc/group` 中定义的隐式组成员关系

尽管这种行为可能并不受许多 Kubernetes 集群用户/管理员的欢迎，但 Kubernetes 默认情况下会将 Pod 中的组信息与容器镜像中 /etc/group 中定义的信息进行合并。

让我们看一个例子，以下 Pod 在 Pod 的安全上下文中指定了 runAsUser=1000、runAsGroup=3000 和 supplementalGroups=4000。

implicit-groups.yaml

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

在 ctr 容器中执行 id 命令的结果是什么？

# 创建 Pod：
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/implicit-groups.yaml

# 验证 Pod 的容器正在运行：
$ kubectl get pod implicit-groups

# 检查 id 命令
$ kubectl exec implicit-groups -- id

输出应类似于：

uid=1000 gid=3000 groups=3000,4000,50000

尽管 50000 根本没有在 Pod 的清单中被定义，但附加组中的组 ID 50000（groups 字段）是从哪里来的呢？答案是容器镜像中的 /etc/group 文件。

检查容器镜像中 /etc/group 的内容应如下所示：

$ kubectl exec implicit-groups -- cat /etc/group
...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

原来如此！容器的主要用户 1000 属于最后一个条目中的组 50000。

因此，容器镜像中为容器的主要用户定义的组成员关系会被隐式合并到 Pod 的信息中。请注意，这是当前 CRI 实现从 Docker 继承的设计决策，而社区直到现在才重新考虑这个问题。

这有什么问题？

从容器镜像中的 /etc/group 隐式合并的组信息可能会引起一些担忧，特别是在访问卷时（有关细节参见 kubernetes/kubernetes#112879），因为在 Linux 中文件权限是通过 uid/gid 进行控制的。更糟糕的是，隐式的 gid 无法被任何策略引擎所检测/验证，因为在清单中没有隐式组信息的线索。这对 Kubernetes 的安全性也可能构成隐患。

Pod 中的细粒度 SupplementalGroups 控制：`SupplementaryGroupsPolicy`

为了解决上述问题，Kubernetes 1.31 在 Pod 的 .spec.securityContext 中引入了新的字段 supplementalGroupsPolicy。

此字段提供了一种控制 Pod 中容器进程如何计算附加组的方法。可用的策略如下：

Merge：将容器的主要用户在 /etc/group 中定义的组成员关系进行合并。如果不指定，则应用此策略（即为了向后兼容性而保持的原有行为）。
Strict：仅将 fsGroup、supplementalGroups 或 runAsGroup 字段中指定的组 ID 挂接为容器进程的附加组。这意味着容器的主要用户在 /etc/group 中定义的任何组成员关系都不会被合并。

让我们看看 Strict 策略是如何工作的。

strict-supplementalgroups-policy.yaml

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

# 创建 Pod：
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/strict-supplementalgroups-policy.yaml

# 验证 Pod 的容器正在运行：
$ kubectl get pod strict-supplementalgroups-policy

# 检查进程身份：
kubectl exec -it strict-supplementalgroups-policy -- id

输出应类似于：

uid=1000 gid=3000 groups=3000,4000

你可以看到 Strict 策略可以将组 50000 从 groups 中排除出去！

因此，确保（通过某些策略机制强制执行的）supplementalGroupsPolicy: Strict 有助于防止 Pod 中的隐式附加组。

说明：

实际上，这还不够，因为具有足够权限/能力的容器可以更改其进程身份。有关细节参见以下章节。

Pod 状态中挂接的进程身份

此特性还通过 .status.containerStatuses[].user.linux 字段公开挂接到容器的第一个容器进程的进程身份。这将有助于查看隐式组 ID 是否被挂接。

...
status:
  containerStatuses:
  - name: ctr
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

说明：

请注意，status.containerStatuses[].user.linux 字段中的值是首次挂接到容器中第一个容器进程的进程身份。如果容器具有足够的权限调用与进程身份相关的系统调用（例如 setuid(2)、 setgid(2) 或 setgroups(2) 等），则容器进程可以更改其身份。因此，实际的进程身份将是动态的。

特性可用性

要启用 supplementalGroupsPolicy 字段，必须使用以下组件：

Kubernetes：v1.31 或更高版本，启用 SupplementalGroupsPolicy 特性门控。截至 v1.31，此门控标记为 Alpha。
CRI 运行时：
- containerd：v2.0 或更高版本
- CRI-O：v1.31 或更高版本

你可以在 Node 的 .status.features.supplementalGroupsPolicy 字段中查看此特性是否受支持。

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

接下来

Kubernetes SIG Node 希望并期待此特性将在 Kubernetes 后续版本中进阶至 Beta，并最终进阶至正式发布（GA），以便用户不再需要手动启用特性门控。

当 supplementalGroupsPolicy 未被指定时，将应用 Merge 策略，以保持向后兼容性。

我如何了解更多？

为 Pod 或容器配置安全上下文以获取有关 supplementalGroupsPolicy 的更多细节
KEP-3619：细粒度 SupplementalGroups 控制

如何参与？

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

Kubernetes v1.31：全新的 Kubernetes CPUManager 静态策略：跨核分发 CPU

Thu, 22 Aug 2024 00:00:00 +0000

在 Kubernetes v1.31 中，我们很高兴引入了对 CPU 管理能力的重大增强：针对 CPUManager 静态策略的 distribute-cpus-across-cores 选项。此特性目前处于 Alpha 阶段，默认被隐藏，标志着旨在优化 CPU 利用率和改善多核处理器系统性能的战略转变。

理解这一特性

传统上，Kubernetes 的 CPUManager 倾向于尽可能紧凑地分配 CPU，通常将这些 CPU 打包到尽可能少的物理核上。然而，分配策略很重要，因为同一物理主机上的 CPU 仍然共享一些物理核的资源，例如缓存和执行单元等。

虽然默认方法可以最小化核间通信，并在某些情况下是有益的，但也带来了挑战。在同一物理核上共享的 CPU 可能导致资源竞争，从而可能造成性能瓶颈，这在 CPU 密集型应用中尤为明显。

全新的 distribute-cpus-across-cores 特性通过修改分配策略来解决这个问题。当此特性被启用时，此策略选项指示 CPUManager 尽可能将 CPU（硬件线程）分发到尽可能多的物理核上。这种分发旨在最小化共享同一物理核的 CPU 之间的争用，从而通过为应用提供专用的核资源来潜在提高性能。

从技术上讲，在这个静态策略中，可用的 CPU 列表按照图示的方式重新排序，旨在从不同的物理核分配 CPU。

启用此特性

要启用此特性，用户首先需要在 kubelet 配置中添加 --cpu-manager-policy=static kubelet 标志或 cpuManagerPolicy: static 字段。然后用户可以在 Kubernetes 配置中添加 --cpu-manager-policy-options distribute-cpus-across-cores=true 或 distribute-cpus-across-cores=true 到自己的 CPUManager 策略选项中。此设置指示 CPUManager 采用新的分发策略。需要注意的是，目前此策略选项无法与 full-pcpus-only 或 distribute-cpus-across-numa 选项一起使用。

当前限制和未来方向

与所有新特性一样，尤其是处于 Alpha 阶段的特性，此特性也存在一些限制，很多方面还有待后续改进。当前一个显著的限制是 distribute-cpus-across-cores 不能与可能在 CPU 分配策略上存在冲突的其他策略选项结合使用。这一限制可能会影响与（依赖于更专业的资源管理的）某些工作负载和部署场景的兼容性。

展望未来，我们将致力于增强 distribute-cpus-across-cores 选项的兼容性和特性。未来的更新将专注于解决这些兼容性问题，使此策略能够与其他 CPUManager 策略无缝结合。我们的目标是提供一个更灵活和强大的 CPU 分配框架，能够适应各种工作负载和性能需求。

结论

在 Kubernetes CPUManager 中引入 distribute-cpus-across-cores 策略是我们持续努力改进资源管理和提升应用性能而向前迈出的一步。通过减少物理核上的争用，此特性提供了更加平衡的 CPU 资源分配方法，特别有利于运行异构工作负载的环境。我们鼓励 Kubernetes 用户测试这一新特性并提供反馈，这将对其未来发展至关重要。

本文旨在清晰地解释这一新特性，同时设定对其当前阶段和未来改进的期望。

进一步阅读

请查阅节点上的 CPU 管理策略任务页面，以了解有关 CPU 管理器的更多信息，以及 CPU 管理器与其他节点级资源管理器的关系。

参与其中

此特性由 SIG Node 推动。如果你有兴趣帮助开发此特性、分享反馈或参与其他目前 SIG Node 项目的工作，请参加 SIG Node 会议了解更多细节。

Kubernetes 1.31: 节点 Cgroup 驱动程序的自动配置 (beta)

Wed, 21 Aug 2024 00:00:00 +0000

一直以来，为新运行的 Kubernetes 集群配置正确的 cgroup 驱动程序是用户的一个痛点。在 Linux 系统中，存在两种不同的 cgroup 驱动程序：cgroupfs 和 systemd。过去，kubelet 和 CRI 实现（如 CRI-O 或 containerd）需要配置为使用相同的 cgroup 驱动程序，否则 kubelet 会报错并退出。这让许多集群管理员头疼不已。不过，现在曙光乍现！

自动检测 cgroup 驱动程序

在 v1.28.0 版本中，SIG Node 社区引入了 KubeletCgroupDriverFromCRI 特性门控，它指示 kubelet 向 CRI 实现询问使用哪个 cgroup 驱动程序。在两个主要的 CRI 实现（containerd 和 CRI-O）增加对该功能的支持这段期间，Kubernetes 经历了几次小版本发布，但从 v1.31.0 版本开始，此功能现已进入 beta 阶段！

除了设置特性门控之外，集群管理员还需要确保 CRI 实现版本足够新：

containerd：v2.0.0 版本开始支持
CRI-O：v1.28.0 版本开始支持

然后，他们应该确保配置其 CRI 实现使用他们想要的 cgroup 驱动程序。

未来工作

最终，kubelet 对 cgroupDriver 配置字段的支持将会被移除，如果 CRI 实现的版本不够新，无法支持此功能，kubelet 将无法启动。

Kubernetes 1.31：流式传输从 SPDY 转换为 WebSocket

Tue, 20 Aug 2024 00:00:00 +0000

在 Kubernetes 1.31 中，kubectl 现在默认使用 WebSocket 协议而不是 SPDY 进行流式传输。

这篇文章介绍了这些变化对你意味着什么以及这些流式传输 API 的重要性。

Kubernetes 中的流式 API

在 Kubernetes 中，某些以 HTTP 或 RESTful 接口公开的某些端点会被升级为流式连接，因而需要使用流式协议。与 HTTP 这种请求-响应协议不同，流式协议提供了一种持久的双向连接，具有低延迟的特点，并允许实时交互。流式协议支持在客户端与服务器之间通过同一个连接进行双向的数据读写。这种类型的连接非常有用，例如，当你从本地工作站在某个运行中的容器内创建 shell 并在该容器中运行命令时。

为什么要改变流式传输协议？

在 v1.31 版本发布之前，Kubernetes 默认使用 SPDY/3.1 协议来升级流式连接。但是 SPDY/3.1 已经被废弃了八年之久，并且从未被标准化，许多现代代理、网关和负载均衡器已经不再支持该协议。因此，当你尝试通过代理或网关访问集群时，可能会发现像 kubectl cp、kubectl attach、kubectl exec 和 kubectl port-forward 这样的命令无法正常工作。

从 Kubernetes v1.31 版本开始，SIG API Machinery 修改了 Kubernetes 客户端（如 kubectl）中用于这些命令的流式传输协议，将其改为更现代化的 WebSocket 流式传输协议。 WebSocket 协议是一种当前得到支持的标准流式传输协议，它可以确保与不同组件及编程语言之间的兼容性和互操作性。相较于 SPDY，WebSocket 协议更为广泛地被现代代理和网关所支持。

流式 API 的工作原理

Kubernetes 通过在原始的 HTTP 请求中添加特定的升级头字段来将 HTTP 连接升级为流式连接。例如，在集群内的 nginx 容器上运行 date 命令的 HTTP 升级请求类似于以下内容：

$ kubectl exec -v=8 nginx -- date
GET https://127.0.0.1:43251/api/v1/namespaces/default/pods/nginx/exec?command=date…
Request Headers:
    Connection: Upgrade
    Upgrade: websocket
    Sec-Websocket-Protocol: v5.channel.k8s.io
    User-Agent: kubectl/v1.31.0 (linux/amd64) kubernetes/6911225

如果容器运行时支持 WebSocket 流式协议及其至少一个子协议版本（例如 v5.channel.k8s.io），服务器会以代表成功的 101 Switching Protocols 状态码进行响应，并附带协商后的子协议版本：

Response Status: 101 Switching Protocols in 3 milliseconds
Response Headers:
    Upgrade: websocket
    Connection: Upgrade
    Sec-Websocket-Accept: j0/jHW9RpaUoGsUAv97EcKw8jFM=
    Sec-Websocket-Protocol: v5.channel.k8s.io

此时，原本用于 HTTP 协议的 TCP 连接已转换为流式连接。随后，此 Shell 交互中的标准输入（STDIN）、标准输出（STDOUT）和标准错误输出（STDERR）数据（以及终端重置大小数据和进程退出码数据）会通过这个升级后的连接进行流式传输。

如何使用新的 WebSocket 流式协议

如果你的集群和 kubectl 版本为 1.29 及以上版本，有两个控制面特性门控以及两个 kubectl 环境变量用来控制启用 WebSocket 而不是 SPDY 作为流式协议。在 Kubernetes 1.31 中，以下所有特性门控均处于 Beta 阶段，并且默认被启用：

特性门控
- TranslateStreamCloseWebsocketRequests
  - .../exec
  - .../attach
- PortForwardWebsockets
  - .../port-forward
kubectl 特性控制环境变量
- KUBECTL_REMOTE_COMMAND_WEBSOCKETS
  - kubectl exec
  - kubectl cp
  - kubectl attach
- KUBECTL_PORT_FORWARD_WEBSOCKETS
  - kubectl port-forward

如果你正在使用一个较旧的集群但可以管理其特性门控设置，那么可以通过开启 TranslateStreamCloseWebsocketRequests（在 Kubernetes v1.29 中添加）和 PortForwardWebsockets（在 Kubernetes v1.30 中添加）来尝试启用 Websocket 作为流式传输协议。版本为 1.31 的 kubectl 可以自动使用新的行为，但你需要连接到明确启用了服务器端特性的集群。

了解有关流式 API 的更多信息

Kubernetes 1.31：针对 Job 的 Pod 失效策略进阶至 GA

Mon, 19 Aug 2024 00:00:00 +0000

这篇博文阐述在 Kubernetes 1.31 中进阶至 Stable 的 Pod 失效策略，还介绍如何在你的 Job 中使用此策略。

关于 Pod 失效策略

当你在 Kubernetes 上运行工作负载时，Pod 可能因各种原因而失效。理想情况下，像 Job 这样的工作负载应该能够忽略瞬时的、可重试的失效，并继续运行直到完成。

要允许这些瞬时的失效，Kubernetes Job 需包含 backoffLimit 字段，此字段允许你指定在 Job 执行期间你愿意容忍的 Pod 失效次数。然而，如果你为 backoffLimit 字段设置了一个较大的值，并完全依赖这个字段，你可能会发现，由于在满足 backoffLimit 条件之前 Pod 重启次数太多，导致运营成本发生不必要的增加。

在运行大规模的、包含跨数千节点且长时间运行的 Pod 的 Job 时，这个问题尤其严重。

Pod 失效策略扩展了回退限制机制，帮助你通过以下方式降低成本：

让你在出现不可重试的 Pod 失效时控制 Job 失败。
允许你忽略可重试的错误，而不增加 backoffLimit 字段。

例如，通过忽略由节点体面关闭引起的 Pod 失效，你可以使用 Pod 失效策略在更实惠的临时机器上运行你的工作负载。

此策略允许你基于失效 Pod 中的容器退出码或 Pod 状况来区分可重试和不可重试的 Pod 失效。

它是如何工作的

你在 Job 规约中指定的 Pod 失效策略是一个规则的列表。

对于每个规则，你基于以下属性之一来定义匹配条件：

容器退出码：onExitCodes 属性。
Pod 状况：onPodConditions 属性。

此外，对于每个规则，你要指定在 Pod 与此规则匹配时应采取的动作，可选动作为以下之一：

Ignore：不将失效计入 backoffLimit 或 backoffLimitPerIndex。
FailJob：让整个 Job 失败并终止所有运行的 Pod。
FailIndex：与失效 Pod 对应的索引失效。
此动作与逐索引回退限制特性一起使用。
Count：将失效计入 backoffLimit 或 backoffLimitPerIndex。这是默认行为。

当在运行的 Job 中发生 Pod 失效时，Kubernetes 按所给的顺序将失效 Pod 的状态与 Pod 失效策略规则的列表进行匹配，并根据匹配的第一个规则采取相应的动作。

请注意，在指定 Pod 失效策略时，你还必须在 Job 的 Pod 模板中设置 restartPolicy: Never。此字段可以防止在对 Pod 失效计数时在 kubelet 和 Job 控制器之间出现竞争条件。

Kubernetes 发起的 Pod 干扰

为了允许将 Pod 失效策略规则与由 Kubernetes 引发的干扰所导致的失效进行匹配，此特性引入了 DisruptionTarget Pod 状况。

Kubernetes 会将此状况添加到因可重试的干扰场景而失效的所有 Pod，无论其是否由 Job 控制器管理。其中 DisruptionTarget 状况包含与这些干扰场景对应的以下原因之一：

PreemptionByKubeScheduler：由 kube-scheduler 抢占以接纳更高优先级的新 Pod。
DeletionByTaintManager - Pod 因其不容忍的 NoExecute 污点而被 kube-controller-manager 删除。
EvictionByEvictionAPI - Pod 因为 API 发起的驱逐而被删除。
DeletionByPodGC - Pod 被绑定到一个不再存在的节点，并将通过 Pod 垃圾收集而被删除。
TerminationByKubelet - Pod 因节点体面关闭、节点压力驱逐或被系统关键 Pod抢占

在所有其他干扰场景中，例如因超过 Pod 容器限制而驱逐， Pod 不会收到 DisruptionTarget 状况，因为干扰可能是由 Pod 引起的，并且在重试时会再次发生干扰。

示例

下面的 Pod 失效策略片段演示了一种用法：

podFailurePolicy:
  rules:
  - action: Ignore
    onPodConditions:
    - type: DisruptionTarget
  - action: FailJob
    onPodConditions:
    - type: ConfigIssue
  - action: FailJob
    onExitCodes:
      operator: In
      values: [ 42 ]

在这个例子中，Pod 失效策略执行以下操作：

忽略任何具有内置 DisruptionTarget 状况的失效 Pod。这些 Pod 不计入 Job 回退限制。
如果任何失效的 Pod 具有用户自定义的、由自定义控制器或 Webhook 添加的 ConfigIssue 状况，则让 Job 失败。
如果任何容器以退出码 42 退出，则让 Job 失败。
将所有其他 Pod 失效计入默认的 backoffLimit（在合适的情况下，计入 backoffLimitPerIndex）。

进一步了解

有关使用 Pod 失效策略的实践指南，参见使用 Pod 失效策略处理可重试和不可重试的 Pod 失效
阅读文档：Pod 失效策略和逐索引回退限制
阅读文档：Pod 干扰状况
阅读 KEP：Pod 失效策略

参与其中

这项工作由 Batch Working Group（批处理工作组）发起，与 SIG Apps、 SIG Node 和 SIG Scheduling 社区密切合作。

如果你有兴趣处理这个领域中的新特性，建议你订阅我们的 Slack 频道，并参加定期的社区会议。

感谢

我想感谢在这些年里参与过这个项目的每个人。这是一段旅程，也是一个社区共同努力的见证！以下名单是我尽力记住并对此特性产生过影响的人。感谢大家！

Aldo Culquicondor 在整个过程中提供指导和审查
Jordan Liggitt 审查 KEP 和 API
David Eads 审查 API
Maciej Szulik 从 SIG Apps 角度审查 KEP
Clayton Coleman 提供指导和 SIG Node 审查
Sergey Kanzhelev 从 SIG Node 角度审查 KEP
Dawn Chen 从 SIG Node 角度审查 KEP
Daniel Smith 从 SIG API Machinery 角度进行审查
Antoine Pelisse 从 SIG API Machinery 角度进行审查
John Belamaric 审查 PRR
Filip Křepinský 从 SIG Apps 角度进行全面审查并修复 Bug
David Porter 从 SIG Node 角度进行全面审查
Jensen Lo 进行早期需求讨论、测试和报告问题
Daniel Vega-Myhre 推进 JobSet 集成并报告问题
Abdullah Gharaibeh 进行早期设计讨论和指导
Antonio Ojea 审查测试
Yuki Iwai 审查并协调相关 Job 特性的实现
Kevin Hannon 审查并协调相关 Job 特性的实现
Tim Bannister 审查文档
Shannon Kularathna 审查文档
Paola Cortés 审查文档

Kubernetes 1.31：podAffinity 中的 matchLabelKeys 进阶至 Beta

Fri, 16 Aug 2024 00:00:00 +0000

Kubernetes 1.29 在 podAffinity 和 podAntiAffinity 中引入了新的字段 matchLabelKeys 和 mismatchLabelKeys。

在 Kubernetes 1.31 中，此特性进阶至 Beta，并且相应的特性门控（MatchLabelKeysInPodAffinity）默认启用。

`matchLabelKeys` - 为多样化滚动更新增强了调度

在工作负载（例如 Deployment）的滚动更新期间，集群中可能同时存在多个版本的 Pod。
然而，调度器无法基于 podAffinity 或 podAntiAffinity 中指定的 labelSelector 区分新旧版本。结果，调度器将并置或分散调度 Pod，不会考虑这些 Pod 的版本。

这可能导致次优的调度结果，例如：

新版本的 Pod 与旧版本的 Pod（podAffinity）并置在一起，这些旧版本的 Pod 最终将在滚动更新后被移除。
旧版本的 Pod 被分布在所有可用的拓扑中，导致新版本的 Pod 由于 podAntiAffinity 无法找到节点。

matchLabelKeys 是一组 Pod 标签键，可以解决上述问题。
调度器从新 Pod 的标签中查找这些键的值，并将其与 labelSelector 结合，以便 podAffinity 匹配到具有相同标签键值的 Pod。

通过在 matchLabelKeys 中使用标签 pod-template-hash，
你可以确保对 podAffinity 或 podAntiAffinity 进行评估时仅考虑相同版本的 Pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-server
...
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
        topologyKey: topology.kubernetes.io/zone
        matchLabelKeys:
        - pod-template-hash

上述 Pod 中的 matchLabelKeys 将被转换为：

kind: Pod
metadata:
  name: application-server
  labels:
    pod-template-hash: xyz
...
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
          - key: pod-template-hash # 从 matchLabelKeys 添加; 只有来自同一 ReplicaSet 的 Pod 将与此亲和性匹配
            operator: In
            values:
            - xyz 
        topologyKey: topology.kubernetes.io/zone
        matchLabelKeys: 
        - pod-template-hash

`mismatchLabelKeys` - 服务隔离

mismatchLabelKeys 是一组 Pod 标签键，类似于 matchLabelKeys，
它在新 Pod 的标签中查找这些键的值，并将其与 labelSelector 合并为 key notin (value)，以便 podAffinity 不会匹配到具有相同标签键值的 Pod。

假设每个租户的所有 Pod 通过控制器或像 Helm 这样的清单管理工具得到 tenant 标签。

尽管在组合每个工作负载的清单时，tenant 标签的值是未知的，
但集群管理员希望实现租户与域之间形成排他性的 1:1 对应关系，以便隔离租户。

mismatchLabelKeys 适用于这一使用场景；
通过使用变更性质的 Webhook 在全局应用以下亲和性，集群管理员可以确保来自同一租户的 Pod 将以独占方式落到同一域上，
这意味着来自其他租户的 Pod 不会落到同一域上。

affinity:
  podAffinity:      # 确保此租户的 Pod 落在同一节点池上
    requiredDuringSchedulingIgnoredDuringExecution:
    - matchLabelKeys:
        - tenant
      topologyKey: node-pool
  podAntiAffinity:  # 确保只有此租户的 Pod 落在同一节点池上
    requiredDuringSchedulingIgnoredDuringExecution:
    - mismatchLabelKeys:
        - tenant
      labelSelector:
        matchExpressions:
        - key: tenant
          operator: Exists
      topologyKey: node-pool

上述的 matchLabelKeys 和 mismatchLabelKeys 将被转换为：

kind: Pod
metadata:
  name: application-server
  labels:
    tenant: service-a
spec: 
  affinity:
    podAffinity:      # 确保此租户的 Pod 落在同一节点池上
      requiredDuringSchedulingIgnoredDuringExecution:
      - matchLabelKeys:
          - tenant
        topologyKey: node-pool
        labelSelector:
          matchExpressions:
          - key: tenant
            operator: In
            values:
            - service-a 
    podAntiAffinity:  # 确保只有此租户的 Pod 落在同一节点池上
      requiredDuringSchedulingIgnoredDuringExecution:
      - mismatchLabelKeys:
          - tenant
        labelSelector:
          matchExpressions:
          - key: tenant
            operator: Exists
          - key: tenant
            operator: NotIn
            values:
            - service-a 
        topologyKey: node-pool

参与其中

这些特性由 Kubernetes SIG Scheduling 管理。

请加入我们并分享你的反馈。我们期待听到你的声音！

了解更多

Kubernetes 1.31：防止无序删除时 PersistentVolume 泄漏

Fri, 16 Aug 2024 00:00:00 +0000

PersistentVolume（简称 PV）具有与之关联的回收策略。回收策略用于确定在删除绑定到 PV 的 PVC 时存储后端需要采取的操作。当回收策略为 Delete 时，期望存储后端释放为 PV 所分配的存储资源。实际上，在 PV 被删除时就需要执行此回收策略。

在最近发布的 Kubernetes v1.31 版本中，一个 Beta 特性允许你配置集群以这种方式运行并执行你配置的回收策略。

在以前的 Kubernetes 版本中回收是如何工作的？

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

通常，如果卷要被删除，对应的预期是为一个已绑定的 PV-PVC 对删除其中的 PVC。不过，对于在删除 PVC 之前可否删除 PV 并没有限制。

首先，我将演示运行旧版本 Kubernetes 的集群的行为。

检索绑定到 PV 的 PVC

检索现有的 PVC example-vanilla-block-pvc：

kubectl get pvc example-vanilla-block-pvc

以下输出显示了 PVC 及其绑定的 PV；此 PV 显示在 VOLUME 列下：

NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
example-vanilla-block-pvc   Bound    pvc-6791fdd4-5fad-438e-a7fb-16410363e3da   5Gi        RWO            example-vanilla-block-sc   19s

删除 PV

当我尝试删除已绑定的 PV 时，kubectl 会话被阻塞，且 kubectl 工具不会将控制权返回给 Shell；例如：

kubectl delete pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

persistentvolume "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" deleted
^C

检索 PV

kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

你可以观察到 PV 处于 Terminating 状态：

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                               STORAGECLASS               REASON   AGE
pvc-6791fdd4-5fad-438e-a7fb-16410363e3da   5Gi        RWO            Delete           Terminating   default/example-vanilla-block-pvc   example-vanilla-block-sc            2m23s

删除 PVC

kubectl delete pvc example-vanilla-block-pvc

如果 PVC 被成功删除，则会看到以下输出：

persistentvolumeclaim "example-vanilla-block-pvc" deleted

集群中的 PV 对象也被删除。当尝试检索 PV 时，你会观察到该 PV 已不再存在：

kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

Error from server (NotFound): persistentvolumes "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" not found

尽管 PV 被删除，但下层存储资源并未被删除，需要手动移除。

总结一下，与 PersistentVolume 关联的回收策略在某些情况下会被忽略。对于 Bound 的 PV-PVC 对，PV-PVC 删除的顺序决定了回收策略是否被执行。如果 PVC 先被删除，则回收策略被执行；但如果在删除 PVC 之前 PV 被删除，则回收策略不会被执行。因此，外部基础设施中关联的存储资产未被移除。

Kubernetes v1.31 的 PV 回收策略

新的行为确保当用户尝试手动删除 PV 时，下层存储对象会从后端被删除。

如何启用新的行为？

要利用新的行为，你必须将集群升级到 Kubernetes v1.31 版本，并运行 CSI external-provisioner v5.0.1 或更高版本。

工作方式

下面是一个带 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.vsphere.vmware.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.vsphere.vmware.com
    fsType: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.vsphere.vmware.com
      type: vSphere CNS Block Volume
    volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
  persistentVolumeReclaimPolicy: Delete
  storageClassName: example-vanilla-block-sc
  volumeMode: Filesystem
status:
  phase: Bound

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

有关 CSI 迁移的卷

本次修复同样适用于 CSI 迁移的卷。

一些注意事项

本次修复不适用于静态制备的树内插件卷。

参考

我该如何参与？

Kubernetes Slack SIG Storage 交流频道是与 SIG Storage 和迁移工作组团队联系的良好媒介。

特别感谢以下人员的用心评审、周全考虑和宝贵贡献：

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

如果你有兴趣参与 CSI 或 Kubernetes Storage 系统任何部分的设计和开发，请加入 Kubernetes Storage SIG。我们正在快速成长，始终欢迎新的贡献者。

Kubernetes 1.31：基于 OCI 工件的只读卷 (Alpha)

Fri, 16 Aug 2024 00:00:00 +0000

Kubernetes 社区正朝着在未来满足更多人工智能（AI）和机器学习（ML）使用场景的方向发展。虽然此项目在过去设计为满足微服务架构，但现在是时候听听最终用户的声音并引入更侧重于 AI/ML 的特性了。

其中一项需求是直接支持与开放容器倡议（OCI）兼容的镜像和工件（称为 OCI 对象）作为原生卷源。这使得用户能够专注于 OCI 标准，且能够使用 OCI 镜像仓库存储和分发任何内容。与此类似的特性让 Kubernetes 项目有机会扩大其使用场景，不再局限于运行特定镜像。

在这一背景下，Kubernetes 社区自豪地展示在 v1.31 中引入的一项新的 Alpha 特性：镜像卷源（KEP-4639）。此特性允许用户在 Pod 中指定一个镜像引用作为卷，并在容器内将其作为卷挂载进行复用：

…
kind: Pod
spec:
  containers:
    - …
      volumeMounts:
        - name: my-volume
          mountPath: /path/to/directory
  volumes:
    - name: my-volume
      image:
        reference: my-image:tag

上述示例的结果是将 my-image:tag 挂载到 Pod 的容器中的 /path/to/directory。

使用场景

此增强特性的目标是在尽可能贴近 kubelet 中现有的容器镜像实现的同时，引入新的 API 接口以支持更广泛的使用场景。

例如，用户可以在 Pod 中的多个容器之间共享一个配置文件，而无需将此文件包含在主镜像中，这样用户就可以将安全风险最小化和并缩减整体镜像大小。用户还可以使用 OCI 镜像打包和分发二进制工件，并直接将它们挂载到 Kubernetes Pod 中，例如用户这样就可以简化其 CI/CD 流水线。

数据科学家、MLOps 工程师或 AI 开发者可以与模型服务器一起在 Pod 中挂载大语言模型权重或机器学习模型权重数据，从而可以更高效地提供服务，且无需将这些模型包含在模型服务器容器镜像中。他们可以将这些模型打包在 OCI 对象中，以利用 OCI 分发机制，还可以确保高效的模型部署。这一新特性允许他们将模型规约/内容与处理它们的可执行文件分开。

另一个使用场景是安全工程师可以使用公共镜像作为恶意软件扫描器，并将私有的（商业的）恶意软件签名挂载到卷中，这样他们就可以加载这些签名且无需制作自己的组合镜像（公共镜像的版权要求可能不允许这样做）。签名数据文件与操作系统或扫描器软件版本无关，总是可以被使用。

但就长期而言，作为此项目的最终用户的你要负责为这一新特性的其他重要使用场景给出规划。 SIG Node 乐于接收与进一步增强此特性以适应更高级的使用场景有关的所有反馈或建议。你可以通过使用 Kubernetes Slack（#sig-node）频道或 SIG Node 邮件列表提供反馈。

详细示例

你需要在 API 服务器以及 kubelet 上启用 Kubernetes Alpha 特性门控 ImageVolume，才能使其正常工作。如果启用了此特性，并且容器运行时支持此特性（如 CRI-O ≥ v1.31），那就可以创建这样一个示例 pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: test
      image: registry.k8s.io/e2e-test-images/echoserver:2.3
      volumeMounts:
        - name: volume
          mountPath: /volume
  volumes:
    - name: volume
      image:
        reference: quay.io/crio/artifact:v1
        pullPolicy: IfNotPresent

此 Pod 使用值为 quay.io/crio/artifact:v1 的 image.reference 声明一个新卷，该字段值引用了一个包含两个文件的 OCI 对象。pullPolicy 的行为与容器镜像相同，允许以下值：

Always：kubelet 总是尝试拉取引用，如果拉取失败，容器创建将失败。
Never：kubelet 从不拉取引用，只使用本地镜像或工件。如果引用不存在，容器创建将失败。
IfNotPresent：kubelet 会在引用已不在磁盘上时进行拉取。如果引用不存在且拉取失败，容器创建将失败。

volumeMounts 字段表示名为 test 的容器应将卷挂载到 /volume 路径下。

如果你现在创建 Pod：

kubectl apply -f pod.yaml

然后通过 exec 进入此 Pod：

kubectl exec -it pod -- sh

那么你就能够查看已挂载的内容：

/ # ls /volume
dir   file
/ # cat /volume/file
2
/ # ls /volume/dir
file
/ # cat /volume/dir/file
1

你已经成功地使用 Kubernetes 访问了 OCI 工件！

容器运行时拉取镜像（或工件），将其挂载到容器中，并最终使其可被直接使用。在实现中有很多细节，这些细节与 kubelet 现有的镜像拉取行为密切相关。例如：

如果提供给 reference 的值包含 :latest 标签，pullPolicy 将默认为 Always，而在任何其他情况下，pullPolicy 在未被设置的情况下都默认为 IfNotPresent。
如果 Pod 被删除并重新创建，卷将被重新解析，这意味着在 Pod 重新创建时将可以访问新的远端内容。如果在 Pod 启动期间未能解析或未能拉取镜像，将会容器启动会被阻止，并可能显著增加延迟。如果拉取镜像失败，将使用正常的卷回退机制进行重试，并将在 Pod 的原因和消息中报告出错原因。

拉取 Secret 的组装方式与容器镜像所用的方式相同，也是通过查找节点凭据、服务账户镜像拉取 Secret 和 Pod 规约中的镜像拉取 Secret 来完成。
OCI 对象被挂载到单个目录中，清单层的合并方式与容器镜像相同。
卷以只读（ro）和非可执行文件（noexec）的方式被挂载。

容器的子路径挂载不被支持（spec.containers[*].volumeMounts.subpath）。
字段 spec.securityContext.fsGroupChangePolicy 对这种卷类型没有影响。
如果已启用，此特性也将与 AlwaysPullImages 准入插件一起工作。

感谢你阅读到这篇博客文章的结尾！对于将此特性作为 Kubernetes v1.31 的一部分交付，SIG Node 感到很高兴也很自豪。

作为这篇博客的作者，我想特别感谢所有参与者！你们都很棒，让我们继续开发之旅！

进一步阅读

Kubernetes 1.31：通过 VolumeAttributesClass 修改卷进阶至 Beta

Thu, 15 Aug 2024 00:00:00 +0000

在 Kubernetes 中，卷由两个属性描述：存储类和容量。存储类是卷的不可变属性，而容量可以通过卷调整大小进行动态变更。

这使得使用卷的工作负载的垂直扩缩容变得复杂。虽然云厂商和存储供应商通常提供了一些允许指定注入 IOPS 或吞吐量等 IO 服务质量（性能）参数的卷，并允许在工作负载运行期间调整这些参数，但 Kubernetes 没有提供用来更改这些参数的 API。

我们很高兴地宣布，自 Kubernetes 1.29 起以 Alpha 引入的 VolumeAttributesClass KEP 将在 1.31 中进入 Beta 阶段。这一机制提供了一个通用的、Kubernetes 原生的 API，可用来修改诸如所提供的 IO 能力这类卷参数。

类似于 Kubernetes 中所有新的卷特性，此 API 是通过容器存储接口（CSI）实现的。除了 VolumeAttributesClass 特性门控外，特定于制备器的 CSI 驱动还必须支持此特性在 CSI 一侧的全新的 ModifyVolume API。

有关细节请参阅完整文档。在这里，我们展示了常见的工作流程。

动态修改卷属性

VolumeAttributesClass 是一个集群范围的资源，用来指定特定于制备器的属性。这些属性由集群管理员创建，方式上与存储类相同。例如，你可以为卷创建一系列金、银和铜级别的卷属性类，以区隔不同级别的 IO 能力。

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
  name: silver
driverName: your-csi-driver
parameters:
  provisioned-iops: "500"
  provisioned-throughput: "50MiB/s"
---
apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
  name: gold
driverName: your-csi-driver
parameters:
  provisioned-iops: "10000"
  provisioned-throughput: "500MiB/s"

属性类的添加方式与存储类类似。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pv-claim
spec:
  storageClassName: any-storage-class
  volumeAttributesClassName: silver
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 64Gi

与存储类不同，卷属性类可以被更改：

kubectl patch pvc test-pv-claim -p '{"spec": "volumeAttributesClassName": "gold"}'

Kubernetes 将与 CSI 驱动协作来更新卷的属性。 PVC 的状态将跟踪当前和所需的属性类。 PV 资源也将依据新的卷属性类完成更新，卷属性类也会被依据 PV 当前活跃的属性完成设置。

Beta 阶段的限制

作为一个 Beta 特性，仍有一些特性计划在 GA 阶段推出，但尚未实现。最大的限制是配额支持，详见 KEP 和 sig-storage 中的讨论。

有关此特性在 CSI 驱动中的最新支持信息，请参阅 Kubernetes CSI 驱动列表。

Kubernetes v1.31：通过基于缓存的一致性读加速集群性能

Thu, 15 Aug 2024 00:00:00 +0000

Kubernetes 以其强大的容器化应用编排能力而闻名，但随着集群规模扩大，对控制平面的需求可能成为性能瓶颈。其中一个主要挑战是确保从 etcd 数据存储进行强一致性读，这通常需要资源密集型仲裁读取操作。

今天，Kubernetes 社区很高兴地宣布一个重大改进：基于缓存的一致性读，已在 Kubernetes v1.31 中晋升至 Beta 阶段。

为什么一致性读如此重要

一致性读是确保 Kubernetes 组件准确了解最新集群状态的关键。保证一致性读对于保持 Kubernetes 操作准确性和可靠性至关重要，使组件能够根据最新信息做出明智决策。在大型集群中，数据的获取和处理往往会成为性能瓶颈，特别是那些需要过滤结果的请求。

虽然 Kubernetes 可以直接在 etcd 中按命名空间过滤数据，但如果按标签或字段选择器过滤，则需要从 etcd 获取整个数据集，然后由 Kubernetes API 服务器在内存中执行过滤操作。这对 Kubelet 等组件的影响尤为显著，因为 Kubelet 现在仅需列出调度到其节点的 Pod，而之前却需要 API 服务器和 etcd 处理集群中所有的 Pod。

突破：自信地缓存

Kubernetes 长期以来一直使用监视缓存来优化读取操作。监视缓存保存集群状态的快照，并通过对 etcd 的监视获取更新。然而，直到现在,它无法直接支持一致性读，因为没有机制保证缓存是最新的。

基于缓存的一致性读 特性通过使用 etcd 的进度通知机制来解决这一问题。这些通知会向监视缓存说明其数据与 etcd 相比的新旧状态。当发出一致性读请求时，系统会首先检查监视缓存是否为最新状态。

如果缓存未更新到最新状态，系统会通过查询 etcd 的进度通知，直到确认缓存已经足够新。一旦缓存就绪，读取操作就可以直接从缓存中高效地获取数据，这可以显著提升性能，尤其是在需要从 etcd 获取大量数据的场景下。这种方式支持通过缓存处理数据过滤请求，仅需从 etcd 读取少量的元数据。

重要提示： 要享受此特性带来的好处，你的 Kubernetes 集群需运行 etcd 版本 3.4.31+ 或 3.5.13+。对于较早版本的 Etcd，Kubernetes 将自动回退为直接从 etcd 提供一致性读。

你将注意到的性能提升

这个看似简单的改动，对 Kubernetes 的性能和可扩展性有着深远影响:

降低 etcd 负载： Kubernetes v1.31 可以将部分工作从 etcd 分载出去，为其他关键操作释放资源。
更低的延迟： 从缓存读取数据的速度显著快于从 etcd 获取并处理数据。这使组件的响应速度更快，提升了集群整体的响应能力。
增强的可扩展性： 拥有数千个节点和 Pod 的大型集群将获得最显著的性能增益，因为 etcd 负载的降低使得控制平面可以在不牺牲性能的情况下处理更多请求。

5 千节点扩缩容测试结果： 在最近针对 5,000 节点集群的扩缩容测试中，启用基于缓存的一致性读带来了显著提升：

kube-apiserver CPU 使用率降低 30%
etcd CPU 使用率降低 25%
第 99 百分位的 Pod 列表请求延迟出现了高至 3 倍的减少（从 5 秒降至 1.5 秒）

下一步是什么？

随着基于缓存的一致性读特性晋升至 Beta 版，该特性已默认启用，为所有使用受支持 etcd 版本的 Kubernetes 用户提供了无缝的性能提升。

我们的探索并未止步于此。Kubernetes 社区正积极研究在监视缓存中加入分页支持，未来有望带来更多性能优化。

开始使用

升级到 Kubernetes v1.31 并确保使用 etcd 版本 3.4.31+ 或 3.5.13+，是体验基于缓存的一致性读优势的最简单方法。如果有任何问题或反馈，不要犹豫，随时联系 Kubernetes 社区。

请让我们知道基于缓存的一致性读如何改善了你的 Kubernetes 体验！

特别感谢 @ah8ad3 和 @p0lyn0mial 对这一特性做出的贡献！

Kubernetes 1.31：对 cgroup v1 的支持转为维护模式

Wed, 14 Aug 2024 00:00:00 +0000

随着 Kubernetes 不断发展，为了适应容器编排全景图的变化，社区决定在 v1.31 中将对 cgroup v1 的支持转为维护模式。这一转变与行业更广泛地向 cgroup v2 的迁移保持一致，后者的功能更强，包括可扩展性和更加一致的接口。在我们深入探讨对 Kubernetes 的影响之前，先回顾一下 cgroup 的概念及其在 Linux 中的重要意义。

理解 cgroup

控制组（Control Group）也称为 cgroup，是 Linux 内核的一项特性，允许在进程之间分配、划分优先级、拒绝和管理系统资源（如 CPU、内存、磁盘 I/O 和网络带宽）。这一功能对于维护系统性能至关重要，确保没有单个进程能够垄断系统资源，这在多租户环境中尤其重要。

cgroup 有两个版本： v1 和 v2。虽然 cgroup v1 提供了足够的资源管理能力，但其局限性促使了 cgroup v2 的开发。 cgroup v2 在更好的资源控制特性之外提供了更统一且更一致的接口。

Kubernetes 中的 cgroup

对于 Linux 节点，Kubernetes 在管理和隔离 Pod 中运行的容器所消耗的资源方面高度依赖 cgroup。 Kubernetes 中的每个容器都放在其自己的 cgroup 中，这使得 Kubernetes 能够强制执行资源限制、监控使用情况并确保所有容器之间的资源公平分配。

Kubernetes 如何使用 cgroup

资源分配: 确保容器不超过其分配的 CPU 和内存限制。
隔离: 将容器相互隔离，防止资源争用。
监控: 跟踪每个容器的资源使用情况，以提供洞察数据和指标。

向 cgroup v2 过渡

Linux 社区一直在聚焦于为 cgroup v2 提供新特性和各项改进。主要的 Linux 发行版和像 systemd 这样的项目正在过渡到 cgroup v2。使用 cgroup v2 相较于使用 cgroup v1 提供了多个好处，例如统一的层次结构、改进的接口、更好的资源控制，以及 cgroup 感知的 OOM 杀手、非 root 支持等。

鉴于这些优势，Kubernetes 也正在更全面地转向 cgroup v2。然而，这一过渡需要谨慎处理，以避免干扰现有的工作负载，并为用户提供平滑的迁移路径。

对 cgroup v1 的支持转入维护模式

维护模式意味着什么？

当 cgroup v1 在 Kubernetes 中被置于维护模式时，这意味着：

特性冻结：不会再向 cgroup v1 添加新特性。
安全修复：仍将提供关键的安全修复。
尽力而为的 Bug 修复：在可行的情况下可能会修复重大 Bug，但某些问题可能保持未解决。

为什么要转入维护模式？

转入维护模式的原因是为了与更广泛的生态体系保持一致，也为了鼓励采用 cgroup v2，后者提供了更好的性能、安全性和可用性。通过将 cgroup v1 转入维护模式，Kubernetes 可以专注于增强对 cgroup v2 的支持，并确保其满足现代工作负载的需求。需要注意的是，维护模式并不意味着弃用；cgroup v1 将继续按需进行关键的安全修复和重大 Bug 修复。

这对集群管理员意味着什么

目前强烈鼓励那些依赖 cgroup v1 的用户做好向 cgroup v2 过渡的计划。这一过渡涉及：

升级系统：确保底层操作系统和容器运行时支持 cgroup v2。
测试工作负载：验证工作负载和应用程序在 cgroup v2 下正常工作。

进一步阅读

Kubernetes v1.31: PersistentVolume 的最后阶段转换时间进阶到 GA

Wed, 14 Aug 2024 00:00:00 +0000

现在宣布 PersistentVolume 的 lastTransitionTime 状态字段在 Kubernetes v1.31 版本进阶至正式发布（GA）！

Kubernetes SIG Storage 团队很高兴地宣布，"PersistentVolumeLastPhaseTransitionTime" 特性自 Kubernetes v1.28 作为 Alpha 版本引入以来，现已进阶至正式发布（GA），并正式成为 Kubernetes v1.31 版本的一部分。该功能帮助 Kubernetes 用户增强对 PersistentVolume 在不同阶段之间转换的理解，从而实现更高效和更明智的资源管理。

在 v1.31 集群中，你可以默认每个 PersistentVolume 对象都包含 .status.lastTransitionTime 字段，该字段记录存储卷最近一次发生阶段转换时的时间戳。该更改不会立刻生效，而是在升级到 Kubernetes v1.31 后，当 PersistentVolume 发生更新并首次在（Pending、Bound 或 Released）这几个阶段之间进行转换时，才会填充该字段。

有什么变化？

更新 PersistentVolume 对象的 API 策略已经被修改，当存储卷转换阶段时会自动填充当前时间戳到 .status.lastTransitionTime 字段。如果需要，用户可以手动设置该字段，但当 PersistentVolume 再次转换阶段时，该字段会被新时间戳覆盖。

想了解更多信息，可以查阅 Kubernetes 文档中的阶段转换时间戳。你还可以阅读此前的博客文章，该文章介绍了此特性在 v1.28 版本中作为 Alpha 版本发布的情况。

要提供反馈，请加入我们的 Kubernetes 存储特别兴趣小组 (SIG) 或参与公共 Slack 频道上的讨论。

Kubernetes Blog

Kubernetes v1.34 抢先一览

Kubernetes v1.34 的重点增强特性

DRA 核心功能趋向稳定

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

Deployment 的 Pod 替换策略

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

Service 的 PreferSameZone 和 PreferSameNode 流量分发

支持 KYAML：Kubernetes 的 YAML 方言

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

想了解更多？

参与其中

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

镜像兼容性规范的需求

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

多云与混合云的挑战

镜像兼容性倡议

在 Node Feature Discovery 中的实现

兼容性规范

节点验证的客户端实现

使用示例

总结

加入我们

Kubernetes Slack 变更公告

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

Kubernetes Event 的挑战

现实世界的价值

构建 Event 聚合系统

架构概述

Event 处理和分类

实现 Event 关联

Event 存储和保留

Event 管理的良好实践

高级特性

模式检测

实时警报

结论

下一步

介绍 Gateway API 推理扩展

Gateway API 推理扩展

工作原理

请求流程

基准测试

主要结果

路线图

总结

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

简要回顾

问题

就绪性检测

或许是一个启动探针？

关于 postStart 生命周期钩子？

存活探针

调研总结

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

升级至 Standard 渠道

基于百分比的流量复制

实验渠道的新特性

CORS 过滤

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

重试预算（Retry budgets）（XBackendTrafficPolicy）

试用

参与其中

相关 Kubernetes 博客文章

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

什么是原地 Pod 调整大小？

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

从 Alpha 到 Beta 有哪些变化？

显著的用户可感知的变化

稳定性和可靠性增强

接下来是什么？

开始使用并提供反馈

Kubernetes 1.33：Job 的 SuccessPolicy 进阶至 GA

关于 Job 的成功策略

工作原理

了解更多

加入我们

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

Sleep 动作的零值

容器停止信号

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