问题
目前阿里云的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+的客户生产运行。