这篇文章已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
为 Kubernetes 引入 Windows CSI 支持 alpha
用于 Windows 的 CSI Proxy 的 alpha 版本已随 Kubernetes 1.18 发布。CSI 代理通过允许 Windows 中的容器执行特权存储操作，从而在 Windows 上启用 CSI 驱动程序。
背景
Kubernetes 的容器存储接口 (CSI) 在 Kubernetes 1.13 版本中正式发布。CSI 已成为将块和文件存储公开给 Kubernetes 等容器编排系统 (CO) 上容器化工作负载的标准。它使第三方存储提供商无需更改核心 Kubernetes 代码库即可编写和部署插件。所有新的存储功能都将使用 CSI，因此使 CSI 驱动程序在 Windows 上工作非常重要。
Kubernetes 中的 CSI 驱动程序有两个主要组件：控制器插件和节点插件。控制器插件通常不需要直接访问主机，并且可以通过 Kubernetes API 和外部控制平面服务（例如，云存储服务）执行其所有操作。但是，节点插件需要直接访问主机，以便为 Kubernetes kubelet 提供块设备和/或文件系统。以前 Windows 上的容器无法实现这一点。随着 CSIProxy 的发布，CSI 驱动程序现在可以在节点上执行存储操作。这反过来使容器化的 CSI 驱动程序能够在 Windows 上运行。
Windows 集群的 CSI 支持
建议将 CSI 驱动程序（例如，AzureDisk、GCE PD 等）作为容器部署。CSI 驱动程序的节点插件通常在集群中的每个工作节点上运行（作为 DaemonSet）。节点插件容器需要以提升的权限运行才能执行与存储相关的操作。但是，Windows 当前不支持特权容器。为了解决这个问题，CSIProxy 使节点插件现在可以作为非特权 Pod 部署，然后使用代理在节点上执行特权存储操作。
节点插件与 CSIProxy 的交互
CSI 代理的设计在此 KEP 中捕获。下图描述了与 CSI 节点插件和 CSI 代理的交互。
CSI 代理作为进程直接在每个 Windows 节点的主机上运行 - 与 kubelet 非常相似。kubelet 中的 CSI 代码与 节点驱动程序注册器组件和 CSI 节点插件交互。节点驱动程序注册器是一个社区维护的 CSI 项目，负责处理特定于供应商的节点插件的注册。kubelet 在节点插件上启动 CSI gRPC 调用，例如 NodeStageVolume/NodePublishVolume，如图所示。节点插件与 CSIProxy 进程交互以执行本地主机操作系统与存储相关的操作，例如卷的创建/枚举、挂载/卸载等。
CSI 代理架构和实现
在 alpha 版本中，CSIProxy 支持以下 API 组
- 文件系统
- 磁盘
- 卷
- SMB
CSI 代理通过 Windows 命名管道公开每个 API 组。通信是使用 gRPC 通过这些管道执行的。CSI 代理项目中的客户端库使用这些管道与 CSI 代理 API 交互。例如，文件系统 API 通过类似于 \.\pipe\csi-proxy-filesystem-v1alpha1 的管道公开，卷 API 通过 \.\pipe\csi-proxy-volume-v1alpha1 公开，依此类推。
从每个 API 组服务，调用被路由到主机 API 层。主机 API 通过 Powershell 或 Go 标准库调用进入主机 Windows OS。例如，当调用文件系统 API Rmdir 时，API 组服务将解码 grpc 结构 RmdirRequest 并找到要删除的目录，然后调用主机 API 层。这将导致调用 os.Remove，这是一个 Go 标准库调用，以执行删除操作。
控制流详细信息
下图使用 CSI 调用 NodeStageVolume 作为示例来解释 kubelet、CSI 插件和 CSI 代理之间用于配置新卷的交互。在节点插件收到 CSI RPC 调用后，它会相应地对 CSIProxy 进行几次调用。作为 NodeStageVolume 调用的结果，首先使用磁盘 API 调用之一来标识所需的磁盘：ListDiskLocations（在 AzureDisk 驱动程序中）或 GetDiskNumberByName（在 GCE PD 驱动程序中）。如果磁盘未分区，则调用 PartitionDisk（磁盘 API 组）。随后，调用 Volume API，例如 ListVolumesOnDisk、FormatVolume 和 MountVolume，以执行其余所需的操作。在 NodeUnstageVolume、NodePublishVolume、NodeUnpublishedVolume 等情况下执行类似的操作。
当前支持
CSI 代理现在以 alpha 版本提供。您可以在 CSIProxy GitHub 存储库中找到更多详细信息。目前，有两个云提供商为 Windows 上的 CSI 驱动程序提供 alpha 支持：Azure 和 GCE。
未来计划
beta 版的一个主要关注领域将是基于 Windows 的构建和 CI/CD 设置，以提高代码库的稳定性和质量。另一个领域是直接使用基于 Go 的调用而不是 Powershell cmdlet 来提高性能。增强可调试性和添加更多测试是团队将关注的其他领域。
如何参与？
这个项目，像所有的 Kubernetes 一样，是来自不同背景的许多贡献者共同努力的结果。那些有兴趣参与 CSI Proxy 的设计和开发，或 Kubernetes 存储系统的任何部分的人，可以加入 Kubernetes 存储特别兴趣小组 (SIG)。我们正在迅速发展，并且始终欢迎新的贡献者。
对于那些对更多详细信息感兴趣的人，CSIProxy GitHub 存储库是一个很好的起点。此外，kubernetes slack 上的 #csi-windows 频道可用于讨论特定于 Windows 上 CSI 的问题。
鸣谢
我们要感谢 Michelle Au 在整个 alpha 之旅中的指导。我们要感谢 Jean Rougé 在最初的 CSI 代理工作中所做的贡献。我们要感谢 Saad Ali 在项目方面的所有指导以及对本博客草稿的审查/反馈。我们要感谢 Patrick Lang 和 Mark Rossetti 在 Windows 特定问题和细节方面的帮助。特别感谢 Andy Zhang 对 Azuredisk 和 Azurefile 工作的审查和指导。非常感谢 Paul Burt 和 Karen Chu 对改进这篇博文的审查和建议。
最后但并非最不重要的一点是，我们要感谢在项目每个阶段做出贡献的更广泛的 Kubernetes 社区。