时间戳

首页 > 解决方案 > 在 NFS 中设置 PVC，不会挂载设置的 PVC 大小，而是设置整个 NFS 卷的大小

kubernetes - 在 NFS 中设置 PVC，不会挂载设置的 PVC 大小，而是设置整个 NFS 卷的大小

问题描述

我们正在使用 NFS 卷（1TB 大小的 GCP 文件存储）来设置 RWX GCP 中的许多访问 PVC，这里的问题是：例如我分配了一个 5Gi 的 PVC 并将其挂载到 /etc/nginx/test-pvc 下的 nginx pod ，而不是仅仅分配 5Gi，它分配了整个 NFS 卷大小。

我登录到 nginx pod 并执行了 df -kh：

df -kh
Filesystem           Size  Used Avail Use% Mounted on
overlay               95G   16G   79G  17% /
tmpfs                 64M     0   64M   0% /dev
tmpfs                 63G     0   63G   0% /sys/fs/cgroup
shm                   64M     0   64M   0% /dev/shm
/dev/sda1             95G   16G   79G  17% /etc/hosts
10.x.10.x:/vol 1007G  5.0M  956G   1% /etc/nginx/test-pvc
tmpfs                 63G   12K   63G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                 63G     0   63G   0% /proc/acpi
tmpfs                 63G     0   63G   0% /proc/scsi
tmpfs                 63G     0   63G   0% /sys/firmware

/etc/nginx/test-pvc 的大小是 1007G，这是我在 NFS 中的整个卷大小（1 TB），它应该是 5G，甚至在 /etc/nginx/test 中实际上并没有使用 5MB 的已用空间-PVC。为什么会有这样的行为？

使用的 PV 和 PVC yaml：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-test
spec:
  capacity:
    storage: 5Gi 
  accessModes:
  - ReadWriteOnce 
  nfs: 
    path: /vol
    server: 10.x.10.x
  persistentVolumeReclaimPolicy: Recycle 


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim1
spec:
  accessModes:
    - ReadWriteOnce 
  storageClassName: ""
  resources:
    requests:
      storage: 5Gi
  volumeName: pv-nfs-test

Nginx 部署 yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-pv-demo-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-pv-demo
  template:
    metadata:
      name: nfs-pv-pod
      labels:
        app: nfs-pv-demo
    spec:
      containers:
      - image: nginx
        name: nfs-pv-multi
        imagePullPolicy: Always
        name: ng
        volumeMounts:
          - name: nfs-volume-1
            mountPath: "/etc/nginx/test-pvc"
      volumes:
      - name: nfs-volume-1
        persistentVolumeClaim:
          claimName: nfs-claim1

有什么我想念的吗？或者这是 NFS 的行为？如果是这样，那么在生产中处理它的最佳方法是什么，因为我们将有多个其他 PVC，并可能导致一些混乱和批量拒绝问题。

标签： kubernetesgoogle-cloud-platformnfskubernetes-pvcgoogle-cloud-filestore

解决方案

有什么我想念的吗？或者这是 NFS 的行为？

不，什么都没有。这就是它的工作方式。它也不是特定于 NFS 的。

5Gi您定义的存储容量PV可以更像是声明您拥有一个PersistentVolume具有 5 GB 基础存储的对象。但这只不过是一个声明。您不能以这种方式对可用磁盘容量施加任何限制。因此，如果您有一个实际容量为 100 GB 的磁盘，为了保持一致性，最好在PV定义的该字段中声明。100Gi

您设置的存储容量PVC有点不同。可以理解为满足您的存储要求的最小存储容量。因此，如果您假设 3 个不同PVs的具有以下能力（在PV定义中声明，无论它们的实际能力是什么）：3Gi，10Gi并且100Gi您5Gi在您的 中声明PersistentVolumeClaim，其中只有 2 个，即10Gi并且100Gi可以满足此类要求。3Gi正如我上面所说，声明的最小磁盘实际上有一个相当大的磁盘支持并不重要，该磁盘具有1000Gi. 如果您PV在 kubernetes 环境中定义了一个代表此类磁盘的对象（并使其可供某些人使用）PVC最后被一些Pod使用它的人声明）并且您声明这个特定的容量PV只有3Gi容量，PVC您请求的容量5Gi无法验证磁盘的实际容量，并且“看到”容量不足的卷以满足为5Gi.

为了说明它不是特定于 NFS，您可以创建一个 100 GB 的新 GCE 永久磁盘（例如，通过云控制台，这似乎是最简单的方法），然后您可以在 a 中使用这样的磁盘，PV最终PVC将是由简单的 nginx pod 使用。这在此处进行了描述。

因此，尽管您的 GCE 永久磁盘实际上具有 100 gig 的容量，但您可以在PV10Gi 中声明（然后最多 10Gi）。PVC如果你连接到这样的 pod，你将不会看到 10Gi 的声明容量，而是磁盘的实际容量。这是完全正常的，完全按照设计的方式工作。

您可能认为它的工作方式类似于LVM创建由一个或多个磁盘组成的卷组，并且您可以创建尽可能多的逻辑卷，只要您的基础容量允许您。PVs在 kubernetes 中不允许你做这样的事情。您在定义中“设置”的容量PV只是一个声明，而不是任何类型的约束。如果您需要将巨大磁盘的单独块挂载到不同的 pod 中，则需要先将其划分为多个分区并创建单独PV的对象，每个对象都来自一个分区。

推荐阅读