0

好吧，我现在正用头撞墙好几天……

我的用例：我在自己的裸机云上，我正在运行 ubuntu 机器并在 4 台机器上设置 kubernetes，一台主机 3 台工人。我创建了一个私人注册表和证书管理器等。

nfs 共享也在工作节点上

我有一个必须在 pod 内以 root 身份运行的软件，现在我希望这个 root 用户将数据存储在 nfs 共享上的持久卷上。

root_squash 在咬我但是...

如果我不是 pod 内的 root，我已经创建了卷和声明，并且一切正常。当 root 时，nfs 共享上的文件被压缩到nobody:nogroup 并且 pod 内的 root 用户不能再使用它们......

该怎么办？

1) 使用 no_root_squash 选项导出 nfs 共享，但考虑到安全问题，这似乎是一个非常糟糕的主意，不确定这是否可以仅通过防火墙规则来缓解？

2）我为 fsGroup 和 uid 和 gid 挂载选项尝试了各种 securityContext 选项，只要您不是 de pod 的根，一切都可以正常工作......但我不确定我是否完全理解这一点所以

我的电脑 yaml：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: s03-pv0004
  annotations:
    pv.beta.kubernetes.io/gid: "1023"
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /data/k8s/pv0004
    server: 212.114.120.61

如您所见，我创建了一个具有 uid 1023 的专用 nfsuser 并使用它来使 pod 以该用户身份存储数据...只要我不在 pod 内就可以正常工作...

我正在运行的 pod 是有状态集中的 MarkLogic pod，如下所示：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: marklogic
  namespace: default
spec:
  selector:
    matchLabels:
      app: marklogic
  serviceName: "ml-service"
  replicas: 3
  template:
    metadata:
      labels:
        app: marklogic
    spec:
      securityContext:
        fsGroup: 1023
... more

runAsUser: 1023 有效，但如果我想成为 pod 内的 root，则再次无效...

我的问题：可以做到吗，以 root 身份运行 pod 并仍然使用 nfs 作为具有安全 nfs 共享的持久卷（即不使用 no_root_squash）？？？

还是我需要放弃 nfs 的想法并转向像 glusterfs 这样的替代方案？

4

2 回答 2

1

我将尝试以非常简单的步骤回答：

1. 你甚至可以让 root_squash 为 k8s 工作：

- run your containers as non root user: 1023 in your case

- chown -R 1023:1023 <nfs dir>

2. 你可以让 no_root_squash 为 k8s 工作：

- run your containers as root user: 0 

- chown -R root:root <nfs dir>
于 2021-09-15T16:05:27.627 回答
0

我已经从 nfs 存储转移到 kubernetes 中的本地存储声明选项。可以对此进行注释，以便需要 PV 的 pod 每次重新创建时都位于同一节点上......

于 2018-11-30T10:42:23.537 回答