本文发表已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.23：Kubernetes In-Tree 到 CSI 卷迁移状态更新
Kubernetes 内置存储插件到 容器存储接口 (CSI) 的迁移基础设施自 v1.17 以来已经处于 beta 阶段。CSI 迁移在 Kubernetes v1.14 中作为 alpha 版本引入。
从那时起，SIG Storage 和其他 Kubernetes 特殊兴趣小组正在努力确保功能的稳定性和兼容性，为 GA 做准备。本文旨在提供该功能的最新状态，以及 Kubernetes 1.17 和 1.23 之间的变化。此外，我还将介绍每个存储插件的 CSI 迁移功能 GA 的未来路线图。
快速回顾：什么是 CSI 迁移，为什么要迁移？
容器存储接口 (CSI) 的设计旨在帮助 Kubernetes 替换其现有的内置存储驱动机制，特别是供应商特定的插件。Kubernetes 对 容器存储接口 的支持自 Kubernetes v1.13 以来已 普遍可用。引入对使用 CSI 驱动程序的支持，以便更容易地添加和维护 Kubernetes 和存储后端技术之间的新集成。使用 CSI 驱动程序可以更好地维护（驱动程序作者可以定义自己的发布周期和支持生命周期）并减少漏洞的发生机会（由于内置代码较少，出错的风险降低，并且集群运营商可以选择仅其集群所需的存储驱动程序）。
随着越来越多的 CSI 驱动程序被创建并投入生产，SIG Storage 小组希望所有 Kubernetes 用户都能从 CSI 模型中受益。但是，我们不能破坏与现有存储 API 类型的 API 兼容性。我们提出的解决方案是 CSI 迁移：一种将内置 API 转换为等效 CSI API 并将操作委托给替换 CSI 驱动程序的功能。
CSI 迁移工作可以替换现有的内置存储插件，例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs，并使用存储后端相应的 CSI 驱动程序。如果 CSI 迁移工作正常，Kubernetes 最终用户不应注意到任何差异。现有的 StorageClass、PersistentVolume 和 PersistentVolumeClaim 对象应该继续工作。当 Kubernetes 集群管理员更新集群以启用 CSI 迁移时，利用由内置存储插件支持的 PVC 的现有工作负载将继续像往常一样运行。但是，在后台，Kubernetes 将所有存储管理操作的控制权（以前针对内置驱动程序）移交给 CSI 驱动程序。
例如，假设您是 kubernetes.io/gce-pd 用户，在 CSI 迁移后，您仍然可以使用 kubernetes.io/gce-pd 来配置新卷、挂载现有 GCE-PD 卷或删除现有卷。所有现有的 API/接口都将继续正常运行。但是，底层函数调用都通过 GCE PD CSI 驱动程序 而不是内置的 Kubernetes 函数。
这为最终用户实现了平稳过渡。此外，作为存储插件开发人员，我们可以减少维护内置存储插件的负担，并最终将其从核心 Kubernetes 二进制文件中删除。
发生了什么变化，以及有哪些新功能？
在 Kubernetes v1.17 及更早版本中所做工作的基础上，此后的版本进行了一系列更改
新的功能门控
Kubernetes v1.21 版本弃用了 CSIMigration{provider}Complete 功能标志，并且不再使用它们。取而代之的是名为 InTreePlugin{vendor}Unregister 的新功能标志，它们取代了旧的功能标志，并保留了 CSIMigration{provider}Complete 提供的所有功能。
CSIMigration{provider}Complete 之前被引入作为辅助功能门控，一旦 CSI 迁移在所有节点上启用。此标志取消注册您使用标志名称的 {provider} 部分指定的内置存储插件。
当您启用该功能门控时，您的集群会直接选择并使用相关的 CSI 驱动程序，而不是使用内置驱动程序代码。这发生在不检查是否在节点上启用了 CSI 迁移，或者您是否实际上部署了该 CSI 驱动程序的情况下。
虽然此功能门控是一个很好的帮手，但 SIG Storage（并且，我相信，许多集群运营商）也想要一个允许您禁用内置存储插件的功能门控，即使没有启用 CSI 迁移。例如，您可能希望在 GCE 集群上禁用 EBS 存储插件，因为 EBS 卷特定于其他供应商的云（AWS）。
为了实现这一点，Kubernetes v1.21 引入了一组新的功能标志：InTreePlugin{vendor}Unregister。
InTreePlugin{vendor}Unregister 是一个独立的功能门控，可以独立于 CSI 迁移启用和禁用。启用后，该组件不会将特定的内置存储插件注册到支持的列表中。如果集群操作员仅启用此标志，则最终用户将从 PVC 收到错误，提示在使用该插件时找不到该插件。如果他们不想支持旧的内置 API，而只支持 CSI 的发展，则集群操作员可能希望启用此功能，而不管 CSI 迁移与否。
可观察性
Kubernetes v1.21 引入了用于跟踪 CSI 迁移的 指标。您可以使用这些指标来观察集群如何使用存储服务，以及对该存储的访问是使用旧的内置驱动程序还是基于 CSI 的替代品。
| 组件 | 指标 | 注释 |
|---|---|---|
| Kube-Controller-Manager | storage_operation_duration_seconds | 一个新的标签 migrated 被添加到指标中，以指示此存储操作是否为 CSI 迁移操作（字符串值，启用时为 true，未启用时为 false）。 |
| Kubelet | csi_operations_seconds | 新指标公开了包括 driver_name、method_name、grpc_status_code 和 migrated 在内的标签。这些标签的含义与 csi_sidecar_operations_seconds 相同。 |
| CSI Sidecars（配置程序、附加程序、调整大小程序） | csi_sidecar_operations_seconds | 一个新的标签 migrated 被添加到指标中，以指示此存储操作是否为 CSI 迁移操作（字符串值，启用时为 true，未启用时为 false）。 |
错误修复和功能改进
在我们的 beta 测试人员的帮助下，我们修复了许多错误，例如悬空的附件、垃圾回收、不正确的拓扑标签。
云提供商 && 集群生命周期协作
SIG Storage 一直在与 SIG Cloud Provider 和 SIG Cluster Lifecycle 密切合作，推出 CSI 迁移。
如果您是托管 Kubernetes 服务的使用者，请咨询您的提供商是否需要执行任何操作。在许多情况下，提供商将管理迁移，无需额外工作。
如果您使用 Kubernetes 的发行版，请查看其官方文档，了解有关此功能支持的信息。对于 CSI 迁移功能毕业到 GA，SIG Storage 和 SIG Cluster Lifecycle 正在合作，以尽快在工具（例如 kubeadm）中提供迁移机制，只要它们在 Kubernetes 本身中可用即可。
时间表/状态是什么？
下表显示了每个单独驱动程序的当前和目标发布版本
| 驱动程序 | Alpha | Beta（内置已弃用） | Beta（默认开启） | GA | 目标“内置插件”移除 |
|---|---|---|---|---|---|
| AWS EBS | 1.14 | 1.17 | 1.23 | 1.24（目标） | 1.26（目标） |
| GCE PD | 1.14 | 1.17 | 1.23 | 1.24（目标） | 1.26（目标） |
| OpenStack Cinder | 1.14 | 1.18 | 1.21 | 1.24（目标） | 1.26（目标） |
| Azure Disk | 1.15 | 1.19 | 1.23 | 1.24（目标） | 1.26（目标） |
| Azure File | 1.15 | 1.21 | 1.24（目标） | 1.25（目标） | 1.27（目标） |
| vSphere | 1.18 | 1.19 | 1.24（目标） | 1.25（目标） | 1.27（目标） |
| Ceph RBD | 1.23 | ||||
| Portworx | 1.23 |
以下存储驱动程序将不提供 CSI 迁移支持。ScaleIO 驱动程序已被删除；其他驱动程序已被弃用，并将从核心 Kubernetes 中删除。
| 驱动程序 | 已弃用 | 代码删除 |
|---|---|---|
| ScaleIO | 1.16 | 1.22 |
| Flocker | 1.22 | 1.25（目标） |
| Quobyte | 1.22 | 1.25（目标） |
| StorageOS | 1.22 | 1.25（目标） |
下一步是什么？
随着越来越多的 CSI 驱动程序毕业到 GA，我们希望很快将整个 CSI 迁移功能标记为 GA。我们预计云提供商内置存储插件代码的删除将在 Kubernetes v1.26 和 v1.27 中发生。
作为用户，我应该做什么？
请注意，Kubernetes 存储系统的所有新功能（例如卷快照）将仅添加到 CSI 接口中。因此，如果您是首次启动新集群、首次创建有状态应用程序或需要这些新功能，我们建议您本地使用 CSI 驱动程序（而不是内置卷插件 API）。请遵循 CSI 驱动程序的更新用户指南 并使用新的 CSI API。
但是，如果您选择向前滚动集群或继续使用具有旧卷 API 的规范，CSI 迁移将确保我们继续使用新的 CSI 驱动程序支持这些部署。但是，如果您想利用快照等新功能，则需要手动迁移以重新导入现有的内置 PV 作为 CSI PV。
如何参与？
Kubernetes Slack 频道 #csi-migration 以及任何标准的 SIG Storage 通信渠道 都是联系 SIG Storage 和迁移工作组的好方法。
与所有 Kubernetes 一样，该项目是许多来自不同背景的贡献者共同努力的成果。我们非常感谢最近几个季度挺身而出帮助推动该项目前进的贡献者
- Michelle Au (msau42)
- Jan Šafránek (jsafrane)
- Hemant Kumar (gnufied)
特别感谢以下人员为 CSI 迁移功能提供的深刻见解、周全考虑和宝贵贡献
- Andy Zhang (andyzhangz)
- Divyen Patel (divyenpatel)
- Deep Debroy (ddebroy)
- Humble Devassy Chirammal (humblec)
- Jing Xu (jingxu97)
- Jordan Liggitt (liggitt)
- Matthew Cary (mattcary)
- Matthew Wong (wongma7)
- Neha Arora (nearora-msft)
- Oksana Naumov (trierra)
- Saad Ali (saad-ali)
- Tim Bannister (sftim)
- Xing Yang (xing-yang)
如果对参与 CSI 或 Kubernetes 存储系统任何部分的设计和开发感兴趣，请加入 Kubernetes 存储特别兴趣小组 (SIG)。我们正在快速发展，并始终欢迎新的贡献者。