Container Service for Kubernetes:Arena をマルチユーザー環境で使用する際のベストプラクティス

リソース割り当て

department1-public-dev1 および department1-public-dev2 は、Apsara File Storage NAS (NAS) ファイルシステム上の同一ディレクトリにマウントされるため、両方のグループのユーザーが当該データにアクセスできます。dev1-public および dev2-public は別々のディレクトリにマウントされ、それぞれ Bob および Tom のみがアクセス可能です。

サンプルクラスター

本トピックで実行するすべての操作は、特に明記されていない限り、クライアント上の管理者アカウントを使用して実行します。

Linux ユーザーおよびグループの作成

クライアント上で Bob および Tom のユーザー ID (UID) およびグループ ID (GID) を作成します。Linux アカウントシステムにより、タスク 2（各ユーザーが自身の認証情報を用いてのみログイン可能であり、独自の Arena 環境で実行される）が実現されます。

# Linux グループ dev1 および dev2 を作成します。
groupadd -g 10001 dev1
groupadd -g 10002 dev2

# Linux ユーザー Bob および Tom を作成します。
adduser -u 20001 -s /bin/bash -G dev1 -m bob
adduser -u 20002 -s /bin/bash -G dev2 -m tom

# パスワードを設定します。
passwd bob
passwd tom

Kubernetes 名前空間およびサービスアカウントの作成

ジョブが送信されると、ACK クラスター内で実行されます。各 Linux ユーザーグループは Kubernetes 名前空間に、各 Linux ユーザーはその名前空間内のサービスアカウントにマッピングされます。

root ユーザーとしてクライアントにログインし、以下のコマンドを実行します。kubectl を ACK クラスターに接続するための前提条件については、「クラスターの kubeconfig ファイルの取得および kubectl を用いたクラスターへの接続」をご参照ください。

kubectl のバージョンは 1.10 以降である必要があります。

# dev1 および dev2 の名前空間を作成します。
kubectl create namespace dev1
kubectl create namespace dev2

# Bob および Tom のサービスアカウントを作成します。
kubectl create serviceaccount bob -n dev1
kubectl create serviceaccount tom -n dev2

期待される出力：

namespace/dev1 created
namespace/dev2 created
serviceaccount/bob created
serviceaccount/tom created

Arena のインストール

Arena はクライアント上で 1 回だけインストールします。root ユーザーとしてログインし、最新のコミュニティリリースパッケージをダウンロード、解凍し、install.sh を実行します。詳細については、「Arena クライアントの構成」をご参照ください。

kubeconfig ファイルの生成

各ユーザーは、スコープ付きの ID で ACK クラスターにアクセスするための独自の kubeconfig ファイルを必要とします。generate-kubeconfig.sh という名前のスクリプトを、以下の内容で作成します：

#!/usr/bin/env bash

set -e

NAMESPACE=
SERVICE_ACCOUNT=
DURATION=
OUTPUT=

help() {
    echo "Usage: $0 -n <namespace> -s <service-account> -d <duration> -o <output-file>"
    echo ""
    echo "Options:"
    echo "-n, --namespace <namespace>      Namespace of the service account."
    echo "-s, --service-account <name>     Name of the service account."
    echo "-d, --duration <duration>        Duration of the token e.g. 30d."
    echo "-o, --output <file>              Output file name. If not set, a temporary file will be created."
}

parse() {
    while [ $# -gt 0 ]; do
        case $1 in
        -n | --namespace)
            NAMESPACE="$2"
            shift 2
            ;;
        -s | --service-account)
            SERVICE_ACCOUNT="$2"
            shift 2
            ;;
        -d | --duration)
            DURATION="$2"
            shift 2
            ;;
        -o | --output)
            OUTPUT="$2"
            shift 2
            ;;
        *)
            help
            exit 0
            ;;
        esac
    done

    if [ -z "${NAMESPACE}" ] || [ -z "${SERVICE_ACCOUNT}" ] || [ -z "${DURATION}" ]; then
        help
        exit 0
    fi

    if [ -z "${OUTPUT}" ]; then
        OUTPUT=$(mktemp -d)/config
    elif [ -f "${OUTPUT}" ]; then
        echo "Output file \"${OUTPUT}\" already exists."
        exit 1
    fi
}

