地铁上突然想起，如果累积大小超过 k8s 的 persistent volume 大小，pod 会怎么样？
10 条回复 2019-11-15 11:19:07 +08:00
 | 1 ifaii 2019-05-01 10:13:51 +08:00  1 大小是由底层存储类型控制的，并不是 k8s 里面声明的，超过后只要底层卷没满就可以继续写 |
 | 2 henrywangx OP @ifaii 那 k8s 声明的大小意义何在呢？ |
| 3 ifaii 2019-05-01 11:08:38 +08:00 @henrywangx #2 以我的理解经验是在使用 storageclass 动态创建 pvc 时声明需要创建的大小，这时候底层存储就分配给你这么大的一个卷 |
 | 4 iwishing 2019-05-01 12:20:34 +08:00 https://github.com/kubernetes/kubernetes/issues/48701 this is working as intended, kube can't/won't enforce the capacity of PVs, the capacity field on PVs is just a label. It's up to the "administrator" i.e. the creator of the PV to label it accurately so that when users create PVCs that needs >= X Gi, they get what they want. For a hostPath PV, assigning a capacity may be difficult when the user can use as much free space as there is at that host path, but for e.g. EBS you can of course make capacity match the actual disk size. 声明的意义在于 pvc 去匹配 pv （手动狗头） |
 | 5 artandlol 2019-05-01 13:17:47 +08:00 via iPhone 这问题有点傻傻的，满了，pod 自然就挂了 |
| 6 henrywangx OP @artandlol sorry，事实上并没有挂掉...我没找到官方详细的描述，所以求问... |
| 7 henrywangx OP @iwishing 谢谢指教，我会再去看看文档和代码 |
 | 8 kaneg 2019-05-01 18:15:20 +08:00 via iPhone 对一般存储来说 kubernetes 根本不知道你的 PV 实际占用多大空间，只要你底层存储不会因为空间爆掉而出问题就行 |
 | 9 lingduhuanbing 2019-11-15 09:40:38 +08:00 确实不会爆掉，这个设定确实很奇怪。K8S 还提供了 PVC 扩容，如果还是根据底层存储的实际容量来，那直接扩底层存储就好了，为啥还要扩 PVC ？ |
| 10 henrywangx OP @lingduhuanbing 这个就是个标签啦，可能最开始就是为公有云服务的，而且最近理解，k8s 就是 platform for platform，这些标签的背后行为还是由 devops 自己去管理 |
Select Language