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

Итак, я пытаюсь запустить Nexus на основе этого образа в 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 монтировать том? Если так, то как?

— srkiNZ84
источник

Ответы:

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

Итак, вы можете установить UIDby 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

— Антон Костенко
источник

Прекрасно работает. Спасибо за этот взлом. Используя его с образом БД Oracle.

— Томас Хофманн

Это не помогает с ConfigMaps и Secrets, хотя.

— Торстен Бронджер

Это сработало и для меня (также с помощью chmod). Я надеюсь, что кто-то (или Kubernetes) реализует менее хакерский метод.

— leeman24

Я использую что-то вроде, command: ["sh", "-c", "chmod 777 /nexus && chown 200:200 /nexus"]чтобы убедиться, что папка доступна для записи.

— Мартин Тапп

Но вопрос в том, как мы узнаем UID процесса в главном контейнере? Это может быть что угодно, кроме 200, да?

— Наваз

Как сказал Антон, хотя мы не можем установить 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 :)

Теперь давайте проверим, работает ли сервис или нет. Я использую Minikube для запуска кластера 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

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

— chemi0213
источник

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

— Дэвид Дулинг
источник