​Kubernetes 1.17新特性:存储卷从 In-Tree向CSI的迁移已到达Beta阶段

Kubernetes存储插件从in-tree到CSI的迁移在v1.17达到了beta阶段。CSI迁移在Kubernetes v1.14中作为alpha版引入。

Kubernetes功能通常以alpha形式引入，并在后续的Kubernetes发行版中移至beta（最终移至稳定版/ GA）。该过程使Kubernetes开发人员可以获得反馈，发现，并修复问题，迭代设计，并交付高质量的生产级特性。

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

在CSI之前，Kubernetes提供了功能强大的卷（volume）插件系统。这些批量插件是“in-tree插件”，这意味着它们的代码是核心Kubernetes代码的一部分，并随核心Kubernetes二进制文件一起发布。但是，向Kubernetes添加对新的卷插件的支持是一个挑战。想要向Kubernetes添加对其存储系统支持（甚至修复现有的volume插件中的bug）的供应商被迫与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集群，在kube-apiserver、kube-controller-manager和kubelet上启用CSIMigration（默认情况下为1.17启用）和CSIMigration{provider}（默认为禁用）功能标志。其中{provider}是集群中使用的in-tree云提供程序存储类型。

你还必须在集群上安装必要的CSI驱动程序-通常可以从你选择的提供商那里找到相关说明。CSI迁移适用于Beta版的GCE永久磁盘和AWS Elastic Block Store，以及alpha版的Azure Ffile / Ddisk和Openstack / Cinder。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驱动程序。我们目前正在与SIGsig-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插件代码作为云服务提供商提取的一部分而删除。我们预计到Kubernetesv1.21版本完成该项目，全面切换到“默认打开”迁移。

作为用户，我该做什么？

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

如果选择升级集群或继续使用旧版卷API规范，CSI迁移将确保我们继续通过新的CSI驱动程序支持这些环境。

参考文档：

https://kubernetes.io/blog/page/3/

作者:David Zhu，Google软件工程师