Kubernetes持久化存储1——示例

目录贴:Kubernetes学习系列

一、简介

  存储管理与计算管理是两个不同的问题。Persistent Volume子系统,对存储的供应和使用做了抽象,以API形式提供给管理员和用户使用。要完成这一任务,我们引入了两个新的API资源:Persistent Volume(持久卷)和Persistent Volume Claim(持久卷消费者)。

  Persistent Volume(PV)是集群之中的一块网络存储。跟Node一样,也是集群的资源。PV跟Volume(卷)类似,不过会有独立于Pod的生命周期。这一API对象包含了存储的实现细节,例如NFS、iSCSI或者其他的云提供商的存储系统。Persistent Volume Claim(PVC)是用户的一个请求。跟Pod类似,Pod消费Node的资源,PVC消费PV的资源。Pod能够申请特定的资源(CPU和内存);Claim能够请求特定的尺寸和访问模式(例如可以加载一个读写,以及多个只读实例)。

二、PV和PVC的生命周期

  PV是集群的资源。PVC是对这一资源的请求,也是对资源的所有权的检验。PV和PVC之间的互动遵循如下的生命周期。

2.1 供应

  集群管理员会创建一系列的PV。这些PV包含了为集群用户提供的真实存储资源,它们可利用KubernetesAPI来消费。

2.2 绑定

  用户创建一个包含了容量和访问模式的持久卷申请。Master会监听PVC的产生,并尝试根据请求内容查找匹配的PV,并把PV和PVC进行绑定。用户能够获取满足需要的资源,并且在使用过程中可能超出请求数量。

  如果找不到合适的卷,这一申请就会持续处于非绑定状态,一直到出现合适的PV。例如一个集群准备了很多的50G大小的持久卷,(虽然总量足够)也是无法响应100G的申请的,除非把100G的PV加入集群。

2.3 使用

  Pod把申请作为卷来使用。集群会通过PVC查找绑定的PV,并Mount给Pod。对于支持多种访问方式的卷,用户在使用PVC作为卷的时候,可以指定需要的访问方式。

一旦用户拥有了一个已经绑定的PVC,被绑定的PV就归该用户所有了。用户的Pods能够通过在Pod的卷中包含的PVC来访问他们占有的PV。

2.4 释放

  当用户完成对卷的使用时,就可以利用API删除PVC对象了,而且他还可以重新申请。删除PVC后,对应的卷被视为“被释放”,但是这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中,要根据策略来进行后续处理。

2.5 回收

  PV的回收策略向集群阐述了在PVC释放卷的时候,应如何进行后续工作。目前可以采用三种策略:保留,回收或者删除。保留策略允许重新申请这一资源。在持久卷能够支持的情况下,删除策略会同时删除持久卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持,回收策略会执行基础的擦除操作(rm -rf /thevolume/*),这一卷就能被重新申请了。

三、持久卷PV

3.1 持久卷的类型

  持久卷是以插件方式实现的,目前支持如下插件:

  • GCEPersistentDisk
  • AWSElasticBlockStore
  • NFS
  • iSCSI
  • RBD (Ceph Block Device)
  • Glusterfs
  • HostPath (单节点测试使用)
  • 持久卷

 

3.2 持久卷定义

  每个 PV 包含一个 spec 以及 status ,用于描述该卷的规格和状态。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 5Gi 
  accessModes:
    - ReadWriteMany 
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: "/data/disk1"
    server: 192.168.20.47 
    readOnly: false

3.3 Capacity(容量)

  一般来说,PV会指定存储容量。这里需要使用PV的capcity属性。目前存储大小是唯一一个能够被申请的指标,今后会加入更多属性,例如IOPS,吞吐能力等。

3.4 AccessModes(访问模式)

  只要资源提供者支持,持久卷能够被用任何方式加载到主机上。每种存储都会有不同的能力,每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端,但是某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式,这些访问模式取决于PV的能力。访问模式的可选范围如下:

  • ReadWriteOnce:该卷能够以读写模式被加载到一个节点上。
  • ReadOnlyMany:该卷能够以只读模式加载到多个节点上。
  • ReadWriteMany:该卷能够以读写模式被多个节点同时加载。

在CLI下,访问模式缩写为:

  • RWO:ReadWriteOnce
  • ROX:ReadOnlyMany
  • RWX:ReadWriteMany

  另外,一个卷不论支持多少种访问模式,同时只能以一种访问模式加载。例如一个GCE Persistent Disk既能支持ReadWriteOnce,也能支持ReadOnlyMany。

3.5 RecyclingPolicy(回收策略)

  当前的回收策略可选值包括:

  • Retain,人工重新申请
  • Recycle,基础擦除(“rm-rf/thevolume/*”)
  • Delete,相关的存储资产例如AWS EBS,GCE PD或者OpenStack Cinder卷一并删除。

目前,只有NFS和HostPath支持Recycle策略,AWS EBS、GCE PD以及Cinder卷支持Delete策略。

3.6 阶段(Phase)

  一个卷会处于如下阶段之一:

  • Available:可用资源,尚未被绑定到PVC上
  • Bound:该卷已经被绑定
  • Released:PVC已经被删除,但该资源尚未被集群回收
  • Failed:该卷的自动回收过程失败。

四、PersistentVolumeClaims(持久卷消费者)

  每个 PVC 包含一个 spec 以及 status,用以表达其规格和状态。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
  - ReadWriteMany      
  resources:
     requests:
       storage: 1Gi

4.1 访问模式

  PVC使用跟PV一致的访问模式。

4.2 资源

  PVC跟Pod一样可以请求特定数量的资源。在这里的请求内容就是存储(storage)。ResourceModel文中提到的内容对PV和PVC同样适用。

4.3 使用PVC卷

  Pod能够借助PVC来访问存储。PVC必须跟Pod处于同一个命名空间。集群找到Pod命名空间中的PVC,然后利用PVC获取到背后的PV。这个卷就会被加载到主机上,让Pod可以使用。

[root@k8s-master pv]# cat test-pvc-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test-nfs-pvc
  labels:
    name: test-nfs-pvc
spec:
  containers:
    - name: test-nfs-pvc
      image: registry:5000/back_demon:1.0  
      ports:
        - name: backdemon
          containerPort: 80
      command:
        - /run.sh
      volumeMounts:
        - name: nfs-vol 
          mountPath: /home/laizy/test/nfs-pvc 
  volumes:
    - name: nfs-vol
      persistentVolumeClaim:
        claimName: nfs-pvc
[root@k8s-master pv]# kubectl exec -ti test-nfs-pvc /bin/bash
[root@test-nfs-pvc /]# cd /home/laizy/test/nfs-pvc/
[root@test-nfs-pvc nfs-pvc]# ls
1.out
[root@test-nfs-pvc nfs-pvc]# touch 2.out
[root@test-nfs-pvc nfs-pvc]# ls
1.out  2.out

在对应的远程NFS主机上看,可以看到刚刚在Pod内部生成的文件。

posted @ 2017-03-27 11:52  振宇要低调  阅读(5386)  评论(1编辑  收藏