Как смонтировать том с определенным UID в Kubernetes Pod?

Итак, я пытаюсь запустить Nexus на основе этого образа ( https://hub.docker.com/r/sonatype/nexus3/) в Kubernetes, но он не работает с:

mkdir: cannot create directory '../sonatype-work/nexus3/log': Permission denied
mkdir: cannot create directory '../sonatype-work/nexus3/tmp': Permission denied
Java HotSpot(TM) 64-Bit Server VM warning: Cannot open file ../sonatype-work/nexus3/log/jvm.log due to No such file or directory

Из документации говорится, что процесс выполняется с UID 200 и том должен быть смонтирован с такими разрешениями:

A persistent directory, /nexus-data, is used for configuration,
logs, and storage. This directory needs to be writable by the Nexus
process, which runs as UID 200.

Я пытался найти документацию, чтобы найти способ монтировать том с этими разрешениями, однако я не смог найти способ сделать это.

Кто-нибудь знает, можете ли вы указать в конфигурации для PVC/PV или Deployment, с каким UID монтировать том? Если так, то как?

Источник

3 ответа

Решение

Там нет никакого способа установить UID используя определение PodКубернетес спасает UID исходного объема.

Таким образом, вы можете установить UID от InitContainer, который запускается перед основным контейнером, просто добавьте его в containers путь Deployment:

initContainers:
- name: volume-mount-hack
  image: busybox
  command: ["sh", "-c", "chown -R 200:200 /nexus"]
  volumeMounts:
  - name: <your nexus volume>
    mountPath: /nexus
Источник

Как сказал Антон, хотя мы не можем установить UID, используя определение Pod. Вот еще один обходной путь для этой темы.

Пожалуйста, обратитесь к официальному документу Kubernetes. Настройка контекста безопасности для контейнера или контейнера.

Определение стручка, которое я использовал:

apiVersion: v1
kind: Pod
metadata:
  name: nexus3
  labels:
    app: nexus3
spec:
  securityContext:
    fsGroup: 200
  volumes:
  - name: nexus-data-vol
    emptyDir: {}
  containers:
  - name: nexus3-container
    image: sonatype/nexus3
    volumeMounts:
    - name: nexus-data-vol
      mountPath: /nexus-data

Определение сервиса:

apiVersion: v1
kind: Service
metadata:
  name: nexus3-service
spec:
  type: NodePort
  ports:
  - port: 8081
    nodePort: 30390
    protocol: TCP
    targetPort: 8081
  selector:
    app: nexus3

А затем создайте пакет и службу без каких-либо разрешений или других ошибок:

# kubectl create -f nexus3.yaml
# kubectl create -f nexus3-svc.yaml

Попробуйте войти в контейнер Nexus3 и проверить владельца / разрешение / nexus-data:

# kubectl exec -it nexus3 -- sh
sh-4.2$ ls -ld /nexus-data/
drwxrwsrwx 16 root nexus 4096 Mar 13 09:00 /nexus-data/
sh-4.2$

Как видите, каталог принадлежит root: nexus, и вы также можете проверить файлы в каталоге:

sh-4.2$ cd /nexus-data/
sh-4.2$ ls -l
total 72
drwxr-sr-x   3 nexus nexus  4096 Mar 13 09:00 blobs
drwxr-sr-x 269 nexus nexus 12288 Mar 13 08:59 cache
drwxr-sr-x   8 nexus nexus  4096 Mar 13 09:00 db
drwxr-sr-x   3 nexus nexus  4096 Mar 13 09:00 elasticsearch
drwxr-sr-x   3 nexus nexus  4096 Mar 13 08:59 etc
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 generated-bundles
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 instances
drwxr-sr-x   3 nexus nexus  4096 Mar 13 08:59 javaprefs
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 kar
drwxr-sr-x   3 nexus nexus  4096 Mar 13 08:59 keystores
-rw-r--r--   1 nexus nexus     8 Mar 13 08:59 lock
drwxr-sr-x   2 nexus nexus  4096 Mar 13 09:00 log
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 orient
-rw-r--r--   1 nexus nexus     5 Mar 13 08:59 port
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 restore-from-backup
drwxr-sr-x   7 nexus nexus  4096 Mar 13 09:00 tmp
sh-4.2$ touch test-file
sh-4.2$ ls -l test-file
-rw-r--r-- 1 nexus nexus 0 Mar 13 09:13 test-file
sh-4.2$ mkdir test-dir
sh-4.2$ ls -l test-dir
total 0
sh-4.2$ ls -ld test-dir
drwxr-sr-x 2 nexus nexus 4096 Mar 13 09:13 test-dir

В этом сила SetGID:)

Теперь давайте проверим, работает ли сервис или нет. Я использую миникуб для запуска кластера kubernetes:

chris@XPS-13-9350 ~ $ minikube service nexus3-service --url
http://192.168.39.95:30390
chris@XPS-13-9350 ~ $ curl -u admin:admin123 http://192.168.39.95:30390/service/metrics/ping
pong

Сервис работает как положено.

Источник

Что касается комментария Torsten Bronger, когда вы настраиваете ConfigMaps и Secrets в массиве томов в спецификации модуля, вы можете указать разрешения, которые позволят вам получить доступ, используя defaultMode свойство, поэтому, хотя вы не можете установить групповое и пользовательское владение, вы можете разрешить процессам в модуле читать файлы на этих монтируемых устройствах. Запись в секретную или конфигурационную карту на самом деле не имеет смысла, и режим разрешений по умолчанию равен 755, поэтому чтение не должно быть проблемой для любого пользователя.

Источник
Другие вопросы по тегам