Как смонтировать том с определенным 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 монтировать том? Если да, то как?
Невозможно установить UID, используя определение Pod, но Kubernetes сохраняет UID исходного объема.
Таким образом, вы можете установить UID с помощью InitContainer, который запускается перед главным контейнером, просто добавьте его в контейнеры пути Развертывание :
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 :)
Теперь давайте проверим, работает служба или нет. Я использую 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
Служба работает должным образом.
Что касается Torsten Комментарий Bronger , когда вы настраиваете ConfigMaps и Secrets в массиве томов в спецификации модуля, вы можете указать разрешения, чтобы разрешить доступ, который вы хотите, используя свойство defaultMode , поэтому, хотя вы не можете установить владение группой и пользователем, вы можете разрешить процессам в модуле читать файлы в этих монтировках. Запись в секретную или конфигурационную карту на самом деле не имеет смысла , и в любом случае режим разрешений по умолчанию - 755, поэтому чтение не должно быть проблемой для любого пользователя.