kubernets之pv以及pvc

一 持久卷以及持久卷声明的由来

　　由于不管是哪种卷，开发者都需要提前预知kubernets集群里面的存储类型，这样就在一定程度上违背了kubernets集群的设计理念，kubernets的设计理念是在由开发者任意使用集群的

资源的基础下，又不需要关注集群的底部的基础设施，甚至可以在各个集群下面任意迁移资源，基于这些kubernets提出了2个新的资源，持久卷(pv)以及pvc(持久卷声明)，研发人员无须向它们的

pod中添加特定技术的卷，而是由k8s集群管理员设置底层存储，然后通过k8sapi创建持久卷并进行注册，在创建持久卷的时候，管理员指定卷的大小以及访问模式，当研发人员需要使用持久化存储的

时候，只需要向api服务器发起申请并指定卷的大小以及访问模式，之后由kubernets的api服务器匹配卷并进行相绑定它们之间的关系以及作用如下面图所示

• 管理员创建 某个类型的网络存储
• 然后管理员通过向k8s的api服务器传递pv申明来创建持久
• 研发人员根据自己的业务需求向k8s的api发起pvc匹配系统中的pv申请
• 之后k8s集群api匹配到满足的pv和，将pv和研发人员的pvc进行绑定
• 研发人员就可以使用这个持久化存储

二 进行相关的资源创建演示

　　2.1  第一步需要创建持久卷　

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ex-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  gcePersistentDisk: 
    pdName: ex-pv 
    fsType: ext4

• capation定义的是pv的大小
• accessmodes的意思是可以被单个客户端挂载为读写模式或者被多个客户端挂载为只读模式
• persistentVolumeReclaimPolicy: Retain的意思是当声明被释放时候的pv的策略为被保留(不清理和删除)
• gcePersistentDisk指定之前创建的GCE持久磁盘

　　

　　2.2  说明一点持久卷不属于任何一个命名空间，它和node一样属于系统资源

• 由图可知，存储卷声明是用户创建属于某个命名空间
• 存储卷它是独立于任何一个命名空间的一种资源，不属于任何命名空间

　　2.3  接下来我们来创建一个持久卷声明

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ex-pvc
spec:
  resources:
    requests:
      storage: 1Gi
   accessModes:
   - ReadWriteOnce
   storageClassName: ""
    

• resource下面的数据表明存储卷声明的大小
• accessModes 表示存储卷声明需要的访问模式

　　

　　2.4  当创建好这个声明之后，k8s会找到合适持久化的卷将其绑定到这个pvc，持久化的卷容量必须满足持久卷声明的容量大小，并且支持pvc的访问模式

由于这个pvc的条件前面创建的都满足，所以系统会将这个pvc绑定到pv上面来，下面列举出pv以及pvc常见的几种访问模式

• RWO——ReadWriteOnly——仅允许单个节点挂载读写
• ROX——ReadOnlyMany——允许多个节点挂载读写
• RWX——ReadWriteMany——允许多个节点挂载读写

　　2.5 创建一个pod来引用pvc从而对pod中的数据进行持久化存储到pv中

apiVersion: v1
kind: pod
metadata:
  name: ex-pod-pvc
spec:
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mouthPath: /data/db
    ports:
    - containerPort: 27017
       protocol: TCP
  volumes:
  - name: mongodb-data
    persistentVolumeClaim:
      claimName: mongodb-pvc

• 一点声明，pod中是通过引用pvc来引用与pvc绑定的pv
• 需要注意的是，pvc不是在pod中创建而随之创建，而是pod创建完成之后对其进行引用

　

　　2.5 了解使用pv以及pvc的好处

• 从图中可以看出，如果直接用pod来关联持久卷反而更简单点
• 但是中间加了个持久卷声明之后，研发人员将不在需要关注底层实际的存储技术
• 换言之，研发人员只需要根据pod需要的存储大小以及访问模式来引用声明
• 还有个好处是，甚至一份pod可以在很多的不同的底层存储的应用

　　2.6 了解pv的回收机制

　　2.6.1 手动回收持久卷

　　根据上面我们创建的pv，pvc以及pod将它们进行关联，但是我们在删除pod，以及pvc之后，pv的状态将会如何，聪明的你应该会

会想起我们对pv的回收策略设置的为Retain,该种策略下，当与其绑定的pvc被删除之后，该pv无法被其他能够与之匹配的pvc引用，如果需要重新利用

那么唯一的办法是删除和重新创建持久化资源，如果这么操作的话，你还必须考虑一个问题是，如何处理底层存储的文件

　　

　　2.6.2 自动回收持久卷

　　当然除了我们已经用到的回收策略Retain之外，还有Recycle和Delete的回收策略

• Recycle——删除卷的内容并可以使其再次用于绑定其他声明
• Delete——彻底删除底层存储
• 注意一点的是：是否能够使用这些策略，需要看底层存储类型是否支持