这篇文章发表已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已失效。

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 实现会议、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 驱动程序也参与其中。在多个组件之间协调时，有时可能会出现竞态条件。

另一个挑战是关于核心（Core）与自定义资源定义（CRD），这并非存储独有。CRD 是一种很好的方式来扩展 Kubernetes 的能力，同时避免在 Kubernetes 核心中添加过多代码。然而，这也意味着运行 Kubernetes 集群时需要许多外部组件。

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

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

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

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

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

FSM：那就是 CSI 进入的时候了？

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

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

FSM：将驱动程序从 Kubernetes 主代码树移出并引入 CSI 是一项重要的改进。

XY：CSI 接口相对于树内卷插件接口是一个改进，然而，仍然存在挑战。存储系统种类繁多。目前在 CSI 驱动程序文档中列出了 100 多个 CSI 驱动程序。这些存储系统的多样性也非常高。因此，设计一个适用于所有系统的通用 API 非常困难。我们在 CSI 驱动程序级别引入了能力（Capabilities），但在同一个驱动程序提供的卷具有不同行为时，我们仍然面临挑战。前几天我们刚开会讨论了按卷区分的 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 阶段，但默认启用功能门（feature gate）。Ceph RBD 和 PortWorx 的目标是 Beta，默认关闭功能门。Ceph FS 的目标是 Alpha。
  • 我想重点介绍的第二点是 COSI，即容器对象存储接口。这是 SIG Storage 下的一个子项目。COSI 提出了对象存储 Kubernetes API，以支持 Kubernetes 工作负载的对象存储操作编排。它还引入了 gRPC 接口，供对象存储提供商编写驱动程序来配置存储桶（buckets）。COSI 团队已经在这个项目上工作了两年多。COSI 功能的目标是在 1.25 版本达到 Alpha 阶段。相关的 KEP 刚刚合并。COSI 团队正在根据更新后的 KEP 更新实现。
  • 我想提及的另一个功能是CSI 临时卷支持。此功能允许 CSI 卷直接在 Pod 规范中指定，用于临时使用场景。它们可用于通过挂载的卷直接将任意状态（例如配置、Secrets、身份、变量或类似信息）注入到 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 始终欢迎新的贡献者。我们需要贡献者帮助构建新功能、修复 bug、进行代码评审、编写测试、监控测试网格健康状况以及改进文档等。

FSM：非常感谢您抽出时间并分享您对 SIG Storage 运作情况的见解！