这篇文章已超过一年。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已失效。
Kubernetes 1.23：Kubernetes 树内卷迁移至 CSI 卷迁移状态更新
Kubernetes in-tree 存储插件到 容器存储接口 (CSI) 的迁移基础设施自 v1.17 起已达到 Beta 阶段。CSI 迁移作为 Alpha 功能在 Kubernetes v1.14 中引入。
自那时以来，SIG Storage 和其他 Kubernetes 特别兴趣小组一直致力于确保该功能的稳定性和兼容性，为 GA 做准备。本文旨在提供该功能的最新状态以及 Kubernetes 1.17 和 1.23 之间的变化。此外，我还将介绍 CSI 迁移功能针对每个存储插件的 GA 未来路线图。
快速回顾：什么是 CSI 迁移，为何要迁移？
容器存储接口 (CSI) 旨在帮助 Kubernetes 替换其现有的 in-tree 存储驱动机制，特别是特定于供应商的插件。Kubernetes 对 容器存储接口 的支持自 Kubernetes v1.13 起已正式发布 (GA)。引入对使用 CSI 驱动的支持是为了更容易地在 Kubernetes 和存储后端技术之间添加和维护新的集成。使用 CSI 驱动可以提高可维护性（驱动作者可以定义自己的发布周期和支持生命周期），并减少漏洞的可能性（in-tree 代码更少，出错的风险降低，集群操作员可以只选择其集群所需的存储驱动）。
随着越来越多的 CSI 驱动被创建并达到生产就绪状态，SIG Storage 小组希望所有 Kubernetes 用户都能从 CSI 模型中受益。然而，我们不能破坏与现有存储 API 类型的 API 兼容性。我们提出的解决方案是 CSI 迁移：这是一个将 in-tree API 转换为等效 CSI API 并将操作委托给替代 CSI 驱动的功能。
CSI 迁移工作使得用存储后端的相应 CSI 驱动 替换现有的 in-tree 存储插件成为可能，例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs。如果 CSI 迁移正常工作，Kubernetes 最终用户应该不会注意到差异。现有的 StorageClass、PersistentVolume 和 PersistentVolumeClaim 对象应该继续工作。当 Kubernetes 集群管理员更新集群以启用 CSI 迁移时，使用由 in-tree 存储插件支持的 PVC 的现有工作负载将像往常一样继续运行。然而，在幕后，Kubernetes 将所有存储管理操作（以前针对 in-tree 驱动）的控制权交给 CSI 驱动。
例如，假设你是 kubernetes.io/gce-pd 用户，在 CSI 迁移后，你仍然可以使用 kubernetes.io/gce-pd 来供应新卷、挂载现有 GCE-PD 卷或删除现有卷。所有现有的 API/接口仍然会正常工作。然而，底层函数调用都将通过 GCE PD CSI 驱动 来完成，而不是 in-tree 的 Kubernetes 函数。
这为最终用户实现了平滑过渡。此外，作为存储插件开发者，我们可以减轻维护 in-tree 存储插件的负担，并最终将它们从核心 Kubernetes 二进制文件中移除。
有哪些变化，又有哪些新特性？
基于 Kubernetes v1.17 及早期版本所做的工作，后续版本进行了一系列更改
新的特性门控
Kubernetes v1.21 版本弃用了 CSIMigration{provider}Complete 特性标志，并停止遵循它们。取而代之的是名为 InTreePlugin{vendor}Unregister 的新特性标志，这些新标志取代了旧的特性标志并保留了 CSIMigration{provider}Complete 提供的所有功能。
CSIMigration{provider}Complete 之前作为辅助特性门控引入，一旦在所有节点上启用了 CSI 迁移，就可以使用它。该标志会注销你在标志名称的 {provider} 部分指定的 in-tree 存储插件。
当你启用该特性门控时，你的集群将直接选择并使用相关的 CSI 驱动，而不是使用 in-tree 驱动代码。这样做不会检查节点上是否启用了 CSI 迁移，也不会检查你是否实际上部署了该 CSI 驱动。
尽管这个特性门控非常有用，但 SIG Storage（我相信还有许多集群操作员）也想要一个特性门控，即使不启用 CSI 迁移，也能禁用 in-tree 存储插件。例如，你可能想在 GCE 集群上禁用 EBS 存储插件，因为 EBS 卷是特定于其他供应商的云（AWS）。
为了实现这一点，Kubernetes v1.21 引入了一组新的特性标志：InTreePlugin{vendor}Unregister。
InTreePlugin{vendor}Unregister 是一个独立的特性门控，可以独立于 CSI 迁移启用或禁用。启用后，组件不会将特定的 in-tree 存储插件注册到支持列表中。如果集群操作员只启用此标志，则当使用该插件时，终端用户会从 PVC 收到一个错误，指示找不到该插件。如果集群操作员不想支持遗留的 in-tree API 并只支持 CSI，则无论 CSI 迁移是否启用，都可能想要启用此功能。
可观测性
Kubernetes v1.21 引入了用于跟踪 CSI 迁移的 指标。你可以使用这些指标来观察你的集群如何使用存储服务，以及对该存储的访问是使用遗留的 in-tree 驱动还是基于 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 Sidecar（provisioner, attacher, resizer） | csi_sidecar_operations_seconds | 指标中添加了一个新的标签 migrated，用于指示此存储操作是否是 CSI 迁移操作（启用时字符串值为 true，未启用时为 false）。 |
Bug 修复和功能改进
在 Beta 测试人员的帮助下，我们修复了许多 Bug，例如悬空挂载、垃圾回收、不正确的拓扑标签等。
云提供商和集群生命周期协作
SIG Storage 一直与 SIG Cloud Provider 和 SIG Cluster Lifecycle 密切合作，共同推进 CSI 迁移的推出。
如果你是托管 Kubernetes 服务的用户，请咨询你的提供商是否需要采取任何措施。在许多情况下，提供商将负责管理迁移，无需额外工作。
如果你使用某个 Kubernetes 发行版，请查阅其官方文档，了解对此功能的支持信息。对于 CSI 迁移功能晋级 GA，SIG Storage 和 SIG Cluster Lifecycle 正在合作，以便在 Kubernetes 本身可用后尽快在工具（如 kubeadm）中提供迁移机制。
时间线 / 状态如何？
下表显示了每个驱动的当前和目标发布版本
| 驱动 | Alpha | Beta（in-tree 弃用） | Beta（默认开启） | GA | 目标“in-tree 插件”移除版本 |
|---|---|---|---|---|---|
| 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。我们预计云提供商 in-tree 存储插件的代码将在 Kubernetes v1.26 和 v1.27 版本中移除。
作为用户，我该怎么做？
请注意，Kubernetes 存储系统的所有新功能（例如卷快照）将仅添加到 CSI 接口。因此，如果你正在启动新集群、首次创建有状态应用或需要这些新功能，我们建议原生使用 CSI 驱动（而不是 in-tree 卷插件 API）。请遵循 CSI 驱动的最新用户指南 并使用新的 CSI API。
但是，如果你选择升级集群或继续使用遗留卷 API 的规范，CSI 迁移将确保我们继续使用新的 CSI 驱动支持这些部署。然而，如果你想利用快照等新功能，则需要手动迁移以将现有的 in-tree 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 Storage 特别兴趣小组 (SIG)。我们正在快速发展，并始终欢迎新的贡献者。