问题

目前阿里云的Kuberntes服务可以提供多种形式的存储对接，包括云盘、NAS以及OSS。在Kubernetes的控制台就可以直接创建对应的PV(存储卷)/PVC(存储声明):

但是对于使用那种存储，或许大家还不是太清晰，对于其中是否有什么约束也不是太清楚。另外Kubernetes使用存储的方式相对来说还是比较复杂的，哪种方式才是最佳的实践？期望本文能给大家一些借鉴和参考。

存储类型的选择

云盘

云盘，就是ECS用的磁盘。该磁盘只能给一台机器使用。用到容器里，也就是一个云盘存储卷PV只能被一个POD使用，不能在多个POD*享。可能有人会问了，如果是用了云盘，又需要部署Deployment的多个POD实例，不就有问题了么？这个可以通过StorageClass的方式动态创建云盘，后面讲。

云盘存储卷PV的创建比较简单，需要先到云盘里先创建一个空云盘，然后在容器存储上创建对应的PV就可。为了避免重复，云盘id就是云盘存储卷的名字。

同时云盘储卷PV会默认打上3个标签：

• alicloud-pvname: 储卷PV名字，也就是云盘ID
• failure-domain.beta.kubernetes.io/zone： 云盘所在的可用区
• failure-domain.beta.kubernetes.io/region：云盘所在的地区

后续需要可以根据这些标签来作为PVC的绑定的选择

因为云盘就是类似机器的磁盘，是有固定大小的。所以如果需要约束一个POD使用的空间，使用云盘也是一种方式，这样避免一个POD使用太多的存储空间，唯一需要考虑的风险是如果云盘满了将影响POD的运行。但是不会因为磁盘满而驱逐Pod。如果使用磁盘空间的request/limit，则会到达限量时会去驱逐Pod，因为要保护机器的运行。

如果需要扩容云盘，是需要删除对应的deployment/daemonset/statefulset，因为如果只是删除POD，调度会重新拉起POD，还是会占用改云盘，造成没法扩容的

另外这里有个小问题，如果扩容了云盘，对应的PV显示的大小是不会变更的，但是不影响使用，那个大小只是个申明，可以通过变更yaml改掉对应的现实

后面我们将支持云盘的加密选项的PV，敬请期待！

NAS

NAS提供标准的文件访问协议，您无需对现有应用做任何修改，即可使用具备无限容量及性能扩展、单一命名空间、多共享、高可靠和高可用等特性的分布式文件系统。

对于在K8S中使用，通常是用在频繁读写的场景，或者是需要多个POD间共享的场景。
这里需要注意的是，NAS的PV实际是没有空间限制的。虽然在PV里可以申明大小，但是当应用写超过这个限制是不会有任何影响的。因为底层是支持“无限”大小的。（目前限制是：SSD性能型文件系统存储容量上限1PB，容量型文件系统存储容量上限10PB。后续可能会发生变化，需要留意）

OSS

OSS是阿里云提供的海量、安全、低成本、高可靠的云存储服务。它具有与平台无关的RESTful API接口，能够提供99.999999999%（11个9）的数据可靠性和99.99%的服务可用性。

OSS的PV也是可以用在多个POD同时读的场景的。
OSS适合写入频度比较低，对于读取要求比较高，没有随机访问需求，比如媒体文件访问等

K8S使用存储的正确的姿势

大家主要可以参考下面这个图（来自Kubernetes in Action这本书，强烈推荐大家认真读读）

对于在K8S使用存储，主要分为两类用户：

• 管理员：主要负责创建Storage Class和Persistent Volume
• 使用者：主要是创建Persistent Volume Claim给Pod使用

建议大家统一按照这个模式来使用存储。
概念可以参考官网：https://kubernetes.io/docs/concepts/storage/persistent-volumes/，下面也针对阿里云的实现做些解释

Storage Class/Persistent Volume Provisioner

Storage Class用来申明使用什么样的提供者Persistent Volume Provisioner来配置persisent volume。

阿里云默认提供了云盘的Storage Class：

• alicloud-disk-common：普通云盘。
• alicloud-disk-efficiency：高效云盘。
• alicloud-disk-ssd：SSD云盘。
• alicloud-disk-available：提供高可用选项，先试图创建高效云盘；如果相应AZ的高效云盘资源售尽，再试图创建SSD盘；如果SSD售尽，则试图创建普通云盘。

注意这个只是针对单AZ的集群，如果是多AZ集群需要自己构建对应的Storage Class，可以参考: https://help.aliyun.com/document_detail/63955.html?spm=a2c4g.11186623.6.636.bKEidy

如果是通过界面绑定PV的方式，则是通过storageClassName为nas或者oss来指定。这里需要注意的是nas/oss并不是真实存在的storage class，它更像一个标签说明存储类型。

Persistent Volume

持久卷，就是将数据存储放到对应的外部可靠存储中，然后提供给Pod/容器使用，而无需先将外部存储挂在到主机上再提供给容器。它最大的特点是其生命周期与Pod不关联，在Pod死掉的时候它依然存在，在Pod恢复的时候自动恢复关联。
所以对于业务需要可靠性保留数据务必使用PV，而不要使用任何普通卷。

这里需要注意的是，PV和存储提供商有绑定关系，阿里云目前通过flexVolume的插件方式与阿里云的存储对接。（后续将通过CSI的方式，敬请期待）

PV创建的时候会申明大小，这里需要注意的是：

• 云盘是有大小的，后续如果扩容云盘，对应的PV不会发生描述变化，又需要可以认为更改
• NAS/OSS虽然是可以申明大小，但是底层是“无限”的，所以写超过这个容量是没有问题的。

另外，从模型上，因为PV和Storage Class是由管理员的创建和维护的，所以两者都和namespace没有关联

Persistent Volume Claim

用来申明它将从PV或者Storage Class资源里获取某个存储大小的空间。例如下面这个Pod中申明volume的例子，它很好的将Pod与存储底层实现隔离了，这个时候，如果更换底层存储对于Pod是无感知的。
另外PVC是有使用者创建与Pod一起使用的所以是和namespace密切关联
，它是必须属于某个namespace的

这里有个需要注意的问题，我们使用PVC的时候，什么时候需要通过关联PV直接使用，什么时候通过Storage Class呢？主要场景如下：

• 如果需要在多个Pod*享一个PV，则可以使用PVC绑定PV的方式。一个比较典型的场景是运行一个高可靠的Jenkins Master集群
• 如果需要每个Pod有个新的PV，则需要使用Storage Class的方式动态创建新的PV，这种主要用于类似数据库等场景。

小结

大家只要读懂上面这个彩色的关系图，基本就能掌握如何使用这些存储相关的概念了。

如需更加简便的在容器里使用存储，欢迎尝试使用阿里云的容器服务。目前容器服务已经服务超过3000+的客户生产运行。