本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

聚焦 SIG Storage

作者：Frederico Muñoz (SAS) | 2022年8月22日，星期一

自 Kubernetes 诞生之初，持久数据以及如何满足有状态应用程序的需求一直是一个重要议题。对无状态部署的支持是自然而然的，从一开始就存在，并得到了广泛关注，变得非常知名。对有状态应用程序更好支持的工作也从早期就开始了，每个版本都增加了 Kubernetes 上可运行的范围。

消息队列、数据库、集群文件系统：这些是具有不同存储要求的一些解决方案示例，如今它们越来越多地部署在 Kubernetes 中。处理临时和持久存储，无论是本地还是远程，文件或块，来自许多不同供应商，同时考虑如何提供用户期望的所需弹性和数据一致性，所有这些都属于 SIG Storage 的职责范围。

在本次 SIG Storage 聚焦活动中，Frederico Muñoz (SAS 的云与架构主管) 与 VMware 技术主管兼 SIG Storage 联合主席 Xing Yang 进行了交谈，讨论了 SIG 的组织方式、当前的挑战以及如何参与和贡献。

关于 SIG Storage

Frederico (FSM)：你好，感谢有机会了解更多关于 SIG Storage 的信息。您能简单介绍一下您自己、您的角色以及您是如何参与 SIG Storage 的吗？

Xing Yang (XY)：我是 VMware 的技术主管，负责云原生存储。我也是 SIG Storage 的联合主席。我于 2017 年底开始参与 K8s SIG Storage，最初是为 VolumeSnapshot 项目贡献代码。当时，VolumeSnapshot 项目仍处于实验性的 pre-alpha 阶段。它需要贡献者。所以我自愿提供了帮助。然后我与社区其他成员合作，使 VolumeSnapshot 在 2018 年的 K8s 1.12 版本中达到 Alpha 阶段，在 2019 年的 K8s 1.17 版本中达到 Beta 阶段，并最终在 2020 年的 1.20 版本中达到 GA 阶段。

FSM：仅阅读 SIG Storage 章程，就很清楚 SIG Storage 涵盖了广泛的领域，您能描述一下 SIG 是如何组织的吗？

XY：在 SIG Storage 中，有两位联合主席和两位技术负责人。来自 Google 的 Saad Ali 和我担任联合主席。来自 Google 的 Michelle Au 和来自 Red Hat 的 Jan Šafránek 担任技术负责人。

我们每两周召开一次会议，讨论每个特定版本正在开发的功能，获取状态，确保每个功能都有开发负责人和评审人员参与其中，并提醒人们发布截止日期等。有关 SIG 的更多信息可在社区页面上找到。人们还可以将需要关注的 PR、需要讨论的设计提案以及其他议题添加到会议议程文档中。我们会在项目跟踪完成后审查这些内容。

我们还有其他定期会议，例如 CSI 实现会议、Object Bucket API 设计会议，以及根据需要针对特定主题举行的一次性会议。还有一个由 SIG Storage 和 SIG Apps 赞助的 K8s 数据保护工作组。SIG Storage 拥有或共同拥有在数据保护工作组中讨论的功能。

存储与 Kubernetes

FSM：存储在许多方面都是基础组件，尤其是在 Kubernetes 中：您认为 Kubernetes 在存储管理方面有哪些特有的挑战？

XY：在 Kubernetes 中，卷操作涉及多个组件。例如，创建一个 Pod 来使用 PVC 涉及多个组件。Attach Detach Controller 和 external-attacher 负责将 PVC 连接到 Pod。Kubelet 负责将 PVC 挂载到 Pod。当然，CSI 驱动程序也参与其中。多个组件之间协调时有时可能会出现竞态条件。

另一个挑战是关于核心与自定义资源定义 (CRD)，这并非存储特有的问题。CRD 是扩展 Kubernetes 功能的好方法，同时不会给 Kubernetes 核心本身增加太多代码。然而，这也意味着运行 Kubernetes 集群时需要许多外部组件。

从 SIG Storage 的角度来看，最显著的例子是 Volume Snapshot。Volume Snapshot API 被定义为 CRD。API 定义和控制器是树外（out-of-tree）的。有一个通用的快照控制器和一个快照验证 webhook，它们应该部署在控制平面上，类似于 kube-controller-manager 的部署方式。尽管 Volume Snapshot 是一个 CRD，但它是 SIG Storage 的一个核心功能。建议 K8s 集群发行版部署 Volume Snapshot CRD、快照控制器和快照验证 webhook，但是，大多数情况下我们没有看到发行版部署它们。因此，这成为存储供应商的一个问题：现在部署这些与驱动程序无关的通用组件成为他们的责任。如果客户想要使用多个存储系统并部署多个 CSI 驱动程序，这可能会导致冲突。

FSM：不仅是单个存储系统的复杂性，您还需要考虑它们如何在 Kubernetes 中协同使用？

XY：是的，有许多不同的存储系统可以为 Kubernetes 中的容器提供存储。它们的工作方式不尽相同。找到一个适用于所有人的解决方案是很有挑战性的。

FSM：Kubernetes 中的存储还涉及与外部解决方案的交互，可能比 Kubernetes 的其他部分更多。这种与供应商和外部提供商的交互是否具有挑战性？它随着时间有什么变化吗？

