29 | PV、PVC体系是不是多此一举？从本地持久化卷谈起

Oct 29, 2018

29 | PV、PVC体系是不是多此一举？从本地持久化卷谈起-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

29 | PV、PVC体系是不是多此一举？从本地持久化卷谈起

2018-10-29 张磊来自北京

《深入剖析Kubernetes》

课程介绍



讲述：张磊

时长15:45大小7.21M



你好，我是张磊。今天我和你分享的主题是：PV、PVC 体系是不是多此一举？从本地持久化卷谈起。
在上一篇文章中，我为你详细讲解了 PV、PVC 持久化存储体系在 Kubernetes 项目中的设计和实现原理。而在文章最后的思考题中，我为你留下了这样一个讨论话题：像 PV、PVC 这样的用法，是不是有“过度设计”的嫌疑？
比如，我们公司的运维人员可以像往常一样维护一套 NFS 或者 Ceph 服务器，根本不必学习 Kubernetes。而开发人员，则完全可以靠“复制粘贴”的方式，在 Pod 的 YAML 文件里填上 Volumes 字段，而不需要去使用 PV 和 PVC。
实际上，如果只是为了职责划分，PV、PVC 体系确实不见得比直接在 Pod 里声明 Volumes 字段有什么优势。
不过，你有没有想过这样一个问题，如果Kubernetes 内置的 20 种持久化数据卷实现，都没办法满足你的容器存储需求时，该怎么办？
这个情况乍一听起来有点不可思议。但实际上，凡是鼓捣过开源项目的读者应该都有所体会，“不能用”“不好用”“需要定制开发”，这才是落地开源基础设施项目的三大常态。
而在持久化存储领域，用户呼声最高的定制化需求，莫过于支持“本地”持久化存储了。
也就是说，用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器 Volume。
这样做的好处很明显，由于这个 Volume 直接使用的是本地磁盘，尤其是 SSD 盘，它的读写性能相比于大多数远程存储来说，要好得多。这个需求对本地物理服务器部署的私有 Kubernetes 集群来说，非常常见。
所以，Kubernetes 在 v1.10 之后，就逐渐依靠 PV、PVC 体系实现了这个特性。这个特性的名字叫作：Local Persistent Volume。
不过，首先需要明确的是，Local Persistent Volume 并不适用于所有应用。事实上，它的适用范围非常固定，比如：高优先级的系统应用，需要在多个不同节点上存储数据，并且对 I/O 较为敏感。典型的应用包括：分布式数据存储比如 MongoDB、Cassandra 等，分布式文件系统比如 GlusterFS、Ceph 等，以及需要在本地磁盘上进行大量数据缓存的分布式应用。
其次，相比于正常的 PV，一旦这些节点宕机且不能恢复时，Local Persistent Volume 的数据就可能丢失。这就要求使用 Local Persistent Volume 的应用必须具备数据备份和恢复的能力，允许你把这些数据定时备份在其他位置。
接下来，我就为你深入讲解一下这个特性。
不难想象，Local Persistent Volume 的设计，主要面临两个难点。
第一个难点在于：如何把本地磁盘抽象成 PV。
可能你会说，Local Persistent Volume，不就等同于 hostPath 加 NodeAffinity 吗？
比如，一个 Pod 可以声明使用类型为 Local 的 PV，而这个 PV 其实就是一个 hostPath 类型的 Volume。如果这个 hostPath 对应的目录，已经在节点 A 上被事先创建好了。那么，我只需要再给这个 Pod 加上一个 nodeAffinity=nodeA，不就可以使用这个 Volume 了吗？
事实上，你绝不应该把一个宿主机上的目录当作 PV 使用。这是因为，这种本地目录的存储行为完全不可控，它所在的磁盘随时都可能被应用写满，甚至造成整个宿主机宕机。而且，不同的本地目录之间也缺乏哪怕最基础的 I/O 隔离机制。
所以，一个 Local Persistent Volume 对应的存储介质，一定是一块额外挂载在宿主机的磁盘或者块设备（“额外”的意思是，它不应该是宿主机根目录所使用的主硬盘）。这个原则，我们可以称为“一个 PV 一块盘”。
第二个难点在于：调度器如何保证 Pod 始终能被正确地调度到它所请求的 Local Persistent Volume 所在的节点上呢？
造成这个问题的原因在于，对于常规的 PV 来说，Kubernetes 都是先调度 Pod 到某个节点上，然后，再通过“两阶段处理”来“持久化”这台机器上的 Volume 目录，进而完成 Volume 目录与容器的绑定挂载。
可是，对于 Local PV 来说，节点上可供使用的磁盘（或者块设备），必须是运维人员提前准备好的。它们在不同节点上的挂载情况可以完全不同，甚至有的节点可以没这种磁盘。
所以，这时候，调度器就必须能够知道所有节点与 Local Persistent Volume 对应的磁盘的关联关系，然后根据这个信息来调度 Pod。
这个原则，我们可以称为“在调度的时候考虑 Volume 分布”。在 Kubernetes 的调度器里，有一个叫作 VolumeBindingChecker 的过滤条件专门负责这个事情。在 Kubernetes v1.11 中，这个过滤条件已经默认开启了。
基于上述讲述，在开始使用 Local Persistent Volume 之前，你首先需要在集群里配置好磁盘或者块设备。在公有云上，这个操作等同于给虚拟机额外挂载一个磁盘，比如 GCE 的 Local SSD 类型的磁盘就是一个典型例子。
而在我们部署的私有环境中，你有两种办法来完成这个步骤。
第一种，当然就是给你的宿主机挂载并格式化一个可用的本地磁盘，这也是最常规的操作；
第二种，对于实验环境，你其实可以在宿主机上挂载几个 RAM Disk（内存盘）来模拟本地磁盘。
接下来，我会使用第二种方法，在我们之前部署的 Kubernetes 集群上进行实践。
首先，在名叫 node-1 的宿主机上创建一个挂载点，比如 /mnt/disks；然后，用几个 RAM Disk 来模拟本地磁盘，如下所示：
# 在node-1上执行
$ mkdir /mnt/disks
$ for vol in vol1 vol2 vol3; do
    mkdir /mnt/disks/$vol
    mount -t tmpfs $vol /mnt/disks/$vol
