web-dev-qa-db-ja.com

Kubernetesポッドで特定のUIDを使用してボリュームをマウントする方法

そのため、Kubernetesの this イメージに基づいて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を指定できるかを誰かが知っていますか？もしそうなら、どうですか？

permissionskubernetesdisk-volumepv
14
srkiNZ84

UIDの定義を使用してPodを設定する方法はありませんが、KubernetesはソースボリュームのUIDを保存します。

したがって、UIDを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
30
Anton Kostenko

アントンが言ったように、ポッドの定義を使用して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

サービスは期待どおりに機能しています。

8
chemi0213

Torsten Bronger の comment については、ポッド仕様のボリューム配列でConfigMapとシークレットを構成するときに、defaultModeを使用して必要なアクセスを許可するアクセス許可を指定できますプロパティなので、グループとユーザーの所有権を設定することはできませんが、ポッド内のプロセスがそれらのマウント内のファイルを読み取ることを許可できます。 シークレットまたは構成マップへの書き込みは実際には意味をなさない であり、デフォルトの許可モードはとにかく755であるため、どのユーザーにとっても読み取りは問題になりません。

0
David Dooling