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

Question

我们正在使用 NFS 卷（GCP 文件存储，大小为 1TB）来设置 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/ 中实际上并没有使用 5MB 的已用空间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

我有什么遗漏吗？或者这是 NFS 的行为？

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

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

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

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

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

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