Question

好吧，我现在正对着他的墙壁猛击头几天……

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

nfs共享也在工作节点上

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

root_squash在咬我，但是...

我已经创建了卷和声明，并且如果我不是root用户，也可以正常工作。以root身份将nfs共享上的文件压缩为nobody：nogroup，并且pod内的root用户无法再使用它们...

该怎么办？

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

2）我尝试了fsGroup和uid en gid挂载选项的各种securityContext选项，只要您不是root用户，它们都可以正常工作...但是我不确定我是否完全理解这一点，所以< / p>

我的电脑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之类的替代方案？

Answer 1

我已经从nfs存储转移到kubernetes中的本地存储声明选项。可以添加注释，以便每次重新创建需要PV的Pod都落在同一节点上...

kubernetes在Pod中使用root用户使用nfs持久卷

1 个答案: