kubernetes 在pod中挂载的卷大小小于PVC中声明的大小,

izkcnapc  于 6个月前  发布在  Kubernetes
关注(0)|答案(8)|浏览(71)

发生了什么?

你好,
Pod中的挂载卷大小小于在PVC中声明的大小。
我不知道这是正常行为还是一个bug。
感谢你的帮助

你期望发生什么?

我期望当我执行它并查看路径/mypath/的df -h命令时,看到20Gi,但我只看到4Gi。

我们如何尽可能精确地重现它?

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ex1
  namespace: ns1
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
  storageClassName: ibmc-s3fs-standard-perf-regional
  volumeMode: Filesystem
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  namespace: ns01
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      volumeMode:
      - name: vol
        PersistentVolumeClaim:
          claimName: ex1
      containers:
      #
      #
        volumeMounts:
          - mountPath: /mypath/
            name: vol

我们需要了解其他信息吗?

  • 无响应*

Kubernetes版本

$ kubectl version
# paste output here

客户端版本:1.11
服务器版本:1.26

云提供商

IBM Cloud

OS版本

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Ubuntu 20

gab6jxml

gab6jxml1#

这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题,他们将通过应用triage/accepted标签并提供进一步的指导来接受它。
组织成员可以通过在评论中写入/triage accepted来添加triage/accepted标签。
有关使用PR评论与我互动的说明,请查看here。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。

44u64gxh

44u64gxh3#

我是否可以理解,你的Pod占用空间大小与PVC应用的大小不匹配?这可能是因为你没有使用它那么多,所以这是正常的。更具体地针对实现,你应该查看SC。

mv1qrgav

mv1qrgav4#

Yes it is that. Even when I add some files to the path, the used size is still to 0 Gi

xkrw2x1b

xkrw2x1b5#

好的,我会尝试复制你的问题。我的当前存储是本地存储,使用OpenEBS中的Local PV Hostpath,我的pod被分配给了Node1:

我的PVC是5G

k get pvc
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
local-hostpath-pvc   Bound    pvc-8a90cef2-7cde-4916-b351-3a1c3a66f635   5G         RWO            openebs-hostpath   2m24s

目前只有一个green.txt文件,我正在使用du-sh查看。它只有4kb:

[root@node1 pvc-8a90cef2-7cde-4916-b351-3a1c3a66f635]# du -sh .
4.0K    .

在这一点上,我在我的Pod中使用dd生成了一个4G的测试文件。

dd if=/dev/zero of=test-pod-file bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.0GB) copied, 18.511771 seconds, 221.3MB/s
[root@node1 pvc-8a90cef2-7cde-4916-b351-3a1c3a66f635]# du -sh .
4.1G    .
[root@node1 pvc-8a90cef2-7cde-4916-b351-3a1c3a66f635]# ls -l
total 4194308
-rw-r--r-- 1 root root        255 Apr  8 22:34 greet.txt
-rw-r--r-- 1 root root 4294967296 Apr  8 22:37 test-pod-file
[root@node1 pvc-8a90cef2-7cde-4916-b351-3a1c3a66f635]#

你可以看到磁盘占用已经增加了。所以,我认为你可以尝试使用DD创建一个更大的文件,看看相应节点上的pvc路径是否发生了变化。这是正常的行为。

7uhlpewt

7uhlpewt6#

@PrasanaaV Can you check this with the CSI driver maintainer? This probably depends on how the CSI driver is implemented.
/triage needs-information

daupos2t

daupos2t7#

这似乎只适用于 https://github.com/IBM/ibmcloud-object-storage-plugin,并且它们的 readme 中包含了这个示例:

resources:
    requests:
      storage: 8Gi # fictitious value
root@s3fs-test-pod:/# df -Th | grep s3
s3fs           fuse.s3fs  256T     0  256T   0% /mnt/s3fs

如果我理解正确的话,在 PVC 中请求的大小不会被驱动程序在配置过程中使用,而实际大小如 df 所示的是 S3 存储桶的大小。我认为这是此 CSI 驱动程序的预期行为,而不是 kubernetes 的 bug。

fbcarpbf

fbcarpbf8#

Kubernetes项目目前缺乏足够的贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理:

  • lifecycle/stale应用后的90天不活动后,将应用lifecycle/stale
  • lifecycle/stale应用后的30天不活动后,将应用lifecycle/rotten
  • lifecycle/rotten应用后的30天不活动后,该问题将被关闭

您可以:

  • 将此问题标记为新鲜的/remove-lifecycle stale
  • 使用/close关闭此问题
  • 提供帮助,请使用Issue Triage

请将反馈发送至sig-contributor-experience@kubernetes/community
/lifecycle stale

相关问题