（10.2）Kubernetes之PV&PVC

最新推荐文章于 2024-04-09 07:30:00 发布

^果然好^

最新推荐文章于 2024-04-09 07:30:00 发布

阅读量921

点赞数

分类专栏： # kubernetes

本文链接：https://blog.csdn.net/allensandy/article/details/103499581

版权

kubernetes 专栏收录该内容

25 篇文章 0 订阅

订阅专栏

第一部分

Volume提供了非常好的数据持久化方案，不过在可管理性上还有不足：

Pod通常是由应用的开发人员维护，而Volume则通常是由存储系统的管理员维护。开发人员要获得上面的信息，要么询问管理员，要么自己就是管理员。这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境，这样的情况还可以接受，当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。

Kubemetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。

PersistentVolume (PV)是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV具有持久性，生命周期独立于Pod。

PersistentVolumeClaim (PVC)是对PV的申请(Claim)。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时，用户可以创建一个PVC,指明存储资源的容量大小和访问模式(比如只读)等信息，Kubemetes会查找并提供满足条件的PV。

有了 PersistentVolumeClaim,用户只需要告诉Kubemetes需要什么样的存储资源，而不必关心真正的空间从哪里分配、如何访问等底层细节信息。这些Storage Provider的底层信息交给管理员来处理，只有管理员才应该关心创建PersistentVolume的细节信息。Kubemetes 支持多种类型的 PersistentVolume,比如 AWS EBS、Ceph、NFS 等。

NFS PV

作为准备工作，我们己经在k8s-master节点上搭建了一个NFS服务器。

下面创建一个PV mypvl,配置文件nfs-pvl.ym：

capacity指定PV的容量为1GB。
accessModes指定访问模式为ReadWriteOnce,支持的访问模式有3种：ReadWriteOnce 表示PV能以read-write模式mount到单个节点，ReadOnlyMany表示PV能以read-only 模式mount到多个节点,ReadWriteMany表示PV能以read-write模式mount到多个节点。
persistentVolumeReclaimPolicy指定当PV的回收策略为Recycle,支持的策略有3种： Retain表示需要管理员手工回收；Recycle表示清除PV中的数据，效果相当于执行rm -rf /thevolume/*； Delete 表示删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、 Azure Disk> OpenStack Cinder Volume 等。
storageClassName指定PV的class为nfs。相当于为PV设置了一个分类，PVC可以指定class申请相应class的PV。
指定PV在NFS服务器上对应的目录。

创建mypvl：

STATUS为Available,表示mypvl就绪，可以被PVC申请。接下来创建PVC mypvcl,配置文件nfs.pvcl.yml:

PVC就很简单了，只需要指定PV的容量、访问模式和class即可。创建mypvcl:

从kubectl get pvc和kubectl get pv的输出可以看到mypvcl已经Bound到mypvl,申请成功。

第二部分

注意：

PV必须先与POD创建
PV和PVC中的spec关键字段要匹配，比如存储（storage）大小。
PV和PVC中的storageClassName字段必须一致
本地持久化存储

就是把数据存储在POD运行的宿主机上，我们知道宿主机有hostPath和emptyDir，由于这两种的特定不适用于本地持久化存储。那么本地持久化存储必须能保证POD被调度到具有本地持久化存储的节点上。为什么需要这种类型的存储呢？有时候你的应用对磁盘IO有很高的要求，网络存储性能肯定不如本地的高，尤其是本地使用了SSD这种磁盘。

5.kubernetes本身支持的动态PV创建不包括nfs，所以需要使用额外插件实现。nfs-client

按照网站的例子来创建（参考nfs-client），里面的内容毫无修改，当然你需要自己准备NFS服务器。由于用于提供动态创建PV的程序是运行在POD中，所以你需要保证你的Kubernetes节点到NFS的网络通畅，我这里就在我的Kubernetes集群的某个节点上建立的NFS服务。

补充：

第三部分

PV中的节点亲和（就是POD不管在哪个node，PV的存储据顶到固定的node）

通常我们先创建PV，然后创建PVC，这时候如果两者匹配那么系统会自动进行绑定，哪怕是动态PV创建，也是先调度POD到任意一个节点，然后根据PVC来进行创建PV然后进行绑定最后挂载到POD中，可是本地持久化存储有一个问题就是这种PV必须要先准备好，而且不一定集群所有节点都有这种PV，如果POD随意调度肯定不行，如何保证POD一定会被调度到有PV的节点上呢？这时候就需要在PV中声明节点亲和，且POD被调度的时候还要考虑卷的分布情况。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local: # local类型
    path: /data/vol1  # 节点上的具体路径
  nodeAffinity: # 这里就设置了节点亲和
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node01 # 这里我们使用node01节点，该节点有/data/vol1路径

如果你在node02上也有/data/vol1这个目录，上面这个PV也一定不会在node02上，因为下面的nodeAffinity设置了主机名就等于node01。

第四部分

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

这里的volumeBindingMode: WaitForFirstConsumer很关键，意思就是延迟绑定，当有符合PVC要求的PV不立即绑定。因为POD使用PVC，而绑定之后，POD被调度到其他节点，显然其他节点很有可能没有那个PV所以POD就挂起了，另外就算该节点有合适的PV，而POD被设置成不能运行在该节点，这时候就没法了，延迟绑定的好处是，POD的调度要参考卷的分布。当开始调度POD的时候看看它要求的LPV（本地卷）在哪里，然后就调度到该节点，然后进行PVC的绑定，最后在挂载到POD中，这样就保证了POD所在的节点就一定是LPV（本地卷）所在的节点。所以让PVC延迟绑定，就是等到使用这个PVC的POD出现在调度器上之后（真正被调度之前），然后根据综合评估再来绑定这个PVC。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: local-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-storage

可以看到这个PVC是pending状态，这也就是延迟绑定，因为此时还没有POD。

定义POD

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      appname: myapp
  template:
    metadata:
      name: myapp
      labels:
        appname: myapp
    spec:
      containers:
      - name: myapp
        image: tomcat:8.5.38-jre8
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        volumeMounts:
          - name: tomcatedata
            mountPath : "/data"
      volumes:
        - name: tomcatedata
          persistentVolumeClaim:
            claimName: local-claim

这个POD被调度到node01上，因为我们的PV就在node01上，这时候你删除这个POD，然后在重建该POD，那么依然会被调度到node01上。

总结：本地卷也就是LPV不支持动态供给的方式，延迟绑定，就是为了综合考虑所有因素再进行POD调度。其根本原因是动态供给是先调度POD到节点，然后动态创建PV以及绑定PVC最后运行POD；而LPV是先创建与某一节点关联的PV，然后在调度的时候综合考虑各种因素而且要包括PV在哪个节点，然后再进行调度，到达该节点后在进行PVC的绑定。也就说动态供给不考虑节点，LPV必须考虑节点。所以这两种机制有冲突导致无法在动态供给策略下使用LPV。换句话说动态供给是PV跟着POD走，而LPV是POD跟着PV走。

以上参考：https://blog.csdn.net/weixin_30433075/article/details/94924330

第五部分

PVC注意点,PV 和PVC怎么关联的？

^果然好^

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
（10.2）Kubernetes之PV&PVC

Volume提供了非常好的数据持久化方案，不过在可管理性上还有不足：Pod通常是由应用的开发人员维护，而Volume则通常是由存储系统的管理员维护。开发人员要获得上面的信息，要么询问管理员，要么自己就是管理员。这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境，这样的情况还可以接受，当集群规模变大，特别是对于生成环境，考虑到效率和安全...
复制链接

扫一扫