Претензия Kubernetes Persistent Volume установлена ​​с неверным указанием

Question

Я создаю Kubernetes PVC и Deploy, который использует его.

В yaml указано, что uid и gid должны быть 1000.

Но при развертывании том смонтирован с разными идентификаторами, поэтому у меня нет прав на запись на него.

Как я могу эффективно указать UID и GID для ПВХ?

ПВХ ямл:

    ---

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

И вот список Dir:

$ 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

Вы можете использовать initContainer для установки разрешений UID/GID для пути монтирования тома.

UID/GID, который вы видите по умолчанию, происходит из-за того, что в NFS включен корневой сквош.

Шаги: https://console.bluemix.net/docs/containers/cs_troubleshoot_storage.html

Answer 2

После некоторых экспериментов, наконец, я могу дать ответ.

Существует несколько способов запуска процессов в контейнере из определенного UID и GID:

1. runAsUser поле в securityContext в определении Pod указывает идентификатор пользователя для первого запуска процесса в контейнере в Pod.

2. fsGroup поле в securityContext в модуле указывает, какой идентификатор группы связан со всеми контейнерами в модуле. Этот идентификатор группы также связан с томами, подключенными к модулю, и с любыми файлами, созданными на этих томах.

3. Когда Pod потребляет PersistentVolume, который имеет pv.beta.kubernetes.io/gid аннотации, аннотированный GID применяется ко всем контейнерам в модуле таким же образом, как и GID, указанные в контексте безопасности модуля.

Обратите внимание, что каждый GID, независимо от того, происходит ли он из аннотации PersistentVolume или спецификации модуля, применяется к первому процессу, запущенному в каждом контейнере.

Также есть несколько способов настроить параметры монтирования для PersistentVolumes. PersistentVolume - это часть хранилища в кластере, предоставленная администратором. Кроме того, он может быть подготовлен динамически с помощью StorageClass. Следовательно, вы можете указать параметры монтирования в PersistentVolume при создании его вручную. Или вы можете указать их в StorageClass, и у каждого PersistentVolume, запрошенного из этого класса PersistentVolumeClaim, будут эти параметры.

Лучше использовать 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

Обратите внимание, что параметры монтирования не проверены, поэтому монтирование просто не удастся, если один из них неверен. И вы можете использовать uid=1000, gid=1000 параметры монтирования для файловых систем, таких как FAT или NTFS, но не для EXT4, например.

Ссылаясь на вашу конфигурацию:

1. В твоем ПВХ ямле volume.beta.kubernetes.io/mount-options: "uid=1000,gid=1000" не работает, потому что это вариант для StorageClass или PV.

2. Вы указали 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. Но убедитесь, что вы используете параметры монтирования, доступные для вашей файловой системы.