使用错误的 gid 安装的 Kubernetes 持久卷声明

Question

我正在创建一个 Kubernetes PVC 和一个使用它的 Deploy。

yaml中指定uid和gid必须为1000

但是在部署时，卷是用不同的 ID 挂载的，所以我没有写入权限。

如何有效地为 PVC 指定 uid 和 gid？

PVC 标签：

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jmdlcbdata
  annotations:
    pv.beta.kubernetes.io/gid: "1000"
    volume.beta.kubernetes.io/mount-options: "uid=1000,gid=1000"
    volume.beta.kubernetes.io/storage-class: default
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "2Gi"
  storageClassName: "default"

部署 yaml：

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  name: jmdlcbempty
  namespace: default
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: jmdlcbempty
    spec:
      securityContext:
        runAsUser: 1000
        fsGroup: 1000
      volumes:
        - name: jmdlcbdata
          persistentVolumeClaim:
            claimName: jmdlcbdata  
      containers:
        - name: myalpine
          image: "alpine"
          command:
            - /bin/sh
            - "-c"
            - "sleep 60m"
          imagePullPolicy: IfNotPresent


          volumeMounts:
            - mountPath: /usr/share/logstash/data
              name: jmdlcbdata

这是目录列表：

$ kubectl get pvc; kubectl get pods;            
NAME         STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
jmdlcbdata   Bound     pvc-6dfcdb29-8a0a-11e8-938b-1a5d4ff12be9   20Gi       RWO            default        2m
NAME                           READY     STATUS    RESTARTS   AGE
jmdlcbempty-68cd675757-q4mll   1/1       Running   0          6s
$ kubectl exec -it jmdlcbempty-68cd675757-q4mll -- ls -ltr /usr/share/logstash/
total 4
drwxr-xr-x    2 nobody   42949672      4096 Jul 17 21:44 data

我在 IBM 的 Bluemix 集群上工作。

谢谢。

Answer 1

经过一番实验，终于可以给出答案了。

有几种方法可以从特定的 UID 和 GID 运行处理容器中的进程：

securityContext

runAsUser 字段指定 Pod 中容器中第一个进程运行的用户 ID。
fsGroup 字段指定与 Pod 中所有 Container 关联的组 ID。此组 ID 还与挂载到 Pod 的卷以及在这些卷中创建的任何文件相关联。
当 Pod 使用具有 pv.beta.kubernetes.io/gid 注解的 PersistentVolume 时，注解的 GID 将应用于 Pod 中的所有容器，其方式与 Pod 安全上下文中指定的 GID 相同.

请注意，每个 GID，无论是源自 PersistentVolume 注释还是 Pod 的规范，都应用于每个容器中的第一个进程运行。

另外，有几种方法可以为 PersistentVolume 设置挂载选项。 PersistentVolume 是集群中已由管理员配置的一块存储。此外，它可以使用 StorageClass 动态配置。因此，您可以在手动创建时在 PersistentVolume 中指定挂载选项。或者您可以在 StorageClass 中指定它们，并且 PersistentVolumeClaim 从 class 请求的每个 PersistentVolume 都将具有这些选项。

最好使用 mountOptions 属性而不是 volume.beta.kubernetes.io/mount-options 注释和 storageClassName 属性而不是 volume.beta.kubernetes.io/storage-class 注释。这些注解在过去被用来代替属性，它们现在仍然有效，但是它们将在未来的 Kubernetes 版本中完全弃用。这是一个例子：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: with-permissions
provisioner: <your-provider>
parameters:
  <option-for your-provider>
reclaimPolicy: Retain
mountOptions: #these options
  - uid=1000
  - gid=1000
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "2Gi"
  storageClassName: "with-permissions" #these options

请注意，挂载选项未经过验证，因此如果一个选项无效，挂载将简单地失败。您可以对 FAT 或 NTFS 等文件系统使用 uid=1000, gid=1000 挂载选项，但不能对 EXT4 等文件系统使用。

参考您的配置：

在您的 PVC yaml 中 volume.beta.kubernetes.io/mount-options: "uid=1000,gid=1000" 不起作用，因为它是 StorageClass 或 PV 的一个选项。
您在 PVC yaml 中指定了 storageClassName: "default" 和 volume.beta.kubernetes.io/storage-class: default，但它们的作用相同。此外，default StorageClass 默认情况下没有挂载选项。
在您的 PVC yaml 中，'pv.beta.kubernetes.io/gid: "1000"' 注释与部署定义中的 securityContext.fsGroup: 1000 选项相同，因此第一个是不必要的。

尝试使用所需的安装选项 (uid=1000, gid=1000) 创建 StorageClass，并使用 PVC 从中请求 PV，如上例所示。之后，您需要使用带有 SecurityContext 的 Deployment 定义来设置对已安装 PVC 的访问。但请确保您使用的挂载选项适用于您的文件系统。

Answer 2

您可以使用 initContainer 为卷安装路径设置 UID/GID 权限。

您默认看到的 UID/GID 是由于在 NFS 上启用了 root squash。

步数：https://console.bluemix.net/docs/containers/cs_troubleshoot_storage.html#nonroot

使用错误的 gid 安装的 Kubernetes 持久卷声明

Kubernetes Persistent Volume Claim mounted with wrong gid

kubernetes

kubernetes-pvc

ibm-cloud

kubernetes-deployment