1

我们正在使用 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,并可能导致一些混乱和批量拒绝问题。

4

1 回答 1

0

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

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

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

您设置的存储容量PVC有点不同。可以理解为满足您的存储要求的最小存储容量。因此,如果您假设 3 个不同PVs的具有以下能力(在PV定义中声明,无论它们的实际能力是什么):3Gi10Gi并且100Gi5Gi在您的 中声明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的对象,每个对象都来自一个分区。

于 2021-08-06T21:03:52.437 回答