done
需要注意的是，如果你希望其他节点也能支持 Local Persistent Volume 的话，那就需要为它们也执行上述操作，并且确保这些磁盘的名字（vol1、vol2 等）都不重复。
接下来，我们就可以为这些本地磁盘定义对应的 PV 了，如下所示：
apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/vol1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node-1
可以看到，这个 PV 的定义里：local 字段，指定了它是一个 Local Persistent Volume；而 path 字段，指定的正是这个 PV 对应的本地磁盘的路径，即：/mnt/disks/vol1。
当然了，这也就意味着如果 Pod 要想使用这个 PV，那它就必须运行在 node-1 上。所以，在这个 PV 的定义里，需要有一个 nodeAffinity 字段指定 node-1 这个节点的名字。这样，调度器在调度 Pod 的时候，就能够知道一个 PV 与节点的对应关系，从而做出正确的选择。这正是 Kubernetes 实现“在调度的时候就考虑 Volume 分布”的主要方法。
接下来，我们就可以使用 kubect create 来创建这个 PV，如下所示：
$ kubectl create -f local-pv.yaml 
persistentvolume/example-pv created
$ kubectl get pv
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY  STATUS      CLAIM             STORAGECLASS    REASON    AGE
example-pv   5Gi        RWO            Delete           Available                     local-storage             16s
可以看到，这个 PV 创建后，进入了 Available（可用）状态。
而正如我在上一篇文章里所建议的那样，使用 PV 和 PVC 的最佳实践，是你要创建一个 StorageClass 来描述这个 PV，如下所示：
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
这个 StorageClass 的名字，叫作 local-storage。需要注意的是，在它的 provisioner 字段，我们指定的是 no-provisioner。这是因为 Local Persistent Volume 目前尚不支持 Dynamic Provisioning，所以它没办法在用户创建 PVC 的时候，就自动创建出对应的 PV。也就是说，我们前面创建 PV 的操作，是不可以省略的。
与此同时，这个 StorageClass 还定义了一个 volumeBindingMode=WaitForFirstConsumer 的属性。它是 Local Persistent Volume 里一个非常重要的特性，即：延迟绑定。
我们知道，当你提交了 PV 和 PVC 的 YAML 文件之后，Kubernetes 就会根据它们俩的属性，以及它们指定的 StorageClass 来进行绑定。只有绑定成功后，Pod 才能通过声明这个 PVC 来使用对应的 PV。
可是，如果你使用的是 Local Persistent Volume 的话，就会发现，这个流程根本行不通。
比如，现在你有一个 Pod，它声明使用的 PVC 叫作 pvc-1。并且，我们规定，这个 Pod 只能运行在 node-2 上。
而在 Kubernetes 集群中，有两个属性（比如：大小、读写权限）相同的 Local 类型的 PV。
其中，第一个 PV 的名字叫作 pv-1，它对应的磁盘所在的节点是 node-1。而第二个 PV 的名字叫作 pv-2，它对应的磁盘所在的节点是 node-2。
假设现在，Kubernetes 的 Volume 控制循环里，首先检查到了 pvc-1 和 pv-1 的属性是匹配的，于是就将它们俩绑定在一起。
然后，你用 kubectl create 创建了这个 Pod。
这时候，问题就出现了。
调度器看到，这个 Pod 所声明的 pvc-1 已经绑定了 pv-1，而 pv-1 所在的节点是 node-1，根据“调度器必须在调度的时候考虑 Volume 分布”的原则，这个 Pod 自然会被调度到 node-1 上。
可是，我们前面已经规定过，这个 Pod 根本不允许运行在 node-1 上。所以。最后的结果就是，这个 Pod 的调度必然会失败。
这就是为什么，在使用 Local Persistent Volume 的时候，我们必须想办法推迟这个“绑定”操作。
那么，具体推迟到什么时候呢？
答案是：推迟到调度的时候。
所以说，StorageClass 里的 volumeBindingMode=WaitForFirstConsumer 的含义，就是告诉 Kubernetes 里的 Volume 控制循环（“红娘”）：虽然你已经发现这个 StorageClass 关联的 PVC 与 PV 可以绑定在一起，但请不要现在就执行绑定操作（即：设置 PVC 的 VolumeName 字段）。
而要等到第一个声明使用该 PVC 的 Pod 出现在调度器之后，调度器再综合考虑所有的调度规则，当然也包括每个 PV 所在的节点位置，来统一决定，这个 Pod 声明的 PVC，到底应该跟哪个 PV 进行绑定。
这样，在上面的例子里，由于这个 Pod 不允许运行在 pv-1 所在的节点 node-1，所以它的 PVC 最后会跟 pv-2 绑定，并且 Pod 也会被调度到 node-2 上。
所以，通过这个延迟绑定机制，原本实时发生的 PVC 和 PV 的绑定过程，就被延迟到了 Pod 第一次调度的时候在调度器中进行，从而保证了这个绑定结果不会影响 Pod 的正常调度。
当然，在具体实现中，调度器实际上维护了一个与 Volume Controller 类似的控制循环，专门负责为那些声明了“延迟绑定”的 PV 和 PVC 进行绑定工作。
通过这样的设计，这个额外的绑定操作，并不会拖慢调度器的性能。而当一个 Pod 的 PVC 尚未完成绑定时，调度器也不会等待，而是会直接把这个 Pod 重新放回到待调度队列，等到下一个调度周期再做处理。
在明白了这个机制之后，我们就可以创建 StorageClass 了，如下所示：
$ kubectl create -f local-sc.yaml 
storageclass.storage.k8s.io/local-storage created
接下来，我们只需要定义一个非常普通的 PVC，就可以让 Pod 使用到上面定义好的 Local Persistent Volume 了，如下所示：
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: example-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-storage
可以看到，这个 PVC 没有任何特别的地方。唯一需要注意的是，它声明的 storageClassName 是 local-storage。所以，将来 Kubernetes 的 Volume Controller 看到这个 PVC 的时候，不会为它进行绑定操作。
现在，我们来创建这个 PVC：
$ kubectl create -f local-pvc.yaml 
persistentvolumeclaim/example-local-claim created
$ kubectl get pvc
NAME                  STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS    AGE
example-local-claim   Pending                                       local-storage   7s
可以看到，尽管这个时候，Kubernetes 里已经存在了一个可以与 PVC 匹配的 PV，但这个 PVC 依然处于 Pending 状态，也就是等待绑定的状态。
然后，我们编写一个 Pod 来声明使用这个 PVC，如下所示：
kind: Pod
apiVersion: v1
metadata:
  name: example-pv-pod
