Kubernetes Persistent Volume Claim 安装了错误的 gid

Question

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

在 yaml 中指定 uid 和 gid 必须为 1000。

但是在部署时，卷安装了不同的 ID，所以我没有写访问权限。

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

PVC yarn :

---

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

runAsUser字段在 securityContext在 Pod 定义中为在 Pod 中的容器中运行的第一个进程指定用户 ID。

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

当 Pod 消耗具有 pv.beta.kubernetes.io/gid 的 PersistentVolume 时注释，被注释的 GID 以与在 Pod 的安全上下文中指定的 GID 相同的方式应用于 Pod 中的所有容器。

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

此外，还有多种方法可以为 PersistentVolume 设置安装选项。 s。一个 PersistentVolume是集群中由管理员配置的一块存储。此外，它可以使用 StorageClass 动态配置。 .因此，您可以在 PersistentVolume 中指定挂载选项。当您手动创建它时。或者您可以在 StorageClass 中指定它们，以及 PersistentVolumeClaim 从该类请求的每个 PersistentVolume会有这些选项。

最好用 mountOptions属性比 volume.beta.kubernetes.io/mount-options注释和 storageClassName属性而不是 volume.beta.kubernetes.io/storage-class注解。这些注释在过去被用来代替属性，现在它们仍然有效，但是在 future 的 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。

引用你的配置:

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

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

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

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