# Generate kubeconfig
generate_kubeconfig() {
    CONTEXT=$(kubectl config current-context)
    CLUSTER=$(kubectl config view -o jsonpath="{.contexts[?(@.name==\"${CONTEXT}\")].context.cluster}")
    SERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"${CLUSTER}\")].cluster.server}")
    TOKEN=$(kubectl create token "${SERVICE_ACCOUNT}" --namespace "${NAMESPACE}" --duration="${DURATION}")
    CERT=$(mktemp)

    mkdir -p "$(dirname "${OUTPUT}")"
    kubectl config view --raw=true -o jsonpath="{.clusters[?(@.name==\"${CLUSTER}\")].cluster.certificate-authority-data}" | base64 -d >"${CERT}"
    kubectl config set-cluster "${CLUSTER}" --kubeconfig="${OUTPUT}" --server="${SERVER}" --embed-certs=true --certificate-authority="${CERT}" >/dev/null
    kubectl config set-credentials "${SERVICE_ACCOUNT}" --kubeconfig="${OUTPUT}" --token="${TOKEN}" >/dev/null
    kubectl config set-context "${CLUSTER}-${NAMESPACE}-${SERVICE_ACCOUNT}-context" --kubeconfig="${OUTPUT}" --cluster="${CLUSTER}" --user="${SERVICE_ACCOUNT}" --namespace="${NAMESPACE}" >/dev/null
    kubectl config use-context "${CLUSTER}-${NAMESPACE}-${SERVICE_ACCOUNT}-context" --kubeconfig="${OUTPUT}" >/dev/null
    rm "${CERT}"
    echo "Saved kubeconfig to \"${OUTPUT}\"."
}

main() {
    parse "$@"
    generate_kubeconfig
}

main "$@"

Bob および Tom 向けの kubeconfig ファイルを生成します。以下のコマンドではトークンの有効期限を 720 時間に設定していますが、セキュリティポリシーに応じてこの値を調整してください。

bash generate-kubeconfig.sh -n dev1 -s bob -d 720h -o /home/bob/.kube/config
bash generate-kubeconfig.sh -n dev2 -s tom -d 720h -o /home/tom/.kube/config

期待される出力：

Saved kubeconfig to "/home/bob/.kube/config".
Saved kubeconfig to "/home/tom/.kube/config".

このステップ完了後、タスク 1 およびタスク 2 が完了します。Bob および Tom はそれぞれクライアントにログインし、独自の隔離された環境で Arena を実行できます。

ロールの作成

dev1 および dev2 名前空間にロールを作成します。Bob および Tom には、自身のジョブのみを参照・管理するために必要な最小限の権限が付与されます（タスク 3）。

以下に、各ユーザーに付与される権限をまとめます：

