Jak zamontować wolumin o określonym UID w Kubernetes Pod?

Próbuję uruchomić Nexusa na podstawie tego obrazu w Kubernetes, ale nie działa to z:

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

Z dokumentacji wynika, że ​​proces działa z UID 200 i wolumin musi być podłączony z tymi uprawnieniami:

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.

Próbowałem przeszukać dokumentację, aby znaleźć sposób na zamontowanie woluminu z tymi uprawnieniami, jednak nie mogłem znaleźć żadnego sposobu, aby to zrobić.

Czy ktoś wie, czy w konfiguracji PCV / PV lub wdrożenia można określić, z jakim identyfikatorem UID należy zamontować wolumin? Jeśli tak to jak?

Nie ma sposobu, aby ustawić UIDużycie definicji Pod, ale Kubernetes zapisuje wolumin źródłowy UID.

Możesz więc ustawić UIDby InitContainer, który uruchamia się przed głównym kontenerem, po prostu dodaj go do containersścieżki Deployment:

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

Jak powiedział Anton, chociaż nie możemy ustawić UID przy użyciu definicji Pod. Oto kolejne obejście tego tematu.

Proszę odnieść się do oficjalnego dokumentu Kubernetes Konfigurowanie kontekstu bezpieczeństwa dla zasobnika lub pojemnika

Użyłem definicji strąka:

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

Definicja usługi:

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

A następnie utwórz pod i usługę bez odmowy dostępu lub innych błędów:

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

Spróbuj zalogować się do kontenera Nexus3 i sprawdź właściciela / pozwolenie / 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$

Jak widać, katalog należy do katalogu root: nexus, a także można sprawdzić pliki w katalogu:

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

Taka jest moc SetGID :)

Teraz sprawdźmy, czy usługa działa, czy nie. Używam Minikube do uruchamiania klastra 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

Usługa działa zgodnie z oczekiwaniami.

Odnośnie Torsten Bronger „s komentarzem , podczas konfigurowania ConfigMaps sekrety i wolumenów w macierzy pod spec można określić uprawnienia, aby umożliwić dostęp chcesz korzystania z defaultModenieruchomości, więc gdy nie można ustawić grupę, a użytkownik własności, ty może zezwalać procesom w zasobniku na odczytywanie plików w tych instalacjach. Zapis do tajnej mapy lub konfiguracji nie ma sensu, a domyślny tryb uprawnień to 755, więc czytanie nie powinno stanowić problemu dla żadnego użytkownika.