Kubernetes Podで特定のUIDを持つボリュームをマウントする方法は？

だから、Kubernetes でこのイメージに基づいてNexusを実行しようとしていますが、次のように失敗します：

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はソースボリュームのを保存します。

そのため、メインコンテナの前に起動するUIDby を設定し、InitContainerそれを次のcontainersパスに追加するだけDeploymentです。

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

Antonが言ったように、Podの定義を使用してUIDを設定することはできませんが。このトピックの別の回避策があります。

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であるため、読み取りはどのユーザーにとっても問題になりません。