在 Pod 上挂载外部 NFS 共享并拒绝访问文件

Question

我已尝试阅读 Stack Overflow 中的所有问题和答案，并进行了很多谷歌搜索，询问了我周围的一些 Kubernetes Guru，但不可用......我对这个问题变得疯狂......

这是我的问题，我们有几个环境，有不同的租户，每个环境都有一个 NFS 服务器（在 AIX、Solaris、Linux、Windows 上......取决于租户）。并希望在特定 POD 上的 Kubernetes 部署中挂载 NFS 共享。

现在，这可行，我们可以使用 NFS V4 挂载 NFS 共享。这适用于我们所有的外部 NFS 服务器。

我正在使用那个 Kubernetes Provisioner (https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner) 并且它有效。

这是我的配置使其工作：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-xy-provisioner
  labels:
    app: nfs-xy-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-xy-provisioner
  template:
    metadata:
      labels:
        app: nfs-xy-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-xy-provisioner
          image: XYZ/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-xxx-xy-provisioner
            - name: NFS_SERVER
              value: myServer.example.com
            - name: NFS_PATH
              value:  /my/path/xy_eingang
      volumes:
        - name: nfs-client-root
          nfs:
            server: myServer.example.com
            path: /my/path/xy_eingang

使用以下 StorageClass：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-xxx-xy-nfs-storage
provisioner: k8s-sigs.io/nfs-xxx-xy-provisioner
parameters:
  pathPattern: ""
  archiveOnDelete: "false"
reclaimPolicy: Retain

以下光伏声明

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-xy-pvc
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-xxx-xy-nfs-storage"
spec:
  storageClassName: "managed-xxx-xy-nfs-storage"
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

吊舱中的挂载：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  template:
    spec:
      volumes:
        - name: app-xy
          persistentVolumeClaim:
            claimName: app-xy-pvc    
      containers:
        - name: app
          volumeMounts:
            - name: app-xy
              mountPath: /my/pod/path/xy

这是坐骑

myServer.example.com:/my/path/xy_eingang on /my/pod/path/xy type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=1.2.3.4,local_lock=none,addr=2.3.4.5)

现在，当我在挂载路径上时，我可以看到以下内容：

drwxrws--- 3 65534 4294967294  73728 Jul  2 07:52 33
drwxrws--- 2 65534 4294967294  69632 Jul  2 07:52 44
drwxrws--- 2 65534 4294967294  90112 Jul  2 07:52 55
-rwxrws--- 1 65534 4294967294 630793 Oct 20  2014 5905001_00001.ZIP

所以我们有 UID=65534 和 GID=4294967294。 我尝试将 fsgroup 或 supplementalGroups 更改为 4294967294，但 kubernetes 抱怨说，它只能 使用 0 到 2147483647 之间的数字（含） .

在我们的 NFS 服务器上（在该示例中），我们有以下用户/组：

• 用户：usernfs (UID=56008)
• 组：usernfs (GID=56001)

而且这个nfs映射没有做，并且在pod中，由于只是运行的应用程序，idmapd没有启动。 据我了解，挂载是在节点上完成的，然后在 pod 中我们只有来自节点的挂载。

而且我们不是 kubernetes 安装的所有者，我们是简单的用户，我们无法更改 Kubernetes 配置/节点等上的任何内容......我们是使用 Kubernetes 功能部署我们的应用程序的简单“用户” .我们不能使用 Helm，我们唯一可以使用的是 Kustomize。

出于安全原因，我们不能将 NFS 服务器上的权限更改为 777/644/744/666 或类似的东西。因此，所有更改共享磁盘权限的建议都对我们不起作用。

我尝试过换成NFS V3，但是从安全的角度来看，我们的安全团队不想使用这么老的协议，所以我们必须使用NFS V4。

我知道对于 NFS V4，我们需要运行 idmapd，但我不知道我们需要在哪里运行它，在节点上、pod 上还是其他地方？不知道，我对 Kubernetes 还很陌生，而我可以在几分钟内完成的事情却要花我几周的时间才能完成（比如这个问题），而且我找不到解决这个问题的方法。

因此，欢迎任何帮助来解决该权限问题...

Kubernetes的版本如下：

Client Version: version.Info{
  Major:"1", 
  Minor:"18", 
  GitVersion:"v1.18.12",
  GitCommit:"7cd5e9086de8ae25d6a1514d0c87bac67ca4a481",
  GitTreeState:"clean",
  BuildDate:"2020-11-12T09:18:55Z",
  GoVersion:"go1.13.15",
  Compiler:"gc",
  Platform:"linux/amd64"
}

Server Version: version.Info{
  Major:"1",
  Minor:"19",
  GitVersion:"v1.19.9+vmware.1",
  GitCommit:"f856d899461199c512c21d0fdc67d49cc70a8963",
  GitTreeState:"clean", BuildDate:"2021-03-19T23:57:11Z",
  GoVersion:"go1.15.8",
  Compiler:"gc",
  Platform:"linux/amd64"
}

亲切的问候， 亚历山德罗

Answer 1

我知道这有多令人沮丧，我已经在 centos 8、Ubuntu 18、20 上的裸机和数字海洋上使用过它，我们必须在主机服务器上安装 nfs 工具，而不是它的魅力。我们甚至不必触摸用户安全 uuid 等。