本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.23：Kubernetes 树内到 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 边车（provisioner、attacher、resizer） | 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 正在合作，以便在 Kubernetes 本身可用时，尽快在工具（例如 kubeadm）中提供迁移机制。
时间表/状态如何？
下表显示了每个驱动程序的当前和目标发布版本
| 驱动程序 | Alpha | 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)。我们正在快速成长，并随时欢迎新的贡献者。