spec:
  volumes:
    - name: example-pv-storage
      persistentVolumeClaim:
       claimName: example-local-claim
  containers:
    - name: example-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: example-pv-storage
这个 Pod 没有任何特别的地方，你只需要注意，它的 volumes 字段声明要使用前面定义的、名叫 example-local-claim 的 PVC 即可。
而我们一旦使用 kubectl create 创建这个 Pod，就会发现，我们前面定义的 PVC，会立刻变成 Bound 状态，与前面定义的 PV 绑定在了一起，如下所示：
$ kubectl create -f local-pod.yaml 
pod/example-pv-pod created
$ kubectl get pvc
NAME                  STATUS    VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS    AGE
example-local-claim   Bound     example-pv   5Gi        RWO            local-storage   6h
也就是说，在我们创建的 Pod 进入调度器之后，“绑定”操作才开始进行。
这时候，我们可以尝试在这个 Pod 的 Volume 目录里，创建一个测试文件，比如：
$ kubectl exec -it example-pv-pod -- /bin/sh
# cd /usr/share/nginx/html
# touch test.txt
然后，登录到 node-1 这台机器上，查看一下它的 /mnt/disks/vol1 目录下的内容，你就可以看到刚刚创建的这个文件：
# 在node-1上
$ ls /mnt/disks/vol1
test.txt
而如果你重新创建这个 Pod 的话，就会发现，我们之前创建的测试文件，依然被保存在这个持久化 Volume 当中：
$ kubectl delete -f local-pod.yaml 
$ kubectl create -f local-pod.yaml 
$ kubectl exec -it example-pv-pod -- /bin/sh
# ls /usr/share/nginx/html
# touch test.txt
这就说明，像 Kubernetes 这样构建出来的、基于本地存储的 Volume，完全可以提供容器持久化存储的功能。所以，像 StatefulSet 这样的有状态编排工具，也完全可以通过声明 Local 类型的 PV 和 PVC，来管理应用的存储状态。
需要注意的是，我们上面手动创建 PV 的方式，即 Static 的 PV 管理方式，在删除 PV 时需要按如下流程执行操作：
删除使用这个 PV 的 Pod；
从宿主机移除本地磁盘（比如，umount 它）；
删除 PVC；
删除 PV。
如果不按照这个流程的话，这个 PV 的删除就会失败。
当然，由于上面这些创建 PV 和删除 PV 的操作比较繁琐，Kubernetes 其实提供了一个 Static Provisioner 来帮助你管理这些 PV。
比如，我们现在的所有磁盘，都挂载在宿主机的 /mnt/disks 目录下。
那么，当 Static Provisioner 启动后，它就会通过 DaemonSet，自动检查每个宿主机的 /mnt/disks 目录。然后，调用 Kubernetes API，为这些目录下面的每一个挂载，创建一个对应的 PV 对象出来。这些自动创建的 PV，如下所示：
$ kubectl get pv
NAME                CAPACITY    ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS    REASON    AGE
local-pv-ce05be60   1024220Ki   RWO           Delete          Available             local-storage             26s
$ kubectl describe pv local-pv-ce05be60 
Name:  local-pv-ce05be60
...
StorageClass: local-storage
Status:  Available
Claim:  
Reclaim Policy: Delete
Access Modes: RWO
Capacity: 1024220Ki
NodeAffinity:
  Required Terms:
      Term 0:  kubernetes.io/hostname in [node-1]
