我使用以下 YAML 创建了一个持久卷
apiVersion: v1
kind: PersistentVolume
metadata:
name: dq-tools-volume
labels:
name: dq-tools-volume
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: volume-class
nfs:
server: 192.168.215.83
path: "/var/nfsshare"
创建此内容后，我使用以下 YAMLS 创建了两个持久卷声明
聚氯乙烯1：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: jenkins-volume-1
labels:
name: jenkins-volume-1
spec:
accessMOdes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
storageClassName: volume-class
selector:
matchLabels:
name: dq-tools-volume
聚氯乙烯2：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: jenkins-volume-2
labels:
name: jenkins-volume-2
spec:
accessMOdes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
storageClassName: volume-class
selector:
matchLabels:
name: dq-tools-volume
但我注意到这两个持久卷声明都在写入同一个后端卷。
如何将一个持久卷声明的数据与另一个持久卷声明的数据隔离开来。我正在使用它来多次安装詹金斯。我希望每个 Jenkins 的工作空间都是隔离的。
正如@D.T.所解释的那样，持久卷声明仅绑定到持久卷。
不能将 2 个 pvc 绑定到同一 pv。
在这里，您可以找到讨论它的另一个案例。
对于你的方案，有一个更好的解决方案，它涉及使用 nfs 客户端预配程序。要实现这一目标，首先您必须在集群中安装 helm，然后按照我在 ServerFault 上为之前的答案创建的这些步骤进行操作。
我已经对其进行了测试，使用此解决方案，您可以将一个PVC与另一个PVC隔离。
1 - 在我的主节点上安装和配置 NFS 服务器(Debian Linux，这可能会根据您的 Linux 发行版而改变(：
在安装 NFS 内核服务器之前，我们需要更新系统的存储库索引：
$ sudo apt-get update
现在，运行以下命令为了在您的系统上安装 NFS 内核服务器：
$ sudo apt install nfs-kernel-server
创建导出目录
$ sudo mkdir -p /mnt/nfs_server_files
由于我们希望所有客户端都访问该目录，我们将通过以下命令删除导出文件夹的限制性权限(根据您的安全策略，这可能会因您的设置而异(：
$ sudo chown nobody:nogroup /mnt/nfs_server_files
$ sudo chmod 777 /mnt/nfs_server_files
通过 NFS 导出文件将服务器访问权限分配给客户端
$ sudo nano /etc/exports
在此文件中，添加一个新行以允许从其他服务器访问您的共享。
/mnt/nfs_server_files 10.128.0.0/24(rw,sync,no_subtree_check)
您可能希望在共享中使用不同的选项。 10.128.0.0/24 是我的 K8s 内部网络。
导出共享目录并重新启动服务以确保所有配置文件正确无误。
$ sudo exportfs -a
$ sudo systemctl restart nfs-kernel-server
检查所有活动共享：
$ sudo exportfs
/mnt/nfs_server_files
10.128.0.0/24
2 - 在我的所有工作节点上安装 NFS 客户端：
$ sudo apt-get update
$ sudo apt-get install nfs-common
此时，您可以进行测试以检查您是否有权从工作线程节点访问您的共享：
$ sudo mkdir -p /mnt/sharedfolder_client
$ sudo mount kubemaster:/mnt/nfs_server_files /mnt/sharedfolder_client
请注意，此时您可以使用主节点的名称。K8s在这里负责DNS。 检查卷是否按预期安装，并创建一些文件夹和文件以确保一切正常。
$ cd /mnt/sharedfolder_client
$ mkdir test
$ touch file
返回到您的主节点并检查这些文件是否位于/mnt/nfs_server_files 文件夹中。
3 - 安装 NFS 客户端配置程序。
使用 helm 安装配置器：
$ helm install --name ext --namespace nfs --set nfs.server=kubemaster --set nfs.path=/mnt/nfs_server_files stable/nfs-client-provisioner
请注意，我已经为它指定了一个命名空间。 检查它们是否正在运行：
$ kubectl get pods -n nfs
NAME READY STATUS RESTARTS AGE
ext-nfs-client-provisioner-f8964b44c-2876n 1/1 Running 0 84s
此时我们有一个名为 nfs-client 的存储类：
$ kubectl get storageclass -n nfs
NAME PROVISIONER AGE
nfs-client cluster.local/ext-nfs-client-provisioner 5m30s
我们需要创建一个 PersistentVolumeClaim：
$ more nfs-client-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
namespace: nfs
name: test-claim
annotations:
volume.beta.kubernetes.io/storage-class: "nfs-client"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Mi
$ kubectl apply -f nfs-client-pvc.yaml
检查状态(预期为"已绑定"(：
$ kubectl get persistentvolumeclaim/test-claim -n nfs
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-e1cd4c78-7c7c-4280-b1e0-41c0473652d5 1Mi RWX nfs-client 24s
4 - 创建一个简单的 pod 来测试我们是否可以读/写出 NFS 共享：
使用此 yaml 创建一个 pod：
apiVersion: v1
kind: Pod
metadata:
name: pod0
labels:
env: test
namespace: nfs
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
volumeMounts:
- name: nfs-pvc
mountPath: "/mnt"
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: test-claim
$ kubectl apply -f pod.yaml
让我们列出 Pod 上所有挂载的卷：
$ kubectl exec -ti -n nfs pod0 -- df -h /mnt
Filesystem Size Used Avail Use% Mounted on
kubemaster:/mnt/nfs_server_files/nfs-test-claim-pvc-a2e53b0e-f9bb-4723-ad62-860030fb93b1 99G 11G 84G 11% /mnt
如我们所见，我们在/mnt 上挂载了一个 NFS 卷。(注意路径kubemaster:/mnt/nfs_server_files/nfs-test-claim-pvc-a2e53b0e-f9bb-4723-ad62-860030fb93b1很重要(
让我们检查一下：
root@pod0:/# cd /mnt
root@pod0:/mnt# ls -la
total 8
drwxrwxrwx 2 nobody nogroup 4096 Nov 5 08:33 .
drwxr-xr-x 1 root root 4096 Nov 5 08:38 ..
它是空的。让我们创建一些文件：
$ for i in 1 2; do touch file$i; done;
$ ls -l
total 8
drwxrwxrwx 2 nobody nogroup 4096 Nov 5 08:58 .
drwxr-xr-x 1 root root 4096 Nov 5 08:38 ..
-rw-r--r-- 1 nobody nogroup 0 Nov 5 08:58 file1
-rw-r--r-- 1 nobody nogroup 0 Nov 5 08:58 file2
现在让我们看看这些文件在我们的 NFS 服务器(主节点(上的位置：
$ cd /mnt/nfs_server_files
$ ls -l
total 4
drwxrwxrwx 2 nobody nogroup 4096 Nov 5 09:11 nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12
$ cd nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12/
$ ls -l
total 0
-rw-r--r-- 1 nobody nogroup 0 Nov 5 09:11 file1
-rw-r--r-- 1 nobody nogroup 0 Nov 5 09:11 file2
这是我们刚刚在 Pod 中创建的文件！
据我了解，不可能将两个 PVC 绑定到同一个 PV。
请参阅此链接> PVC 到 PV 的绑定是一对一的映射
您可能需要查看设置的动态预配选项。
通过创建一个 10G 的 PV 和两个具有 8Gi 的 PVC 和 2Gi 声明请求进行测试 PVC-2 进入挂起状态。
master $ kubectl get persistentvolume
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv 10Gi RWX Retain Bound default/pv1 7m
master $ kubectl get persistentvolumeclaims
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc1 Bound pv 10Gi RWX 3m
pvc2 Pending 8s
用于创建PV和PVC的文件如下
master $ cat pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
hostPath:
path: /var/tmp/
master $ cat pvc1.ayml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 8Gi
master $ cat pvc2.ayml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc2
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 2Gi