问题
目前阿里云的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售尽，则试图创建普通云盘。
如果是通过界面绑定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+的客户生产运行。