XY：是的，这绝对具有挑战性。最初，Kubernetes 存储具有树内卷插件接口。许多存储供应商实现了树内接口，并在 Kubernetes 核心代码库中拥有卷插件。这导致了许多问题。如果卷插件中存在错误，它会影响整个 Kubernetes 代码库。所有卷插件都必须与 Kubernetes 一起发布。如果存储供应商需要修复其插件中的错误或希望与自己的产品发布保持一致，则没有灵活性。

FSM：这就是 CSI 登场的时候？

XY：没错，然后就是容器存储接口 (CSI)。这是一个行业标准，旨在设计通用的存储接口，以便存储供应商可以编写一个插件，并在各种容器编排系统 (CO) 中工作。现在 Kubernetes 是主要的 CO，但当初 CSI 刚开始时，除了 Kubernetes 之外，还有 Docker、Mesos、Cloud Foundry。CSI 驱动程序是树外（out-of-tree）的，因此错误修复和发布可以按照它们自己的节奏进行。

CSI 绝对是与树内卷插件相比的一个重大改进。Kubernetes 的 CSI 实现自 1.13 版本以来已达到 GA 阶段。它已经走过了漫长的道路。SIG Storage 几个版本以来一直在努力将树内卷插件迁移到树外 CSI 驱动程序。

FSM：将驱动程序从 Kubernetes 主树移到 CSI 是一个重要的改进。

XY：CSI 接口是对树内卷插件接口的改进，但仍然存在挑战。存储系统种类繁多。目前 CSI 驱动程序文档中列出了 100 多个 CSI 驱动程序。这些存储系统也各不相同。因此，设计一个适用于所有人的通用 API 是很困难的。我们在 CSI 驱动程序层面引入了功能，但当同一驱动程序提供的卷具有不同行为时，我们也面临挑战。前几天我们刚刚开会讨论了每个卷的 CSI 驱动程序功能。当同一驱动程序同时支持块卷和文件卷时，我们在区分某些 CSI 驱动程序功能时遇到了问题。我们将举行后续会议讨论这个问题。

持续的挑战

FSM：特别是对于 1.25 版本，我们可以看到有大量与存储相关的 KEPs 正在推进中，您会说这个版本对 SIG 来说特别重要吗？

XY：我不会说某个版本比其他版本更重要。在任何给定版本中，我们都在处理一些非常重要的事情。

FSM：确实如此，但是您想指出 1.25 版本中有什么特别之处和亮点吗？

XY：是的。对于 1.25 版本，我想强调以下几点：

CSI 迁移是 SIG Storage 几个版本以来一直在进行的一项持续工作。目标是将树内卷插件迁移到树外 CSI 驱动程序，并最终移除树内卷插件。在 1.25 中，我们有 7 个与 CSI 迁移相关的 KEPs。其中有一个核心 KEP 针对通用的 CSI 迁移功能。它计划在 1.25 中达到 GA 阶段。GCE PD 和 AWS EBS 的 CSI 迁移也计划达到 GA 阶段。vSphere 的 CSI 迁移计划在 1.25 中默认开启功能门，并保持在 Beta 阶段。Ceph RBD 和 PortWorx 计划达到 Beta 阶段，默认关闭功能门。Ceph FS 计划达到 Alpha 阶段。
我想要强调的第二件事是 COSI，容器对象存储接口。这是 SIG Storage 下的一个子项目。COSI 提出对象存储 Kubernetes API，以支持 Kubernetes 工作负载的对象存储操作编排。它还引入了 gRPC 接口，供对象存储提供商编写驱动程序以提供存储桶。COSI 团队已经在这个项目上工作了两年多。COSI 功能计划在 1.25 中达到 Alpha 阶段。KEP 刚刚合并。COSI 团队正在根据更新的 KEP 更新实现。
我想提的另一个功能是 CSI 临时卷支持。此功能允许在 Pod 规范中直接指定 CSI 卷用于临时用例。它们可以通过挂载卷直接向 Pod 注入任意状态，例如配置、密钥、身份、变量或类似信息。这最初在 1.15 中作为 Alpha 功能引入，现在目标是在 1.25 中达到 GA 阶段。

FSM：如果要突出一个最重要的领域，SIG 目前正在努力解决哪些问题？

XY：CSI 迁移无疑是 SIG 投入了大量精力并且已经持续了多个版本的一个领域。它也涉及多个云提供商和存储供应商的工作。

社区参与

FSM：Kubernetes 是一个社区驱动的项目。对于任何希望参与 SIG Storage 工作的人，您有什么建议吗？他们应该从何开始？

XY：请查看 SIG Storage 社区页面，其中包含大量入门信息。还有 SIG 年度报告，可以告诉您我们每年做了什么。查看贡献指南。它包含指向演示文稿的链接，可以帮助您熟悉 Kubernetes 存储概念。

加入我们每周四举行的双周会议。了解 SIG 如何运作以及我们每个版本正在进行的工作。找到您感兴趣的项目并提供帮助。正如我之前提到的，我通过贡献 Volume Snapshot 项目开始参与 SIG Storage。

FSM：您还有什么想补充的结束语吗？

XY：SIG Storage 始终欢迎新的贡献者。我们需要贡献者帮助构建新功能、修复错误、进行代码审查、编写测试、监控测试网格健康状况以及改进文档等。

FSM：非常感谢您分享宝贵的时间和对 SIG Storage 运作的见解！