Kubernetes 1.17 功能：Kubernetes In-Tree 到 CSI 卷迁移升级到 Beta

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

Kubernetes 的功能通常作为 Alpha 版本引入，并在后续版本中升级到 Beta（最终到稳定/正式发布）。这个过程使 Kubernetes 开发者能够获取反馈，发现和修复问题，迭代设计，并交付高质量、生产级的功能。

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

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

随着越来越多的 CSI Driver 被创建并达到生产就绪状态，我们希望所有 Kubernetes 用户都能获得 CSI 模型的益处。然而，我们不希望通过破坏现有的正式发布存储 API 来强迫用户进行工作负载/配置更改。前进的道路是清晰的——我们必须用 CSI 替换“树内插件”API 的后端。

什么是 CSI 迁移？

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

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

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

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

如果您是部署在下方列出的某个环境中的 Kubernetes 分发商，现在是开始测试 CSI 迁移并确定如何部署/管理适当的 CSI driver 的好时机。

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

您还必须在集群上安装必需的 CSI driver - 通常可以从您的选择的提供商那里找到相关的说明。CSI 迁移对于 GCE Persistent Disk 和 AWS Elastic Block Store 已进入 Beta 阶段，对于 Azure File/Disk 和 Openstack Cinder 已进入 Alpha 阶段。Kubernetes 分发商应该考虑自动化部署和管理（升级、降级等）他们将依赖的 CSI Driver。

要验证特性标志是否已启用以及 driver 是否已安装在特定节点上，您可以获取 CSINode 对象。您应该会在 drivers 列表中看到已迁移插件的树内插件名称以及您[已安装的] driver。

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 是否处于 RUNNING 状态

kubectl get pods web-server

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

要确认 CSI driver 实际正在处理您的请求，最好在执行存储管理操作后检查 CSI Driver 的容器日志。请注意，您的容器日志可能会因所使用的提供商而异。

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

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

当前限制

虽然 CSI 迁移现已进入 Beta 阶段，但存在一个主要限制阻止我们默认开启它。开启迁移仍然需要集群管理员在无缝接管存储功能之前安装 CSI driver。我们目前正与 SIG-CloudProvider 合作，为云分发版本捆绑所需的 CSI Driver 提供无缝体验。

时间表/状态是什么？

CSI 迁移的时间表实际上由 cloud provider 提取项目设定。它是从 Kubernetes 中移除所有 cloud provider 代码的工作的一部分。通过将云存储插件迁移到外部 CSI driver，我们能够提取所有 cloud provider 依赖项。

尽管总体功能已进入 Beta 阶段且默认不开启，但针对每个插件仍有工作要做。目前只有 GCE PD 和 AWS EBS 已通过迁移进入 Beta 阶段，但由于它们依赖于手动安装各自的 CSI Driver，两者都默认关闭。Azure File/Disk、OpenStack 和 VMWare 插件目前处于不太成熟的状态，而像 NFS、Portworx、RBD 等非云插件仍在规划阶段。

下表显示了每个独立云 driver 的当前和目标发布版本

下一步是什么？

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

作为用户我应该做什么？

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

然而，如果您选择滚动升级集群或继续使用旧版卷 API 的配置，CSI 迁移将确保我们继续使用新的 CSI driver 支持这些部署。

我如何参与？

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 迁移在其他功能中的周全考虑。

• ←上一篇
• 下一篇→