Kubernetes Persistent Volume Claim 安装了错误的 gid

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 运行容器中的进程：

1. runAsUsersecurityContextPod 定义中的字段指定在 Pod 中的容器中运行的第一个进程的用户 ID。

2. fsGroupsecurityContextPod 中的字段指定与 Pod 中的所有容器关联的组 ID。该组 ID 还与挂载到 Pod 的卷以及在这些卷中创建的任何文件相关联。

3. 当 Pod 使用具有pv.beta.kubernetes.io/gid注解的 PersistentVolume 时，带有注解的 GID 会以与 Pod 安全上下文中指定的 GID 相同的方式应用于 Pod 中的所有容器。

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

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

用mountOptionsattribute比用volume.beta.kubernetes.io/mount-optionsannotation好，用storageClassNameattribute代替volume.beta.kubernetes.io/storage-classannotation。这些注解在过去被用来代替属性，现在它们仍然有效，但是在未来的 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

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

参考你的配置：

1. 在您的 PVC 中 yamlvolume.beta.kubernetes.io/mount-options: "uid=1000,gid=1000"不起作用，因为它是 StorageClass 或 PV 的一个选项。

2. 您在 PVC yaml 中指定了storageClassName: "default"和volume.beta.kubernetes.io/storage-class: default，但他们也在做同样的事情。此外，default StorageClass默认情况下没有挂载选项。

3. 在您的 PVC yaml 'pv.beta.kubernetes.io/gid: "1000"' 注释与securityContext.fsGroup: 1000部署定义中的选项相同，因此第一个是不必要的。

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

Answer 2

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

默认情况下，您看到的 UID/GID 是由于 NFS 上启用了根南瓜。

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