Kubernetes 1.17 特性：Kubernetes 树内到 CSI 卷迁移进入 Beta 阶段

Kubernetes 树内存储插件到容器存储接口 (CSI) 的迁移基础设施在 Kubernetes v1.17 中已进入 Beta 阶段。CSI 迁移在 Kubernetes v1.14 中作为 Alpha 引入。

Kubernetes 功能通常作为 Alpha 引入，并在随后的 Kubernetes 版本中进入 Beta 阶段（最终进入稳定/GA 阶段）。这个过程允许 Kubernetes 开发者获取反馈、发现并修复问题、迭代设计，并交付高质量、生产级的特性。

为什么我们要将树内插件迁移到 CSI？

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

随着越来越多的 CSI 驱动程序被创建并投入生产，我们希望所有 Kubernetes 用户都能从 CSI 模型中获益。然而，我们不想通过破坏现有的通用存储 API 来强迫用户进行工作负载/配置更改。前进的道路很清晰——我们必须用 CSI 替换“树内插件”API 的后端。

什么是 CSI 迁移？

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

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

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

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

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

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

您还必须在集群上安装必要的 CSI 驱动程序——有关此说明通常可以在您选择的提供商处找到。CSI 迁移已在 GCE 持久磁盘和 AWS 弹性块存储中进入 Beta 阶段，并在 Azure 文件/磁盘和 Openstack Cinder 中进入 Alpha 阶段。Kubernetes 分销商应考虑自动化其将依赖的 CSI 驱动程序的部署和管理（升级、降级等）。

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

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 等非云插件仍处于规划阶段。

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

接下来是什么？

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

作为用户我应该怎么做？

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

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

我如何参与？

Kubernetes Slack 频道 csi-migration 以及任何标准的 SIG Storage 通信渠道都是联系 SIG Storage 和迁移工作组团队的好途径。

这个项目，就像所有的 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 迁移的全面考虑。

• ←上一篇
• 下一篇→