Message: 
Source:
    Type: LocalVolume (a persistent volume backed by local storage on a node)
    Path: /mnt/disks/vol1
这个 PV 里的各种定义，比如 StorageClass 的名字、本地磁盘挂载点的位置，都可以通过 provisioner 的配置文件指定。当然，provisioner 也会负责前面提到的 PV 的删除工作。
而这个 provisioner 本身，其实也是一个我们前面提到过的External Provisioner，它的部署方法，在对应的文档里有详细描述。这部分内容，就留给你课后自行探索了。
总结在今天这篇文章中，我为你详细介绍了 Kubernetes 里 Local Persistent Volume 的实现方式。
可以看到，正是通过 PV 和 PVC，以及 StorageClass 这套存储体系，这个后来新添加的持久化存储方案，对 Kubernetes 已有用户的影响，几乎可以忽略不计。作为用户，你的 Pod 的 YAML 和 PVC 的 YAML，并没有任何特殊的改变，这个特性所有的实现只会影响到 PV 的处理，也就是由运维人员负责的那部分工作。
而这，正是这套存储体系带来的“解耦”的好处。
其实，Kubernetes 很多看起来比较“繁琐”的设计（比如“声明式 API”，以及我今天讲解的“PV、PVC 体系”）的主要目的，都是希望为开发者提供更多的“可扩展性”，给使用者带来更多的“稳定性”和“安全感”。这两个能力的高低，是衡量开源基础设施项目水平的重要标准。
思考题正是由于需要使用“延迟绑定”这个特性，Local Persistent Volume 目前还不能支持 Dynamic Provisioning。你是否能说出，为什么“延迟绑定”会跟 Dynamic Provisioning 有冲突呢？
感谢你的收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 43

