在 K3s Kubernetes 中创建 NFS 共享的链接答案

【问题标题】：Creating a link to an NFS share in K3s Kubernetes在 K3s Kubernetes 中创建 NFS 共享的链接
【发布时间】：2020-10-04 22:24:16
【问题描述】：

我对 Kubernetes 很陌生，并试图让 node-red 在一个小的树莓派集群上运行我很高兴地做到了这一点，但注意到一旦集群关闭，下次我启动它时，node-red 中的流就消失了。

所以，我在本地网络上的 freenas 机器上创建了一个 NFS 共享，并且可以从另一个 RPI 挂载它，所以我知道权限有效。

但是我无法让我的挂载在 kubernetes 部署中工作。

请帮忙看看我哪里出错了？

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-red
  labels:
    app: node-red
spec:
  replicas: 1
  selector:
    matchLabels:
      app: node-red
  template:
    metadata:
      labels:
        app: node-red
    spec:
      containers:
      - name: node-red
        image: nodered/node-red:latest
        ports:
        - containerPort: 1880
          name: node-red-ui
        securityContext:
          privileged: true
        volumeMounts:
        - name: node-red-data
          mountPath: /data
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: TZ
          value: Europe/London
      volumes:
         - name: node-red-data
      nfs:
         server: 192.168.1.96
         path: /mnt/Pool1/ClusterStore/nodered

我得到的错误是

error: error validating "node-red-deploy.yml": error validating data: 
ValidationError(Deployment.spec.template.spec): unknown field "nfs" in io.k8s.api.core.v1.PodSpec; if 
you choose to ignore these errors, turn validation off with --validate=false

新信息

我现在有以下内容

apiVersion: v1
kind: PersistentVolume
metadata:
  name: clusterstore-nodered
  labels:
    type: nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /mnt/Pool1/ClusterStore/nodered
    server: 192.168.1.96 
  persistentVolumeReclaimPolicy: Recycle

claim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: clusterstore-nodered-claim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

现在，当我开始部署时，它会一直等待等待，然后我看到 PVC 的以下事件

活动：类型原因年龄来自消息 ---- ------ ---- ---- -------- 普通 WaitForFirstConsumer 5m47s (x7 over 7m3s) persistentvolume-controller 等待在绑定之前创建第一个消费者正常供应 119s (x5 over 5m44s) rancher.io/local-path_local-path-provisioner-58fb86bdfd-rtcls_506528ac-afd0-11ea-930d-52d0b85bb2c2 外部供应商正在供应卷“default/clusterstore-nodered-claim” 警告 ProvisioningFailed 119s (x5 over 5m44s) rancher.io/local-path_local-path-provisioner-58fb86bdfd-rtcls_506528ac-afd0-11ea-930d-52d0b85bb2c2 无法使用 StorageClass“local-path”配置卷：仅支持 ReadWriteOnce 访问模式

Normal ExternalProvisioning 92s (x19 over 5m44s) persistentvolume-controller 等待由外部供应商“rancher.io/local-path”或系统管理员手动创建的卷

我认为这是因为我没有 nfs 提供程序，事实上如果我执行 kubectl get storageclass 我只会看到本地路径

新问题，如何为 NFS 添加存储类？用谷歌搜索一下让我毫无头绪。

【问题讨论】：

标签： kubernetes k3s

【解决方案1】：

在所述教程中，基本上需要完成以下步骤：

showmount -e 192.168.1.XY

检查共享是否可以从 NAS 外部访问

helm install nfs-provisioner stable/nfs-client-provisioner --set nfs.server=192.168.1.**XY** --set nfs.path=/samplevolume/k3s --set image.repository=quay.io/external_storage/nfs-client-provisioner-arm

而您将 IP 替换为您的 NFS 服务器，并将 NFS 路径替换为您 Synology 上的特定路径（两者都应该在您的 showmount -e IP 命令中可见

23.02.2021 更新 看来您也必须使用另一个图表和图像：

helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=192.168.1.**XY** --set nfs.path=/samplevolume/k3s --set image.repository=gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner

kubectl 获取存储类

检查存储类现在是否存在

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' && kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

将新的存储类配置为“默认”。将 nfs-client 和 local-path 替换为 kubectl get storageclass 告诉的内容

kubectl get storageclass

最终检查，是否标记为“默认”

【讨论】：

【解决方案2】：

这是一个验证错误，指向部署 yaml 的最后一部分，因此使其成为无效对象。看起来你在缩进方面犯了一个错误。它应该看起来更像这样：

  volumes:
  - name: node-red-data
    nfs:
      server: 192.168.1.96
      path: /mnt/Pool1/ClusterStore/nodered

另外，由于您是 Kubernetes 新手，我强烈建议您熟悉 PersistentVolumes 的概念及其声明。 PV 是像 Volumes 这样的卷插件，但其生命周期独立于使用 PV 的任何单个 Pod。

如果有帮助，请告诉我。

【讨论】：

谢谢你，我会尝试重写以获得更好的缩进。我还没有意识到它很重要（假设是空白）。我曾尝试使用 Persistant Volumes 来做到这一点，当我尝试使用 NFS 共享时，它只是不会调度 pod，它会永远处于挂起状态。我更改为本地路径，虽然它起作用了，但一旦我测试故障转移，通过断开运行 node-red 的节点，它就处于终止状态，并且不会在新节点上重新安排，我假设因为新节点没有与本地路径中的旧节点相同的数据。
@PeterPage 缩进错误是初学者常见的错误，在使用 yaml 文件时请记住这一点。我看到你也解决了你的第二个问题。如果您需要更多帮助，请随时提出其他问题，社区会尽力帮助您。

【解决方案3】：

好的，问题解决了。 Kubernetes 教程非常深奥，缺少很多假定的步骤。

我的问题归结为 pi 上的 k3s 仅与本地路径存储提供程序一起提供。

我终于找到了一个安装nfs客户端存储提供程序的教程，现在我的集群可以工作了！

This was the tutorial I found the information in.

【讨论】：