本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

聚焦 SIG Storage

作者：Frederico Muñoz (SAS) |

自从 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 阶段。它需要贡献者。所以我自愿提供帮助。然后我与其他社区成员合作，在 2018 年的 K8s 1.12 版本中将 VolumeSnapshot 带入 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 实现会议、对象存储桶 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 驱动程序也参与其中。在协调多个组件之间时，有时可能会出现竞争条件。

另一个挑战是关于核心 vs 自定义资源定义 (CRD)，实际上不是存储特有的。CRD 是扩展 Kubernetes 功能的好方法，同时不会向 Kubernetes 核心本身添加太多代码。但是，这也意味着在运行 Kubernetes 集群时需要许多外部组件。

从 SIG Storage 方面来看，一个最值得注意的例子是 Volume Snapshot。Volume Snapshot API 被定义为 CRD。API 定义和控制器是树外的。应该在控制平面上部署一个通用的快照控制器和一个快照验证 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 核心代码库中拥有卷插件。这造成了很多问题。如果卷插件中存在 bug，它会影响整个 Kubernetes 代码库。所有卷插件都必须与 Kubernetes 一起发布。如果存储供应商需要修复其插件中的 bug 或想要与自己的产品发布保持一致，则没有任何灵活性。

FSM：这就是 CSI 发挥作用的地方吗？

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

与树内卷插件相比，CSI 绝对是一个很大的进步。自 1.13 版本发布以来，Kubernetes 对 CSI 的实现已进入 GA 阶段。它已经取得了长足的进步。SIG Storage 一直致力于在多个版本中将树内卷插件移到树外的 CSI 驱动程序。

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

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

持续的挑战

FSM：特别是对于 1.25 版本，我们可以看到管道中有很多与存储相关的 KEP，您会说这个版本对SIG特别重要吗？

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

FSM：确实如此，但是有没有您想指出的 1.25 版本特有的特性和亮点呢？

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

  • CSI 迁移 是 SIG Storage 已经持续多个版本的工作。目标是将内部卷插件迁移到外部 CSI 驱动程序，并最终移除内部卷插件。在 1.25 版本中，我们有 7 个与 CSI 迁移相关的 KEP。有一个核心 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 的运作方式以及我们在每个版本中的工作内容。找到一个您感兴趣的项目并提供帮助。正如我之前提到的，我通过为卷快照项目做出贡献而开始参与 SIG Storage。

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

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

FSM：非常感谢您抽出时间并分享您对 SIG Storage 工作原理的见解！