作者：汪照辉 王作敬

存储问题本来是想过段时间再详细考虑，不过最近业务团队在使用容器云平台时遇到了几个问题使我们不得不调整工作优先顺序，认真考虑下容器云平台存储的需求场景和存储规划的问题。前期虽然也有所考虑，但真正在生产环境中应用时还是发现很有多问题没有考虑到。

一、 容器云平台存储需求

除了前期我们讨论过的容器云平台镜像仓库存储需求、业务应用服务持久化存储需求、etcd、中间件等存储需求外，大部分业务对存储需求不是很大，对于大量分布式存储需求并不强烈，另外我们在存储速度延迟性等方面暂时也没有明确的需求，所以也就没有考虑搭建分布式存储，而是采用NAS存储作为临时方案。我们本以为传统NAS存储基本可以满足大部分需求，但Kubernetes对NAS的支持实在太差，使我们不得不考虑在平台上扩展支持方案。总的来说目前我们面临着以下几个明确的存储需求场景：

（一） 不同租户之间可能需要共享文件

一个团队是一个租户，虽然我们推荐采用微服务架构，分拆业务应用，但不同团队之间的业务应用并不能完全采用http等协议，特别一些大文件传输，可能需要暂存于网络磁盘的一个目录，或者两个团队协商使用同一个网络文件存储目录，一个写，一个读，或者彼此实现文件交互，这就需要我们分配一块共享卷来实现文件交换。很多服务设计由于受传统合作厂商的数据库表交换、文件交换的设计方式的影响较深，因此难以一时之间全部转换。
不同租户之间都可以访问的存储卷应该是公共的存储卷，这些公共的存储卷由谁管理，如何管理在容器云平台可能也是个问题，比如共享卷维护、共享文件过期清理等。
不过不同租户共享文件需要的公共的网络磁盘空间，这块磁盘可以由平台管理员来维护，也可以由租户申请一块公共磁盘空间用于和其他租户之间进行文件共享。（这样的需求可能在以后会涉及网络云盘的集成需求，但具体怎么实现还没考虑好，各位专家可以考虑下可行性和实现方式）。这两种方式权限和职责会有所不同，不过作为平台，理论上应该支持多种方式。

（二） 同一租户不同应用服务之间可能需要共享文件

除了不同租户之间需要共享文件存储支持外，同一租户的不同业务服务之间也有这样的需求。这需求相对简单些，类似于租户内的公共存储空间，不同的应用和服务都可以使用这块存储空间。但是其他租户是不能访问这块存储空间的，也就是说它是租户私有的。
这样的思路从设计上来说，可能需要考虑租户权限以及租户和资源的所属关系，比第一条需求要稍微麻烦些。

（三） 同一服务不同容器实例之间可能需要共享文件

这个需求个人觉得其实可以合并到上一个需求。可能不同的一点是涉及权限管理，同一租户不同服务可能分属租户下不同的用户，但同一服务的不同实例一定在同一用户之下。如果租户下没有复杂的组织和用户架构，可以不考虑这么复杂。

（四） 容器实例重启、迁移访问同一共享存储地址

这个需求才和容器云平台紧密相关，容器实例在重启、迁移时，挂载的存储不能在重启或迁移后丢失，重启和迁移后还要访问这块存储并读取需要的文件。比如服务初始配置、容器服务运行状态、会话等信息（以文件方式存放）。

（五） 查看存储上详细的文件信息

在Kubernetes上目前似乎无法直接查看NAS存储上到底有什么文件，文件的详细信息等。通过命令行不但繁琐，也让运维人员抵触强制的额外的知识学习要求。

二、 对NAS存储支持的问题

这些需求是传统的一些文件共享需求，容器云平台存储管理不同于传统方式，所以也带来了些问题，在没有建设分布式存储的情况下，采用NAS等传统存储方式，面临着Kubernetes支持的问题，分一块NAS存储，Kubernetes只能mount上，谁在用，存了什么，几乎是两眼一摸黑（只能登录节点命令行方式查看），细粒度的控制管理更是不可能（存储再分配）。我们在和厂商及存储方面的专家多次交流的基础上，对这块多少有了些了解，整理如下，供参考。

1． 不同NAS存储种类的支持需求问题
NAS存储可能来自不同的厂商，所以对于容器云平台来说如果对接支持不同存储厂商的产品，这个似乎比较困难。另外NAS不像分布式存储有通用的API接口可以调用，定制开发的支持似乎也没那么容易。

2． NAS共享存储分配细粒度管理需求问题
每一个共享卷就需要分配一块NAS盘，无法分配一块大空间在k8s中进行再分配，Kubernetes不支持对NAS存储分配的细粒度管理。所以在申请一块存储卷后没办法再分配一部分给其他租户或用户去用，也不能只给所有的租户或所有的用户或所有的应用服务只分配一块NAS存储共享使用（涉及权限管理隔离需求），或者提前请NAS存储管理员分配很多大小不一的存储卷（无法提前预知具体的存储需求），如果频繁的申请存储卷又会让NAS存储管理员不堪重负（除非实现NAS存储资源管理集成和自动化），也使存储资源管理复杂化。

