Как определить uid, gid смонтированного тома в Pod

Это вопрос в нашей производственной среде. Мы используем Kubernetes для развертывания нашего приложения через Pods. Модулям может потребоваться некоторое пространство для хранения файлов.

Мы используем «Постоянный том» и «Заявление о постоянном томе», чтобы представить реальный внутренний сервер хранения. В настоящее время реальным сервером заднего хранилища является «NFS». Но «NFS» не контролируется нами, и мы не можем изменить конфигурацию NFS.

Каждый раз uid и gid тома, монтируемого в Pod, всегда являются «root root». Но процесс в модуле выполняется от имени пользователя без полномочий root, процесс не может читать / записывать смонтированный том. Наше текущее решение состоит в том, что мы определяем initContainer, который запускается от имени пользователя root, и используем команду chown [udi] [gid] [folder] »для смены владельца. Существует ограничение, что ininContainer должен запускаться от имени пользователя root.

На данный момент мы пытаемся развернуть наше приложение на Openshift. По умолчанию все поды (контейнеры) не могут быть запущены с правами root. В противном случае Pod создать не удастся.

Итак, мой вопрос в том, что способ k8s или способ Openshift для определения / изменения uid и gid смонтированного тома. Я пробовал mountOptions, о котором говорилось в Заявление на постоянный том Kubernetes, установленное с неправильным gid
mountOptions: #these options - uid=1000 - gid=1000

Но не удалось с сообщением об ошибке ниже. Похоже, что сервер NFS не поддерживает параметры uid и gid.

Warning  FailedMount  11s  kubelet, [xxxxx.net]  MountVolume.SetUp failed for volume "nfs-gid-pv" : mount failed: exit status 32 Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /opt/kubernetes/data/kubelet/pods/3c75930a-d3f7-4d55-9996-4d10dcac9549/volumes/kubernetes.io~nfs/nfs-gid-pv --scope -- mount -t nfs -o gid=1999,uid=1999 shc-sma-cd74.hpeswlab.net:/var/vols/itom/itsma/tzhong /opt/kubernetes/data/kubelet/pods/3c75930a-d3f7-4d55-9996-4d10dcac9549/volumes/kubernetes.io~nfs/nfs-gid-pv
Output: Running scope as unit run-22636.scope.
mount.nfs: an incorrect mount option was specified
  Warning  FailedMount  7s  kubelet, [xxxxx.net]  MountVolume.SetUp failed for volume "nfs-gid-pv" : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /opt/kubernetes/data/kubelet/pods/3c75930a-d3f7-4d55-9996-4d10dcac9549/volumes/kubernetes.io~nfs/nfs-gid-pv --scope -- mount -t nfs -o gid=1999,uid=1999 shc-sma-cd74.hpeswlab.net:/var/vols/itom/itsma/tzhong /opt/kubernetes/data/kubelet/pods/3c75930a-d3f7-4d55-9996-4d10dcac9549/volumes/kubernetes.io~nfs/nfs-gid-pv
Output: Running scope as unit run-22868.scope.
mount.nfs: an incorrect mount option was specified

kubernetes persistent-volumes persistent-volume-claims nfs
person Cain    schedule 14.06.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если мы говорим о Kubernetes, вы можете установить идентификатор группы, которая владеет томом, это можно сделать с помощью fsGroup, функции из Контекст безопасности Pod.

Как или OpenShift не знаю.

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
spec:
  containers:
  # specification of the pod's containers
  # ...
  securityContext:
    fsGroup: 1000

Контекст безопасности для Pod применяется к контейнерам Pod, а также к томам Pod, если это применимо. В частности, fsGroup и seLinuxOptions применяются к томам следующим образом:

Вы также можете прочитать об этом здесь и следуйте инструкциям, опубликованным @ rajdeepbs29, опубликованным здесь.

person Crou    schedule 15.06.2020
comment
Спасибо. Я уже пробовал fsGroup. Это не работает для NFS. Работает только для emptyDir. - person Cain; 16.06.2020
comment
Единственное решение вашей проблемы - это контейнер инициализации, который вы уже используете. Об этом упоминается здесь. - person Crou; 06.07.2020