提建议

28 | PV、PVC、StorageClass，这些到底在说啥？

30 | 编写自己的存储插件：FlexVolume与CSI

 写留言

精选留言(39)

realc
2018-10-29
知其然，知其所以然。很多教程教材，就跟上学时学校直接灌给我们一样，要让我们去硬啃。不如老师这课程，一个知识点，一个功能的来龙去脉、前世今生都给讲的清清楚楚的。
71
虎虎❤️
2018-10-29
思考题，我的理解：因为当一个pvc创建之后，kubernetes因为dynamic provisioning机制会调用pvc指定的storageclass里的provisioner自动使用local disk的信息去创建pv。而且pv一旦创建，nodeaffinity参数就指定了固定的node。而此时，provisioner并没有pod调度的相关信息。延迟绑定发生的时机是pod已经进入调度器。此时对应的pv已经创建，绑定了node。并可能与pod的调度信息发生冲突。如果dynamic provisioning机制能够推迟到pod 调度的阶段，同时考虑pod调度条件和node硬件信息，这样才能实现dynamic provisioning。实现上可以参考延迟绑定，来一个延迟 provision。另外实现一个controller在pod调度阶段创建pv。
展开
共 3 条评论
60
xfan
2019-01-23
思考题：因为dynamic provision机制不知道pod需要在哪个node下运行，而提前就创建好了，，
14
张三
2020-05-12
Dynamic Provisioning 提供的是自动创建PV的机制，会根据PVC来创建PV并绑定，而我们的延迟绑定是需要在调度的时候综合考虑所有的调度条件来进行PVC和PV的绑定并调度Pod到PV所在的节点，二者有冲突
6
拉欧
2019-11-16
Dynamic Provisioning 是通过pvc 创建指定规格的pv, 而Local Persistent Volume 是先创建pv, 在创建pvc, 然后在pod创建的时候绑定pv和pvc；从语义上讲，Dynamic Provisioning 就不太可能支持延迟这种效果
4
djfhchdh
2019-11-13
因为Dynamic Provisioning会自动创建PV，也就是说，在PVC创建后就根据StorageClass去自动创建PV并绑定了，而“延迟绑定”发生在调度Pod时，此时PVC已经创建了。因此二者是矛盾的~~
4
大星星
2019-03-14
手动删除pv的步骤中，1234步骤，为什么不是1342呢
共 1 条评论
3
海。
2020-07-10
如果不是Local Persistent Volume，而使用云块存储 aws ebs ， “延迟绑定”和 Dynamic Provisioning 可以不冲突吧？我看https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/dynamic-provisioning/specs/storageclass.yaml 的volumeBindingMode也是 WaitForFirstConsumer
共 3 条评论
2
johnson.skiii
2018-12-09
liuchjlu 请教一个问题，当使用Local Persistent Volume的时候，pv中声明的local path如果所在节点没有这个目录会不会自动创建？我的理解是：pv无论是使用NAS或者其他的存储，还是local persistent volume，都是infra的童鞋帮忙先规划好的存储区域。那么你在写这个pv的时候，要确保这块存储可用，比如目录存在。
展开
共 2 条评论
1
liuchjlu
2018-11-03
请教一个问题，当使用Local Persistent Volume的时候，pv中声明的local path如果所在节点没有这个目录会不会自动创建？
共 1 条评论
1
silver
2018-10-30
'一个 PV 一块盘'能再解释下么，如果直接写宿主机上的本地磁盘目录只要把每个container所消耗的硬盘空间都加个cap就能防止磁盘被写满吧？
共 1 条评论
1
Geek_a852c8
2022-09-27 来自广东
[root@VM-20-5-centos test1]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE example-pv 1Gi RWO Delete Failed default/example-local-claim local-storage 81s 绑定了pvc后的pv。如果删除了pvc后。状态变成failed.那怎么才能让他变回Available呢？
展开
阿喵
2022-08-12 来自上海
思考题：假设现在有node1和node2两个节点，且pod因为某些原因只能运行在node2节点上，而dynamic provisioning在pvc创建之后就自动创建pv与其绑定，此时并不会考虑pod的调度情况，假设这个pv被创建在node1节点上，那么pod必然调度失败
阿伦
2022-05-13
有一点疑惑，重启的pod，是如何保证自己一定启动在之前关联的PV机器上的，上面的例子说pod只能运行在2节点上，那如果没有这个限制，被部署在了1机器上，然后写了数据之后，pod重启，运行到2机器上了，那1机器上的PV有数据持久化又有什么意义呢？
要没时间了
2022-04-25
Dynamic Provisioning 这个机制，关键是在于，如果它最终的结果是仅有一个合法的PV以及底层的持久化目录，这就反向影响了Pod Schduling的决定，相当于可被调度的候选节点只有一个了。要不然，就在多个，甚至集群全部节点都创建好相应的local PV。这样可以一定程度，或者彻底消除调度失败的可能。否则，就只能在volume创建的时候想办法，在scheduler里面实现相应的通过调用CSI 的API创建volume的逻辑。后者所谓的“动态创建”的方式，虽然可能，但是是不适合放在 scheduler里面的。scheduler按照责任划分来说，不应该再对资源进行修改了，以为她本身就是一个根据现有资源情况做调度决定的组件。通过上面的考虑，如果资源充足，那就在集群出划分出一个专门可以使用local volume的节点池，在上面每一个节点都创建相应的PV。否则，感觉是没办法解决这个冲突的
展开
loser
2022-04-11
只有几个G那种怎么挂载一个单盘呢？
勤奋的辣牛肉
2022-04-09
Static Provisioner 和 local-volume-provisioner 是一个东西么?
Lccc
2022-03-04
如果PVC支持扩展nodeAffinity字段, 是不是就可以解决延迟绑定了, StorageClass在读取到新增PVC后, 直接创建指定node的PV并进行Bound
共 1 条评论
恰同学少年。
2021-10-19
"需要注意的是，我们上面手动创建 PV 的方式，即 Static 的 PV 管理方式，在删除 PV 时需要按如下流程执行操作：删除使用这个 PV 的 Pod；从宿主机移除本地磁盘（比如，umount 它）；删除 PVC；删除 PV。" 请问这里为什么不按这个顺序就会失败？我在k8s环境实践了以下两种方式也可以删除成功。方案一：只不过这里可能的问题是在删除pv pvc的窗口期pod读写会有异常？ - 删除PV - 删除PVC - 删除Pod 方案二： - 删除PVC - 删除Pod - 删除PV
展开
wx
2021-07-21
思考题: 1. Static Provisioning 的pv 是提前创建好的，调度器在调度pod时，一方面可以考虑nodeAffinity等调度需求，另一方面也能通过已有pv信息知道 pv的空间够不够。所以pv绑定pvc 可以放在Pod调度后进行。 2. Dynamic Provisioning，最大的问题: 无法提前知道节点空间够不够。情况一: 如果让Pod先调度到节点上之后，再通过 storageClass 创建pv绑定pvc，很有可能节点本地磁盘空间都不够了。情况二: 如果先让 storageClass 创建pv绑定pvc，再调度Pod，pvc所在的节点信息和 Pod 需要的节点信息产生冲突。求老师给正确解答
展开