3． 共享存储卷上存了什么文件及目录结构，难以从容器云平台上看到
正是由于Kubernetes对NAS存储的支持不够，所以无法知道mount到Kubernetes上的存储卷上有什么，如果忘记或者不小心，可能导致数据被覆盖，从而可能导致业务错误或数据丢失。如果每次都登录到节点去从命令行查看，显然安全性和便捷性不足。

4． 共享存储卷的大小、使用量、权限管理等
安全要求无处不在，所以我们也一再要求尽可能在界面实现客户需求，禁用命令行终端工具。存储作为基础资源，对存储的一切管理、查看、操作都应该在界面上提供，而不是让客户从终端命令行中去执行命令。终端命令行工具只能对容器云平台管理员开放，由平台管理员来维护平台的基础设施资源。比如存储出现异常，或者存储需要扩展，而租户和用户只是使用这些资源。所以每个租户或用户下所分配的存储量、使用量、存储上的文件、文件权限、存储类别等对租户或用户应该都是可见的。

三、 容器云平台对NAS存储支持设计思路

在当前需求和Kubernetes对NAS存储有限支持的情况下，我们在想是否可以找到一种简单的方式来更好的在容器云平台支持NAS存储，而不用带来巨大的定制化开发工作，同时又保持和以Kubernetes为基础的容器调度管理平台的松耦合。我们和UCloud等多位存储专家讨论过不同的实现方案。但也没有什么好的共识。不过对我们来说，首先要考虑先支持业务需求，因此我们考虑先用下面的思路实现。

1．存储管理的两个视角：平台管理员视角和租户视角。平台管理员维护容器云平台的所有存储资源，比如Mount存储到平台，分配一块存储给租户，回收分配给租户的资源等。租户只是使用分配的资源。租户可以申请多块存储资源，一旦申请成功（平台管理员分配完成），租户就可以在自己的存储管理界面查看到自己的存储资源列表。
对分布式存储比如Ceph等，这些需求的实现可能相对简单，不过对于NAS存储，可能无法通过调用NAS存储的接口实现，而且NAS存储种类、厂商众多，实现对不同厂商、不同种类的支持也不太现实。所以我们考虑在存储之上通过文件目录结构来实现，不管什么存储，只要支持文件结构，就可以通过这种软的类似插件的方式进行管控，虽然不完美，但目前来说可能是一种比较简单的方式。

2．平台管理员向NAS存储管理员申请一大块容器云平台使用的存储。比如说500G。在资源整合之前，通常NAS存储会有专人负责管理，容器云平台也是独立的，比如我们存储资源池、虚拟机、容器等彼此独立但又相互联系，都作为基础设施资源。

3．平台管理员拿到NAS存储之后需要根据申请分配给租户。比如租户A申请100G的存储空间，租户B需要20G的存储空间。这里有两种实现方式。第一种是在NAS存储上建立“文件夹A”和“文件夹B”，然后分别mount这两个文件夹给租户A和租户B。第二种方式是整块存储mount到容器云平台，然后直接分配给租户一个子文件夹。
存储卷大小管理需要借助平台保存这些存储卷的信息。不管这些信息是在文件、数据库或etcd中，需要持久化保存。同时要监控文件夹的大小变化，到达存储分配的最大值时禁止继续写入（当然也可以实现存储自动扩展能力），并及时在资源不足时提醒。这可能需要一个进程来完成这项任务。

4．在租户的存储管理界面，列出该租户所有的存储卷信息，包括卷名称（或文件夹名）、容量、使用量、详情（存储的文件目录信息）等。
租户不能通过终端命令行访问这些信息和其他租户的文件，屏蔽租户对宿主机命令行访问能力，只提供租户管理界面存储卷上的文件目录结构访问权限。

5．存储文件的管理也可以借助操作系统用户、组的管理能力。也可不考虑那么复杂，只实现文件目录结构管理，屏蔽终端命令行，做到相对的安全，这样也就只是实现对文件的管理，与具体的存储类型没有关系，但可以满足目前大部分采用容器云平台未不是分布式存储或对分布式存储需求不大的仅使用NAS存储的客户的需求。

6．租户可以申请共享存储卷（共享目录），然后共享给其他租户，这些租户都可以访问共享存储，读写其中的文件，共享卷通过卷标签标识。
这种思路秉承我们容器云平台“三视角四层次一回环”的设计思想，各组件之间尽可能的松耦合，同时简化一些繁琐的设计，尝试采用简单的方法来满足需求。实际的实现过程中也许还需要做一些调整，不过在容器云平台更好支持NAS存储，更好的提供存储服务，这可能是一种比较简单快捷的实现方法。