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

Question

我们正在使用 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 而不是，即使使用 space 5MB 实际上并没有使用/etc/nginx/test-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，可能会导致一些混乱和容量拒绝问题。

Answer 1

Is there anything I'm missing ? Or is this the behaviour of NFS ?

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

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

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

的请求

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

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

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

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

Setting up PVC in NFS, doesn't mount the set PVC size, instead sets the whole NFS volume size

kubernetes

google-cloud-platform

nfs

kubernetes-pvc

google-cloud-filestore