[转载] 聚焦 SIG Storage

本文为授权转载，非本账号原创。

原文：聚焦 SIG Storage（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/15/sig-storage-spotlight-2026/）

原作者及译者：借由 Darshan Murthy (Apple) | 译者 Fan Baofa (DaoCloud) | 2026.06.15

来源：Kubernetes 官方中文博客；许可：CC BY 4.0（参考地址：https://creativecommons.org/licenses/by/4.0/）。保留原作者和译者署名，正文仅做适配博客编辑器的排版与链接格式转换，未改写技术内容。

内容不代表原作者或 Kubernetes 项目对本账号的认可或背书。

在持续推出的 SIG 聚焦系列中，我们会介绍推动 Kubernetes 项目不断向前发展的各个团队。 这一次，我们采访了 SIG Storage（参考地址：https://github.com/kubernetes/community/tree/master/sig-storage）， 该团队负责持久化数据、卷管理， 以及将 Kubernetes 工作负载与其底层存储系统连接起来的接口。

我们采访了 SIG Storage 联合主席、VMware by Broadcom 软件工程师 Xing Yang（参考地址：https://github.com/xing-yang），聊了聊这个 SIG 的历史、近期 Kubernetes 版本中发布的功能，以及随着 AI 工作负载成为常态，Kubernetes 中的存储将走向何方。

介绍（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/15/sig-storage-spotlight-2026/#%e4%bb%8b%e7%bb%8d）

你能介绍一下自己，并分享你在 SIG Storage 中承担的角色吗？

我叫 Xing Yang（参考地址：https://github.com/xing-yang），是 VMware by Broadcom 的软件工程师。 我是 SIG Storage 的联合主席，另一位联合主席是来自 Google 的 Saad Ali（参考地址：https://github.com/saad-ali）。SIG Storage 还有两位技术负责人： 来自 Google 的 Michelle Au（参考地址：https://github.com/msau42） 和来自 Red Hat 的 Jan Šafránek（参考地址：https://github.com/jsafrane）。

最初是什么吸引你关注 Kubernetes 中的存储？你又是如何开始贡献的？

我一直在存储领域工作，所以当我开始学习 Kubernetes 时，SIG Storage 自然而然成了我的起点。 我开始参加 SIG Storage 会议（参考地址：https://github.com/kubernetes/community/blob/main/sig-storage/README.md#meetings）， 试着了解自己能帮上什么忙。那是在第一个 容器存储接口（参考地址：https://github.com/container-storage-interface/spec/blob/master/spec.md）（CSI） 版本发布之前，很多事情还在演进之中。那是一段非常令人兴奋的时期。

现在你积极维护或评审哪些子项目或领域？

我是 Kubernetes CSI 的维护者。我们需要在每个 Kubernetes 版本发布后发布多个 CSI 边车容器，例如 csi-provisioner、csi-attacher、csi-resizer 和 csi-snapshotter。我也是由 SIG Storage 和 SIG Apps（参考地址：https://github.com/kubernetes/community/tree/main/sig-apps） 共同发起的数据保护工作组（参考地址：https://github.com/kubernetes/community/blob/main/wg-data-protection/README.md）的联合主席。 这个工作组已经产出了若干功能，旨在填补 Kubernetes 中数据保护支持方面的空白。 其中之一是卷组快照（参考地址：https://kubernetes.io/zh-cn/blog/2026/05/08/kubernetes-v1-36-volume-group-snapshot-ga/）（Volume Group Snapshot）， 它为应用所使用的多个卷提供崩溃一致性的组快照。 变更块跟踪（参考地址：https://github.com/kubernetes/enhancements/issues/3314）（Changed Block Tracking，CBT） 是数据保护工作组的另一项关键功能，用于支持高效备份。

关于 SIG Storage（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/15/sig-storage-spotlight-2026/#%e5%85%b3%e4%ba%8e-sig-storage）

对于刚接触的人来说，你会如何用自己的话描述 SIG Storage？你们试图解决 Kubernetes 中的哪些问题？

SIG Storage 是一个特别兴趣小组（参考地址：https://github.com/kubernetes/community/blob/main/governance.md）， 专注于如何为 Kubernetes 集群中运行的容器提供存储。我们定义标准接口，使存储供应商能够编写驱动程序， 并让 Kubernetes 中的容器使用其底层存储系统。

为什么 Kubernetes 需要一个专门的存储 SIG？在分布式系统中，存储为何如此困难？

Kubernetes 最初被引入时，只面向无状态工作负载。容器应用被视为临时性的，因此不需要持久化数据。 然而，这种情况发生了巨大变化。有状态工作负载开始在 Kubernetes 中运行，我们需要一个专门的 SIG 来应对相关的存储挑战。PersistentVolumeClaim、PersistentVolume 和 StorageClass 都是为了给 Kubernetes 中运行的应用制备数据卷而引入的。

SIG Storage 最初是如何形成的？它的使命随着时间发生了哪些变化？

SIG Storage 的成立是为了解决 Kubernetes 中处理持久化数据的挑战。最初，PersistentVolume 是以内置（in-tree）插件的形式实现的，SIG 在开发 PersistentVolume 和 PersistentVolumeClaim 等核心存储原语的同时，也负责管理这些插件。

容器存储接口（Container Storage Interface，CSI）后来被引入，并在简化存储集成方面发挥了关键作用， 使第三方存储提供商能够开发和维护自己的树外（out-of-tree）插件，而无需修改 Kubernetes 核心代码。

随着 CSI 解决了基础集成问题，SIG 的使命扩展到涵盖利用这一新接口的高级存储功能。 SIG 还通过容器对象存储接口（参考地址：https://github.com/kubernetes-sigs/container-object-storage-interface） （Container Object Storage Interface，COSI）扩展了其范围，以支持对象存储。

当前工作和路线图（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/15/sig-storage-spotlight-2026/#%e5%bd%93%e5%89%8d%e5%b7%a5%e4%bd%9c%e5%92%8c%e8%b7%af%e7%ba%bf%e5%9b%be）

SIG Storage 目前正在积极推进的最重要功能有哪些？

数据保护工作组一直在推进几项令人兴奋的功能：

• VolumeGroupSnapshot 是一项 Kubernetes 功能，可同时为多个 PersistentVolume 创建崩溃一致性的时间点快照。 对于数据库这类依赖多个卷的应用，它会在完全相同的时间点原子地捕获组内所有卷，从而确保数据完整性。 该功能刚刚在 Kubernetes v1.36 中进入正式发布（GA）阶段。

• CSI Changed Block Tracking（CBT） 支持高效的增量备份。它允许存储系统只报告自上次快照以来发生变化的块， 从而显著减少需要传输的数据量。该功能刚刚在 Kubernetes v1.36 中进入 Beta 阶段。

另一个值得强调的功能是 Container Object Storage Interface（COSI）。COSI 为在 Kubernetes 中制备和使用对象存储桶提供了标准接口，就像 CSI 为块存储和文件存储所做的那样， 为容器化应用标准化对象存储。COSI 现在正在过渡到 v1alpha2，并计划在未来版本中提升到 Beta。

你认为 SIG Storage 近期哪些工作算得上用户的“胜利”？

VolumeAttributesClass（参考地址：https://kubernetes.io/zh-cn/docs/concepts/storage/volume-attributes-classes/） 在 Kubernetes v1.34 中进入 GA，是管理有状态工作负载的用户的一项重大胜利。过去，修改 IOPS 或吞吐量等卷属性需要带外操作或破坏性操作。现在，用户可以直接通过 Kubernetes API 动态调整 IOPS 或吞吐量等存储属性，在负载高峰时向上扩展，或向下调整以优化成本， 而不需要外部流程或停机。

VolumeAttributesClass 支持在不重新创建卷的情况下动态修改存储特性。它补全了这幅图景： 用户既可以动态调整容量，也可以动态调整其他存储属性，就像现在可以同时调整计算资源中的 CPU 和内存一样。

展望接下来一两个版本，路线图上有哪些值得大家关注的内容？

我想请大家关注 Volume Health（参考地址：https://github.com/kubernetes/enhancements/issues/1432） 功能。 该功能旨在为持久卷的运行状态和完整性提供关键可见性。通过让存储驱动和 Kubernetes 控制平面报告问题，它可以主动监控并识别与卷相关的问题。

目前，卷健康信息是通过非持久化事件来报告的。我们正在积极研究对此功能的增强， 目标是在未来支持自动化修复能力。

有哪些领域是你们非常希望社区进一步讨论或提供帮助的？

我们始终需要社区帮助修复 Bug、添加测试，并参与评审。

我们也希望获得关于 Alpha 功能 Mutable PV Affinity（参考地址：https://github.com/kubernetes/enhancements/issues/4762） 的反馈。 该功能是在 Kubernetes v1.35 中引入的。其使用场景包括将卷从可用区级存储迁移到区域级存储， 或从一种磁盘类型迁移到另一种磁盘类型。

