¿Cómo montar volumen con UID específico en Kubernetes Pod?

Por lo tanto, estoy tratando de ejecutar Nexus en función de esta imagen en Kubernetes, pero falla 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

De la documentación dice que el proceso se ejecuta con UID 200 y el volumen debe montarse con esos permisos:

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.

Intenté buscar en la documentación para encontrar una forma de montar el volumen con esos permisos, sin embargo, no pude encontrar ninguna manera de hacerlo.

¿Alguien sabe si puede especificar en la configuración para PVC / PV o Implementación qué UID para montar el volumen? ¿Si es así, cómo?

No hay forma de establecer el UIDuso de la definición de Pod, pero Kubernetes guarda el UIDvolumen de origen.

Por lo tanto, puede establecer el UIDby InitContainer, que se inicia antes del contenedor principal, simplemente agréguelo a la containersruta de la Deployment:

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

Como dijo Anton, aunque no podemos establecer el UID usando la definición de Pod. Aquí viene otra solución para este tema.

Consulte el documento oficial de Kubernetes Configurar un contexto de seguridad para un pod o contenedor

La definición de pod que utilicé:

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 definición del servicio:

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

Y luego cree pod y servicio sin ningún permiso denegado u otros errores:

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

Intente iniciar sesión en el contenedor Nexus3 y verifique el propietario / permiso de / 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$

Como puede ver, el directorio pertenece a root: nexus, y también puede verificar los archivos en el directorio:

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

Ese es el poder de SetGID :)

Ahora, verifiquemos si el servicio funciona o no. Uso minikube para ejecutar un clúster de 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

El servicio funciona como se esperaba.

Con respecto al comentario de Torsten Bronger , cuando configura ConfigMaps y Secrets en la matriz de volúmenes en la especificación del pod, puede especificar los permisos para permitir el acceso que desea utilizando la defaultModepropiedad, por lo que si bien no puede establecer la propiedad del grupo y del usuario, usted puede permitir que los procesos en el pod lean archivos en esos montajes. Escribir en un mapa secreto o de configuración realmente no tiene sentido y el modo de permiso predeterminado es 755 de todos modos, por lo que la lectura no debería ser un problema para ningún usuario.