Kubernetes クラスターは初めてですが、ラボ用に Kubernetes クラスターをデプロイして管理する役割を担っています。現時点では、GPU を使用する pytorch コンテナーのポッド (私の設定でデプロイされる最も一般的な種類のポッド) は、いくつかの権限の問題はあるものの、クラスター上で問題なく動作しています。
- たとえば、あるユーザーは
tom、別のユーザーによってデプロイされたポッドを削除することができます。jerry - コンテナは として実行されています
root。ここでも、jerryを例に挙げてみましょう。 が、jerryさまざまな他のユーザーが所有するファイルを含むディレクトリをマウントするコンテナでマニフェストされたポッドをデプロイするとします。 として実行されている は、独自のファイルだけでなく、 が所有するファイル、さらには や が所有するファイルも変更できることを意味しますroot。このようなマニフェストは、おそらく次のようになります。jerrytomspiketyke
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
namespace: default # this field should be properly configured
# if I want to restrict user access to certain resources,
# usually pods.
spec:
runtimeClassName: nvidia
nodeSelector:
nvidia.com/gpu: 'true'
restartPolicy: Never
containers:
- name: cuda-container
image: mylab.registry:5000/espnet/espnet:gpu-latest
command:
- /bin/sh
- -c
- |
echo "running following scripts"
ls /data
ls /exp
nvidia-smi
resources:
limits:
nvidia.com/gpu: 4
volumeMounts:
- name: data-volume
mountPath: /data
- name: exp-volume
mountPath: /exp
volumes:
- name: data-volume
hostPath:
path: /data
- name: exp-volume
hostPath:
path: /exp # where directories owned by tom, jerry,
# spike and tyke are located.
# on the host machine, this directory is actually
# a mounted nfs path served by other machine.
実際、Kubernetesはこれらの問題に取り組むための武器を提供してくれます。RBACそしてセキュリティコンテキスト最初の問題は、複数の名前空間または階層的な名前空間を作成し、異なるロールに対して名前空間への正しい権限を構成することで解決できるようですが、それが機能するかどうかはまだわかりません。
しかし、2 番目の問題については、セキュリティ コンテキストにより、一部のイメージ (実際にはインターネットから取得したイメージが多すぎる) はルートで実行する必要があり、再構築が必要であるにもかかわらず、コンテナーは特定のファイルにのみアクセスできる非ルート モードで実行できます。ただし、最終的には、securityContextマニフェストに正しいフィールドを持つポッドのみをデプロイするというユーザーの善意に頼るしかないようです。
クラスター管理者として、前述の 2 つの権限の問題を回避するにはどうすればよいでしょうか? 権限を自動的に処理するための Kubernetes プラグインはありますか? または、すべてのオプションを使い果たした場合、すべてのkubectl applyコマンドをインターセプトし、マニフェストを上書きして、代わりに変更されたバージョンを適用するシステム全体のプログラムを展開する必要がありますか?