ユーザーグループ dev1 向けに dev1_roles.yaml を作成します：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: arena-topnode
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - services
  - deployments
  - nodes
  - nodes/*
  - services/proxy
  - persistentvolumes
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: arena
  namespace: dev1
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - '*'
  - apiGroups:
      - ""
    resources:
      - services/proxy
      - persistentvolumeclaims
      - events
    verbs:
      - get
      - list
  - apiGroups:
      - ""
    resources:
      - pods
      - pods/log
      - services
    verbs:
      - '*'
  - apiGroups:
      - ""
      - apps
      - extensions
    resources:
      - deployments
      - replicasets
    verbs:
      - '*'
  - apiGroups:
      - kubeflow.org
    resources:
      - '*'
    verbs:
      - '*'
  - apiGroups:
      - batch
    resources:
      - jobs
    verbs:
      - '*'

ユーザーグループ dev2 向けに dev2_roles.yaml を作成します：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: arena-topnode
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - services
  - deployments
  - nodes
  - nodes/*
  - services/proxy
  - persistentvolumes
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: arena
  namespace: dev2
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - services/proxy
  - persistentvolumeclaims
  - events
  verbs:
  - get
  - list
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  - services
  verbs:
  - '*'
- apiGroups:
  - ""
  - apps
  - extensions
  resources:
  - deployments
  - replicasets
  verbs:
  - '*'
- apiGroups:
  - kubeflow.org
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - '*'

両方のロール定義ファイルを適用します：

kubectl apply -f dev1_roles.yaml
kubectl apply -f dev2_roles.yaml

期待される出力：

clusterrole.rbac.authorization.k8s.io/arena-topnode created
role.rbac.authorization.k8s.io/arena created

clusterrole.rbac.authorization.k8s.io/arena-topnode unchanged
role.rbac.authorization.k8s.io/arena created

ロールが正しく作成されたかを確認します：

kubectl get role -n dev1
kubectl get role -n dev2

期待される出力：

NAME    CREATED AT
arena   2024-09-14T08:25:34Z

NAME    CREATED AT
arena   2024-09-14T08:25:39Z

ロールのユーザーへのバインド

bob_rolebindings.yaml を作成します：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bob-arena-topnode
  namespace: dev1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: arena-topnode
subjects:
- kind: ServiceAccount
  name: bob
  namespace: dev1
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bob-arena
  namespace: dev1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: arena
subjects:
- kind: ServiceAccount
  name: bob
  namespace: dev1

tom_rolebindings.yaml を作成します：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tom-arena-topnode
  namespace: dev2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: arena-topnode
subjects:
- kind: ServiceAccount
  name: tom
  namespace: dev2
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tom-arena
  namespace: dev2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: arena
subjects:
- kind: ServiceAccount
  name: tom
  namespace: dev2

両方のファイルを適用します：

kubectl apply -f bob_rolebindings.yaml
kubectl apply -f tom_rolebindings.yaml

期待される出力：

clusterrolebinding.rbac.authorization.k8s.io/bob-arena-topnode created
rolebinding.rbac.authorization.k8s.io/bob-arena created

clusterrolebinding.rbac.authorization.k8s.io/tom-arena-topnode created
rolebinding.rbac.authorization.k8s.io/tom-arena created

ロールバインディングが正しく作成されたかを確認します：

kubectl get rolebinding -n dev1
kubectl get rolebinding -n dev2

期待される出力：

NAME        ROLE         AGE
bob-arena   Role/arena   34s

NAME        ROLE         AGE
tom-arena   Role/arena   33s

タスク 1～3 が完了しました。

NAS ファイルシステムの作成

NAS コンソール にログインし、NAS ファイルシステムを作成してマウントポイントを追加します。詳細については、「共有 NAS ボリュームの構成」をご参照ください。Alibaba Cloud NAS コンソール

永続ボリュームおよび永続ボリューム要求の作成

1. 4 つの永続ボリューム（PV）— dev1-public、dev2-public、department1-public-dev1、および department1-public-dev2 — を作成します。department1-public-dev1 および department1-public-dev2 を同一 NAS ディレクトリにマウントすることで、両方のグループが共有データにアクセスできるようにします。dev1-public および dev2-public は別々のディレクトリにマウントします。詳細については、「静的プロビジョニング NAS ボリュームのマウント」をご参照ください。

   直前のステップで追加したマウントポイントを選択してください。

   

2. 各 PV に対して 1 つずつ永続ボリューム要求（PVC）を作成します。詳細については、「静的プロビジョニング NAS ボリュームのマウント」をご参照ください。PVC が作成されると、department1-public-dev1 および dev1-public が名前空間 dev1 に、department1-public-dev2 および dev2-public が名前空間 dev2 に表示されます。

ボリューム構成の検証

root ユーザーとしてクライアントにログインし、以下のコマンドを実行します：

# dev1 で利用可能なボリュームを照会します。
arena data list -n dev1

# dev2 で利用可能なボリュームを照会します。
arena data list -n dev2

期待される出力：

すべてのタスクが完了しました。

Bob のアカウント

1. Bob としてクライアントにログインし、利用可能なボリュームを照会します：

   ssh bob@39.98.xxx.xx
   arena data list

   期待される出力：

   

2. GPU 1 台を必要とするトレーニングジョブを送信します：

   arena submit tf \
           --name=tf-git-bob-01 \
           --gpus=1 \
           --image=tensorflow/tensorflow:1.5.0-devel-gpu \
           --sync-mode=git \
           --sync-source=https://code.aliyun.com/xiaozhou/tensorflow-sample-code.git \
           "python code/tensorflow-sample-code/tfjob/docker/mnist/main.py --max_steps 10000 --data_dir=code/tensorflow-sample-code/data"

3. Bob が送信したすべてのジョブを一覧表示します：

   arena list

   期待される出力：

   

4. GPU 1 台を要求する第 2 のジョブを送信します：

   arena submit tf \
           --name=tf-git-bob-02 \
           --gpus=1 \
           --image=tensorflow/tensorflow:1.5.0-devel-gpu \
           --sync-mode=git \
           --sync-source=https://code.aliyun.com/xiaozhou/tensorflow-sample-code.git \
           "python code/tensorflow-sample-code/tfjob/docker/mnist/main.py --max_steps 10000 --data_dir=code/tensorflow-sample-code/data"

   dev1 のクォータは GPU 1 個のみで、すでに最初のジョブが占有しています。クラスター全体ではまだ空き GPU がありますが、ACK クラスターは 2 番目のジョブを一時停止します。 クォータが使い切られていることを確認するには、次のコマンドを実行します。

   kubectl describe resourcequotas dev1-compute-resources -n dev1

Tom のアカウント

1. Tom としてクライアントにログインし、利用可能なボリュームを照会します：

   ssh tom@39.98.xx.xx
   arena data list

   期待される出力：

   

2. Tom が送信したすべてのジョブを一覧表示します：

   arena list

   Tom は Bob が送信したジョブを参照できません。名前空間によるアイソレーションにより、グループ間のジョブ可視性が防止されています。

   

3. トレーニングジョブを送信します。dev2 には CPU およびメモリのクォータがあるため、送信時にこれらを明示的に指定する必要があります：

    arena submit tf \
            --name=tf-git-tom-01 \
            --gpus=1 \
            --chief-cpu=2 \
            --chief-memory=10Gi \
            --image=tensorflow/tensorflow:1.5.0-devel-gpu \
            --sync-mode=git \
            --sync-source=https://code.aliyun.com/xiaozhou/tensorflow-sample-code.git \
            "python code/tensorflow-sample-code/tfjob/docker/mnist/main.py --max_steps 10000 --data_dir=code/tensorflow-sample-code/data"

4. 第 2 のジョブを送信します：

    arena submit tf \
            --name=tf-git-tom-02 \
            --gpus=1 \
            --chief-cpu=2 \
            --chief-memory=10Gi \
            --image=tensorflow/tensorflow:1.5.0-devel-gpu \
            --sync-mode=git \
            --sync-source=https://code.aliyun.com/xiaozhou/tensorflow-sample-code.git \
            "python code/tensorflow-sample-code/tfjob/docker/mnist/main.py --max_steps 10000 --data_dir=code/tensorflow-sample-code/data"

5. Tom が送信したすべてのジョブを一覧表示します：

   arena list

   期待される出力：Tom の dev2 グループには GPU 2 台のクォータがあるため、両方のジョブが実行されます。