时间戳

首页 > 解决方案 > Kubernetes fsGroup 未更改 PersistentVolume 上的文件所有权

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

问题描述

在主机上，挂载目录 ( /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 start 上 chown 一切，但它没有发生。请问我做错了什么？

标签： kubernetes

解决方案

hostpathPV 类型不支持安全上下文。 您必须是要写入的卷的 root。在这个github 问题和这个关于hostPath的文档中有很好的描述：

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

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

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

安全上下文似乎与 emptyDir 卷一起工作得很好（在 k8s 文档中描述得很好）

推荐阅读