在持续推出的 SIG 聚焦系列中，我们会介绍推动 Kubernetes 项目不断向前发展的各个团队。 这一次，我们采访了 SIG Storage， 该团队负责持久化数据、卷管理， 以及将 Kubernetes 工作负载与其底层存储系统连接起来的接口。
我们采访了 SIG Storage 联合主席、VMware by Broadcom 软件工程师 Xing Yang，聊了聊这个 SIG 的历史、近期 Kubernetes 版本中发布的功能，以及随着 AI 工作负载成为常态，Kubernetes 中的存储将走向何方。
你能介绍一下自己，并分享你在 SIG Storage 中承担的角色吗？
我叫 Xing Yang，是 VMware by Broadcom 的软件工程师。 我是 SIG Storage 的联合主席，另一位联合主席是来自 Google 的 Saad Ali。SIG Storage 还有两位技术负责人： 来自 Google 的 Michelle Au 和来自 Red Hat 的 Jan Šafránek。
最初是什么吸引你关注 Kubernetes 中的存储？你又是如何开始贡献的？
我一直在存储领域工作，所以当我开始学习 Kubernetes 时，SIG Storage 自然而然成了我的起点。 我开始参加 SIG Storage 会议， 试着了解自己能帮上什么忙。那是在第一个 容器存储接口（CSI） 版本发布之前，很多事情还在演进之中。那是一段非常令人兴奋的时期。
现在你积极维护或评审哪些子项目或领域？
我是 Kubernetes CSI 的维护者。我们需要在每个 Kubernetes 版本发布后发布多个 CSI
边车容器，例如 csi-provisioner、csi-attacher、csi-resizer 和
csi-snapshotter。我也是由 SIG Storage 和
SIG Apps
共同发起的数据保护工作组的联合主席。
这个工作组已经产出了若干功能，旨在填补 Kubernetes 中数据保护支持方面的空白。
其中之一是卷组快照（Volume Group Snapshot），
它为应用所使用的多个卷提供崩溃一致性的组快照。
变更块跟踪（Changed Block Tracking，CBT）
是数据保护工作组的另一项关键功能，用于支持高效备份。
对于刚接触的人来说，你会如何用自己的话描述 SIG Storage？你们试图解决 Kubernetes 中的哪些问题？
SIG Storage 是一个特别兴趣小组， 专注于如何为 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 还通过容器对象存储接口 （Container Object Storage Interface，COSI）扩展了其范围，以支持对象存储。
SIG Storage 目前正在积极推进的最重要功能有哪些？
数据保护工作组一直在推进几项令人兴奋的功能：
另一个值得强调的功能是 Container Object Storage Interface（COSI）。COSI
为在 Kubernetes 中制备和使用对象存储桶提供了标准接口，就像 CSI 为块存储和文件存储所做的那样，
为容器化应用标准化对象存储。COSI 现在正在过渡到 v1alpha2，并计划在未来版本中提升到 Beta。
你认为 SIG Storage 近期哪些工作算得上用户的“胜利”？
VolumeAttributesClass 在 Kubernetes v1.34 中进入 GA，是管理有状态工作负载的用户的一项重大胜利。过去，修改 IOPS 或吞吐量等卷属性需要带外操作或破坏性操作。现在，用户可以直接通过 Kubernetes API 动态调整 IOPS 或吞吐量等存储属性，在负载高峰时向上扩展，或向下调整以优化成本， 而不需要外部流程或停机。
VolumeAttributesClass 支持在不重新创建卷的情况下动态修改存储特性。它补全了这幅图景： 用户既可以动态调整容量，也可以动态调整其他存储属性，就像现在可以同时调整计算资源中的 CPU 和内存一样。
展望接下来一两个版本，路线图上有哪些值得大家关注的内容？
我想请大家关注 Volume Health 功能。 该功能旨在为持久卷的运行状态和完整性提供关键可见性。通过让存储驱动和 Kubernetes 控制平面报告问题，它可以主动监控并识别与卷相关的问题。
目前，卷健康信息是通过非持久化事件来报告的。我们正在积极研究对此功能的增强， 目标是在未来支持自动化修复能力。
有哪些领域是你们非常希望社区进一步讨论或提供帮助的？
我们始终需要社区帮助修复 Bug、添加测试，并参与评审。
我们也希望获得关于 Alpha 功能 Mutable PV Affinity 的反馈。 该功能是在 Kubernetes v1.35 中引入的。其使用场景包括将卷从可用区级存储迁移到区域级存储， 或从一种磁盘类型迁移到另一种磁盘类型。
另一个主题是卷复制。这个主题是在 KubeCon Atlanta 上提出的，并已在数据保护工作组中讨论。鼓励对此主题感兴趣的社区成员参加数据保护工作组会议。
如今用户在 Kubernetes 上运行有状态工作负载时面临的最大挑战是什么？
虽然 Kubernetes 已经让数据库和 AI 流水线等有状态工作负载进入主流， 但在一个为临时性而设计的系统中管理“状态”仍然很困难：
你认为未来几年 Kubernetes 中的存储会如何演进，尤其是在 AI/ML 工作负载增长的背景下？
随着 Kubernetes 从容器编排器演进为 AI 的“操作系统”，我看到有几种趋势正在塑造 Kubernetes 中的存储：
SIG Storage 持续应对 Kubernetes 中一些最困难的问题：让有状态应用可靠运行， 让存储操作透明且可组合，并且如今还要扩展能力以满足 AI 时代工作负载的需求。 无论你是在生产环境中管理数据库的用户，还是对存储内部机制感兴趣的开发者， SIG Storage 中都有适合你的位置。
如果你想参与进来，请查看 SIG Storage 社区页面， 并参加双周会议。 你也可以在 Slack 上的 #sig-storage 找到这个 SIG。