Como montar volume com UID específico no Kubernetes Pod?

Então, estou tentando fazer o Nexus funcionar com base nessa imagem no Kubernetes, mas está falhando com:

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

A partir da documentação, diz que o processo é executado com o UID 200 e o volume deve ser montado com essas permissões:

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.

Tentei pesquisar na documentação para encontrar uma maneira de montar o volume com essas permissões, no entanto, não consegui encontrar nenhuma maneira de fazê-lo.

Alguém sabe se você pode especificar na configuração para o PVC / PV ou Deployment com que UID montar o volume? Se sim, como?

Não há como definir o UIDuso da definição de Pod, mas o Kubernetes salva o UIDvolume de origem.

Portanto, você pode definir o UIDby InitContainer, que é iniciado antes do contêiner principal, basta adicioná-lo ao containerscaminho do Deployment:

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

Como Anton disse, embora não possamos definir o UID usando a definição de Pod. Aí vem outra solução alternativa para este tópico.

Consulte o documento oficial do Kubernetes Configurar um contexto de segurança para um pod ou container

A definição de pod que eu usei:

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

A definição de serviço:

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

E, em seguida, crie pod e serviço sem nenhuma permissão negada ou outros erros:

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

Tente fazer login no contêiner Nexus3 e verifique o proprietário / permissão 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 você pode ver, o diretório pertence ao root: nexus, e você também pode verificar os arquivos no diretório:

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

Esse é o poder do SetGID :)

Agora vamos verificar se o serviço está funcionando ou não. Eu uso o minikube para executar um 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

O serviço está funcionando conforme o esperado.

Em relação Torsten Bronger 's comentário , quando você configura ConfigMaps e segredos na matriz volumes na especificação pod, você pode especificar as permissões para permitir o acesso que pretende utilizar a defaultModepropriedade, por isso, enquanto você não pode definir grupo e de usuário propriedade, você pode permitir que processos no pod leiam arquivos nessas montagens. Gravar em um mapa secreto ou de configuração não faz muito sentido e o modo de permissão padrão é 755 de qualquer maneira, portanto, a leitura não deve ser um problema para nenhum usuário.