Kubernetes fsGroup 未更改 PersistentVolume 上的文件所有权

Question

在主机上，挂载目录 ( /opt/testpod) 中的所有内容均归 uid=0 gid=0 所有。我需要这些文件由容器决定的任何内容（即不同的 gid）拥有，以便能够在那里写入。我正在测试的资源：

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv
  labels:
    name: pv
spec:
  storageClassName: manual
  capacity:
    storage: 10Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/opt/testpod"

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  storageClassName: manual
  selector:
    matchLabels:
      name: pv
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi

---
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  nodeSelector:
    foo: bar
  securityContext:
    runAsUser: 500
    runAsGroup: 500
    fsGroup: 500
  volumes:
  - name: vol
    persistentVolumeClaim:
      claimName: pvc
  containers:
  - name: testpod
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: vol
      mountPath: /data

pod 运行后，我kubectl exec进入它并ls -la /data显示 gid=0 仍然拥有的所有内容。根据一些 Kuber 文档，fsGroup应该在 pod 启动时 chown 所有内容，但它没有发生。请问我做错了什么？

Answer 1

PV类型 hostpath不支持安全上下文。您必须是 root 才能写入卷。在这个github 问题和关于hostPath 的文档中对此进行了很好的描述：

在底层主机上创建的目录只能由 root 写入。您需要在 特权容器中以 root 身份运行进程 ，或者修改主机上的文件权限以便能够写入 hostPath 卷

您可能还想检查此github 请求，该请求描述了为什么更改主机目录的权限是危险的。

人们描述的解决方法似乎是授予用户 sudo 权限，但这实际上使得以非 root 用户身份运行容器的想法变得毫无用处。

安全上下文似乎与emptyDir卷配合得很好（这里的k8s文档中有很好的描述）