Kubernetes 1.17 功能：Kubernetes 内置到 CSI 卷迁移移至 Beta

Kubernetes 的 in-tree 存储插件到 容器存储接口 (CSI) 的迁移基础设施现在在 Kubernetes v1.17 中处于 Beta 阶段。CSI 迁移在 Kubernetes v1.14 中作为 Alpha 版本引入。

Kubernetes 功能通常以 Alpha 版本引入，并在后续的 Kubernetes 版本中移至 Beta（最终移至 Stable/GA）。此过程允许 Kubernetes 开发人员获取反馈、发现并修复问题、迭代设计，并交付高质量的生产级功能。

我们为什么要将 in-tree 插件迁移到 CSI？

在 CSI 之前，Kubernetes 提供了一个强大的卷插件系统。这些卷插件是“in-tree”的，这意味着它们的代码是 Kubernetes 核心代码的一部分，并与 Kubernetes 核心二进制文件一起发布。但是，向 Kubernetes 添加对新卷插件的支持具有挑战性。希望向 Kubernetes 添加对其存储系统支持（甚至修复现有卷插件中的错误）的供应商被迫与 Kubernetes 发布过程保持一致。此外，第三方存储代码在 Kubernetes 核心二进制文件中导致了可靠性和安全问题，并且代码通常难以（在某些情况下不可能）由 Kubernetes 维护人员进行测试和维护。在 Kubernetes 中使用容器存储接口解决了这些主要问题。

随着越来越多的 CSI 驱动程序被创建并投入生产，我们希望所有 Kubernetes 用户都能享受到 CSI 模型的好处。但是，我们不想通过破坏现有的通用存储 API 来迫使用户进行工作负载/配置更改。前进的道路很明确 - 我们必须用 CSI 替换“in-tree 插件”API 的后端。

什么是 CSI 迁移？

CSI 迁移工作使得可以使用相应的 CSI 驱动程序替换现有的 in-tree 存储插件，例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs。如果 CSI 迁移正常工作，Kubernetes 最终用户不应注意到任何差异。迁移后，Kubernetes 用户可以使用现有接口继续依赖 in-tree 存储插件的所有功能。

当 Kubernetes 集群管理员更新集群以启用 CSI 迁移时，现有的有状态部署和工作负载会像往常一样继续运行；但是，在后台，Kubernetes 会将所有存储管理操作（之前针对 in-tree 驱动程序）的控制权移交给 CSI 驱动程序。

Kubernetes 团队一直在努力确保存储 API 的稳定性，并承诺提供流畅的升级体验。这涉及对所有现有功能和行为进行细致的核算，以确保向后兼容性和 API 稳定性。你可以将其想象为在赛车以高速直线行驶时更换车轮。

如何试用现有插件的 CSI 迁移？

如果你是部署在下面列出的环境之一中的 Kubernetes 发行商，那么现在是开始测试 CSI 迁移并弄清楚如何部署/管理相应的 CSI 驱动程序的好时机。

要试用现有插件的 Beta 版 CSI 迁移，你必须使用 Kubernetes v1.17 或更高版本。首先，你必须更新/创建 Kubernetes 集群，并在所有 Kubernetes 组件（主节点和节点）上启用功能标志 CSIMigration（在 1.17 中默认启用）和 CSIMigration{provider}（默认禁用）。其中 {provider} 是集群中使用的 in-tree 云提供商存储类型。请注意，在集群升级期间，你必须先排空每个节点（删除正在运行的工作负载），然后才能更新或更改 Kubelet 的配置。你可能还会看到一个可选的 CSIMigration{provider}Complete 标志，如果你的所有节点都启用了 CSI 迁移，则你可以启用该标志。

你还必须在集群上安装必需的 CSI 驱动程序 - 此说明通常可以从你选择的提供商处找到。CSI 迁移适用于 GCE 持久磁盘和 AWS 弹性块存储的 Beta 版，以及适用于 Azure 文件/磁盘和 Openstack Cinder 的 Alpha 版。Kubernetes 发行商应考虑自动化其将依赖的 CSI 驱动程序的部署和管理（升级、降级等）。

要验证是否在特定节点上启用了功能标志并安装了驱动程序，你可以获取 CSINode 对象。你应该在驱动程序列表中看到已迁移插件的 in-tree 插件名称以及你[已安装]的驱动程序。

kubectl get csinodes -o yaml

- apiVersion: storage.k8s.io/v1
  kind: CSINode
  metadata:
    annotations:
      storage.alpha.kubernetes.io/migrated-plugins: kubernetes.io/gce-pd
    name: test-node
    ...
  spec:
    drivers:
      name: pd.csi.storage.gke.io
      ...

完成上述设置后，你可以通过使用旧 API 部署有状态工作负载来确认你的集群具有正常工作的 CSI 迁移。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-disk
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       - mountPath: /var/lib/www/html
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       claimName: test-disk

验证 Pod 在一段时间后是否正在运行

kubectl get pods web-server

NAME         READY   STATUS    RESTARTS   AGE
web-server   1/1     Running   0          39s

要确认 CSI 驱动程序实际上正在为你的请求提供服务，明智的做法是在执行存储管理操作后检查 CSI 驱动程序的容器日志。请注意，你的容器日志可能会因使用的提供商而异。

kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}

/csi.v1.Controller/ControllerPublishVolume called with request: ...
Attaching disk ... to ...
ControllerPublishVolume succeeded for disk ... to instance ...

当前限制

尽管 CSI 迁移现在是 Beta 版，但仍有一个主要限制阻止我们默认启用它。启用迁移仍然需要集群管理员在无缝移交存储功能之前安装 CSI 驱动程序。我们目前正在与 SIG-CloudProvider 合作，以提供将所需的 CSI 驱动程序与云分发捆绑在一起的无摩擦体验。

时间表/状态是什么？

CSI 迁移的时间表实际上是由云提供商提取项目设置的。它是从 Kubernetes 中删除所有云提供商代码的工作的一部分。通过将云存储插件迁移到外部 CSI 驱动程序，我们能够提取出所有云提供商依赖项。

尽管整体功能是 Beta 版，并且默认未启用，但每个插件仍然需要完成一些工作。目前只有 GCE PD 和 AWS EBS 已进入 Beta 版迁移阶段，但由于它们依赖于手动安装各自的 CSI 驱动程序，因此两者仍然默认处于关闭状态。Azure 文件/磁盘、OpenStack 和 VMWare 插件目前处于不太成熟的状态，而 NFS、Portworx、RBD 等非云插件仍在规划阶段。

下表显示了每个单独的云驱动程序的当前和目标版本

下一步是什么？

即将进行的主要工作包括为其余的 in-tree 插件实施和强化 CSI 迁移、在发行版中默认安装 CSI 驱动程序、默认启用 CSI 迁移，以及最后删除所有 in-tree 插件代码作为云提供商提取的一部分。我们预计将在 Kubernetes v1.21 之前完成此项目，包括完全切换到“默认启用”迁移。

作为用户我应该做什么？

请注意，Kubernetes 存储系统的所有新功能（如卷快照）都将仅添加到 CSI 接口。因此，如果你要启动新的集群、首次创建有状态应用程序或需要这些新功能，我们建议本机使用 CSI 驱动程序（而不是 in-tree 卷插件 API）。请遵循 CSI 驱动程序的更新用户指南并使用新的 CSI API。

但是，如果你选择向前滚动集群或继续使用具有旧卷 API 的规范，CSI 迁移将确保我们继续使用新的 CSI 驱动程序支持这些部署。

我如何参与？

Kubernetes Slack 频道 csi-migration 以及任何标准的 SIG 存储通信渠道是联系 SIG 存储和迁移工作组的好方法。

该项目与所有 Kubernetes 项目一样，是来自不同背景的许多贡献者共同努力的结果。我们非常感谢这些季度以来站出来帮助项目达到 Beta 版的贡献者

• David Zhu
• Deep Debroy
• Cheng Pan
• Jan Šafránek

特别感谢

• Michelle Au
• Saad Ali
• Jonathan Basseri
• Fabio Bertinatto
• Ben Elder
• Andrew Sy Kim
• Hemant Kumar

感谢他们富有成效的对话、深刻的评论，以及对其他功能中 CSI 迁移的全面考虑。

• ←上一篇
下一篇→