无法在 Kubernetes (Google Cloud) 中的持久卷上保留数据答案

【问题标题】：Can't keep data on my persistent volume in Kubernetes (Google Cloud)无法在 Kubernetes (Google Cloud) 中的持久卷上保留数据
【发布时间】：2020-05-03 20:28:13
【问题描述】：

我在 Google Cloud 上的 Kubernetes 集群上有一个 Redis pod。我已经建立了 pv 和声明。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: redis-pv
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: my-size 
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: postgres
  name: redis-pv-claim
spec:
  storageClassName: manual
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: my size

我也将它安装在我的 deployment.yaml 中

volumeMounts:
      - mountPath: /data
        name: redis-pv-claim
    volumes:
    - name: redis-pv-claim
      persistentVolumeClaim:
        claimName: redis-pv-claim

运行describe pod时看不到任何错误

Volumes:
  redis-pv-claim:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  redis-pv-claim
    ReadOnly:   false

但它无法保存任何密钥。每次部署后，“/data”文件夹都是空的。

我的 NFS 现在处于活动状态，但我仍然无法保留数据。

描述PVC


Namespace:     my namespace 
StorageClass:  nfs-client
Status:        Bound
Volume:        pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-class: nfs-client
               volume.beta.kubernetes.io/storage-provisioner: cluster.local/ext1-nfs-client-provisioner
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Gi
Access Modes:  RWX
VolumeMode:    Filesystem
Mounted By:    my grafana pod
Events:        <none>

Describe pod 给了我一个错误。


Warning  FailedMount  18m   kubelet, gke-devcluster-pool-1-36e6a393-rg7d  MountVolume.SetUp failed for volume "pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3" : mount failed: exit status 1
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/8f7b6630-ed9b-427a-9ada-b75e1805ed60/volumes/kubernetes.io~nfs/pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3 --scope -- /
home/kubernetes/containerized_mounter/mounter mount -t nfs 192.168.1.21:/mnt/nfs/development-test-claim-pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3 /var/lib/kubelet/pods/8f7b6630-ed9b-427a-9ada-b75e1805ed60
/volumes/kubernetes.io~nfs/pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3
Output: Running scope as unit: run-ra5925a8488ef436897bd44d526c57841.scope
Mount failed: mount failed: exit status 32
Mounting command: chroot

【问题讨论】：

标签： kubernetes redis persistent-storage

【解决方案1】：

发生的情况是，当您有多个节点使用 PVC 在 pod 之间共享文件时并不是最好的方法。

PVC 可以在位于同一节点的 pod 之间共享文件。因此，如果我有多个节点，有时我可能会觉得我的文件没有正确存储。

您的理想解决方案是使用任何可用的DSF 解决方案。在您的问题中，您提到您正在使用 GCP，但不清楚您是在使用 GKE 还是在计算实例之上创建了集群。

如果您使用的是 GKE，您是否已经检查过this 文档？请告诉我。

如果您可以访问您的节点，您可以拥有的最简单的设置是在您的一个节点中创建一个 NFS 服务器，并使用nfs-client-provisioner 提供从您的 pod 对 nfs 服务器的访问权限。

我已经使用这种方法很长一段时间了，而且效果非常好。

1 - 在我的主节点上安装和配置 NFS 服务器（Debian Linux，这可能会根据您的 Linux 发行版而有所不同）：

在安装 NFS Kernel 服务器之前，我们需要更新系统的存储库索引：

$ 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 中创建的文件！

如果此解决方案对您有帮助，请告诉我。

【讨论】：

您好，感谢您的回答。不幸的是，它没有用。 NFS 已制作，我可以看到在我的共享中的非主节点上制作的文件。我仍然看不到的唯一问题是那里的文件以及我创建的 Grafana 仪表板。