另一个主题是卷复制。这个主题是在 KubeCon Atlanta（参考地址：https://www.cncf.io/reports/kubecon-cloudnativecon-north-america-2025/） 上提出的，并已在数据保护工作组中讨论。鼓励对此主题感兴趣的社区成员参加数据保护工作组会议。

如今用户在 Kubernetes 上运行有状态工作负载时面临的最大挑战是什么？

虽然 Kubernetes 已经让数据库和 AI 流水线等有状态工作负载进入主流， 但在一个为临时性而设计的系统中管理“状态”仍然很困难：

• 数据引力和存储局部性：Pod 可以在数秒内迁移，但数据具有引力。如果某个节点发生故障， 使用本地存储的 Pod 就会受困。操作者必须判断故障是临时性的还是永久性的，这是一个风险很高的决策。 这就是我们增强 Volume Health 功能的原因：提供自动化恢复决策所需的可见性。

• 第 2 天复杂性：搭建数据库很容易；随着时间推移持续维护其健康状态才是真正的挑战。 StatefulSet 这类标准 Kubernetes 对象提供了基础能力，但缺少执行模式升级、引擎补丁更新或集群范围 Kubernetes 升级等任务所需的运维逻辑。

• 数据移动性：迁移持久化数据仍然是一大障碍，无论是在存储层级之间迁移、跨可用区迁移工作负载， 还是迁移到另一个集群。这个挑战还包括在分布式系统中为实现高可用和灾难恢复而持续进行同步和复制。

存储和 AI（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/15/sig-storage-spotlight-2026/#%e5%ad%98%e5%82%a8%e5%92%8c-ai）

你认为未来几年 Kubernetes 中的存储会如何演进，尤其是在 AI/ML 工作负载增长的背景下？

随着 Kubernetes 从容器编排器演进为 AI 的“操作系统”，我看到有几种趋势正在塑造 Kubernetes 中的存储：

• 更智能的数据管理：我们会看到更智能的 CSI 驱动和数据管理工具逐渐出现， 提供自动分层、快照、迁移和复制等高级功能，并专门针对高性能 AI/ML 工作流和大型数据平台进行优化。

• 对象存储成为一等公民：如今 AI 数据集经常达到 EB 级规模，使对象存储成为 AI 工作负载的首选。 COSI 正在标准化存储桶管理，就像 CSI 标准化磁盘一样，让数据科学家能够使用 BucketClaim 原生制备兼容 S3 的存储，并将对象存储、文件存储和块存储统一到一个工作流中。

• 性能和低延迟：对于 AI/ML 来说，存储需要跟上 GPU 的处理速度。这会加速采用高性能并行文件系统， 以及通过 Kubernetes 原生管理的 NVMe over Fabrics（NVMe-oF）技术。传统块/文件存储与内存速度存储之间的界限将继续模糊。

• 数据感知调度：Kubernetes 调度器将不再只考虑 CPU 和 RAM，而是会越来越优先根据数据局部性放置 Pod， 计算移动数据与移动计算之间的成本，以保持海量数据平台的性能。

SIG Storage 持续应对 Kubernetes 中一些最困难的问题：让有状态应用可靠运行， 让存储操作透明且可组合，并且如今还要扩展能力以满足 AI 时代工作负载的需求。 无论你是在生产环境中管理数据库的用户，还是对存储内部机制感兴趣的开发者， SIG Storage 中都有适合你的位置。

如果你想参与进来，请查看 SIG Storage 社区页面（参考地址：https://www.kubernetes.dev/community/community-groups/sigs/storage/）， 并参加双周会议（参考地址：https://github.com/kubernetes/community/tree/master/sig-storage#meetings）。 你也可以在 Slack 上的 #sig-storage（参考地址：https://kubernetes.slack.com/messages/sig-storage） 找到这个 SIG。

• SIG Storage 邮件列表（参考地址：https://groups.google.com/a/kubernetes.io/g/sig-storage）
• Slack 上的 SIG Storage（参考地址：https://kubernetes.slack.com/messages/sig-storage）
• 数据保护工作组（参考地址：https://github.com/kubernetes/community/blob/master/wg-data-protection/README.md）

• ←上一页（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/01/dashboard-to-headlamp/）
• 下一页→（参考地址：https://kubernetes.io/zh-cn/blog/2026/06/24/wg-device-management-spotlight-2026/）