Come montare il volume con UID specifico nel Kubernetes Pod?

Quindi, sto cercando di far funzionare Nexus basato su questa immagine in Kubernetes, ma non riesce con:

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

Dalla documentazione si afferma che il processo viene eseguito con UID 200 e il volume deve essere montato con tali autorizzazioni:

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.

Ho provato a cercare nella documentazione per trovare un modo per montare il volume con quelle autorizzazioni, tuttavia non sono riuscito a trovare un modo per farlo.

Qualcuno sa se è possibile specificare nella configurazione per PVC / PV o Deployment quale UID per montare il volume? Se é cosi, come?

Non è possibile impostare l' UIDutilizzo della definizione di Pod, ma Kubernetes salva il UIDvolume di provenienza.

Quindi, puoi impostare il UIDby InitContainer, che si avvia prima del contenitore principale, basta aggiungerlo al containerspercorso del Deployment:

initContainers:
- name: volume-mount-hack
  image: busybox
  command: ["sh", "-c", "chown -R 200:200 /nexus"]
  volumeMounts:
  - name: <your nexus volume>
    mountPath: /nexus

Come ha detto Anton, anche se non possiamo impostare l'UID usando la definizione di Pod. Ecco un'altra soluzione per questo argomento.

Fare riferimento al documento ufficiale di Kubernetes Configurare un contesto di sicurezza per un pod o un contenitore

La definizione del pod che ho usato:

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

La definizione del servizio:

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

E quindi creare pod e servizio senza alcuna autorizzazione negata o altri errori:

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

Prova ad accedere al contenitore Nexus3 e controlla il proprietario / permesso di / 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$

Come puoi vedere, la directory appartiene a root: nexus e puoi anche controllare i file nella directory:

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

Questo è il potere di SetGID :)

Ora controlliamo che il servizio funzioni o meno. Uso minikube per eseguire un cluster 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

Il servizio funziona come previsto.

Per quanto riguarda il commento di Torsten Bronger , quando si configura ConfigMaps e Secrets nell'array dei volumi nella specifica del pod, è possibile specificare le autorizzazioni per consentire l'accesso desiderato utilizzando la proprietà, quindi, mentre non è possibile impostare la proprietà del gruppo e dell'utente, può consentire ai processi nel pod di leggere i file in tali montaggi. Scrivere su una mappa segreta o di configurazione non ha davvero senso e la modalità di autorizzazione predefinita è comunque 755, quindi la lettura non dovrebbe essere un problema per nessun utente.defaultMode