本文通过实现五个目标任务举例说明如何在多用户场景下使用Arena。
操作视频
前提条件
- 创建一个ACK集群。详情请参见创建Kubernetes托管版集群。
- 在ACK集群同VPC下，创建一个操作系统为Linux的ECS实例。具体操作步骤请参见使用向导创建实例。
本示例中，ECS实例被称为Client机器。Client机器作为Arena的工作站，提交作业至ACK集群。
- 安装最新版本Arena。具体操作步骤请参见安装Arena。
背景信息
当多个开发人员在一个公司或大团体下使用Arena进行工作时，为了有效管理，您可能需要对这些人员进行小组划分，且每个小组需要彼此隔离。这样在同一个集群内，小组就是您分配、隔离资源和权限的基本单元。
| 主机名 | 角色 | IP地址 | GPU卡数 | CPU核数 | MEM |
|---|---|---|---|---|---|
| client01 | Client | 10.0.0.97（私有）39.98.xxx.xxx（公） | 0 | 2 | 8 GiB |
| master01 | Master | 10.0.0.91（私有） | 0 | 4 | 8 GiB |
| master02 | Master | 10.0.0.92（私有） | 0 | 4 | 8 GiB |
| master03 | Master | 10.0.0.93（私有） | 0 | 4 | 8 GiB |
| worker01 | Worker | 10.0.0.94（私有） | 1 | 4 | 30 GiB |
| worker02 | Worker | 10.0.0.95（私有） | 1 | 4 | 30 GiB |
| worker03 | Worker | 10.0.0.96（私有） | 1 | 4 | 30 GiB |
目标任务
- 目标一：您需要为当前ACK集群创建两个分组dev1和dev2，并且为这两个分组各添加一个用户bob和tom。
- 目标二：每个用户只能通过自己的账号和密码登录到Client机器，使用自己环境下的Arena。
- 目标三：bob和tom只对自己提交的作业可见，以及进行管理。
- 目标四：按组划分Worker节点GPU、CPU、MEM资源（注：仅Worker节点的计算资源才能被Arena作业使用）。
- 目标五：创建组内共享的数据卷，和组与组之间全局共享的数据卷。
| 组名 | 用户 | GPU | CPU | MEM | 共享数据卷 |
|---|---|---|---|---|---|
| dev1 | bob | 1 | 不限制 | 不限制 | dev1-public和department1-public-dev1 |
| dev2 | tom | 2 | 8 | 60 GiB | dev2-public和department1-public-dev2 |
步骤一：创建和管理ACK集群的用户和组
为了安全起见，不建议您直接登录ACK集群的Master节点安装使用Arena以及对集群进行操作，因此建议您在与ACK集群同一个VPC下创建ECS实例（Client机器）。通过配置KubeConfig文件，使用ECS实例节点对ACK集群进行访问。
- 创建ACK集群中的用户（服务账号）和组（命名空间）。
提交给AI平台的作业都将在ACK集群中运行。在ACK中，作业的拥有者以服务账号（ServiceAccount）区分，作业运行的环境以名字空间（Namespace）区分。运维管理员admin将创建ServiceAccount和Namespace，并保证与在Client机器上创建的用户和组对应。可以将Namespace对应组，ServiceAccount对应用户。
admin以root身份登录Client机器，并确保拥有操作集群的权限（通过kubectl连接ACK集群步骤中完成）。执行以下操作：# 创建分组dev1对应的Namespace。 kubectl create namespace dev1 # 创建分组dev2对应的Namespace。 kubectl create namespace dev2 # 创建用户bob对应的serviceaccount。 kubectl create serviceaccount bob -n dev1 # 创建用户tom对应的serviceaccount。 kubectl create serviceaccount tom -n dev2 # 可以查看创建的组（Namespace）和用户（ServiceAccount）。 kubectl get serviceaccount -n dev1 kubectl get serviceaccount -n dev2预期输出：
步骤二：为用户配置Arena的使用环境
- 为用户创建Arena配置文件。为了使不同用户以各自的身份和权限正确操作AI平台集群（ACK集群），首先您需要创建不同用户用于Arena连接ACK集群的环境配置文件（即创建在各自ServiceAccount下使用的KubeConfig文件）。集群管理员以root身份登录到Client机器上，使用附录提供的脚本createKubeConfig.sh为每位用户生成各自的KubeConfig配置文件。执行以下代码：
# 赋予生成KubeConfig脚本工具执行权限。 chmod +x createKubeConfig.sh # 为组dev1下的bob用户创建专门的KubeConfig文件。 ./createKubeConfig.sh bob -n dev1 # 为组dev2下的tom用户创建专门的KubeConfig文件。 ./createKubeConfig.sh tom -n dev2 # 把生成各自用户的Kubernetes环境配置文件放到各自用户的home目录下。 mkdir -p /home/bob/.kube/ && cp bob.config /home/bob/.kube/config mkdir -p /home/tom/.kube/ && cp tom.config /home/tom/.kube/config预期输出：
步骤三：为用户配置Arena的权限
- 在ACK集群中为每个组（Namespace），按需创建组内的角色（Role）。
集群管理员可以为每个组（Namespace）在ACK集群的具体操作权限配置不同的角色（Role）。一个角色（Role）代表组（Namespace）内一系列具体权限规则的集合。有关ACK集群中角色（Role）的定义方法，请参见Using RBAC Authorization。
- 创建好权限定义文件dev1_roles.yaml和dev2_roles.yaml后，集群管理员通过执行以下命令，使之在ACK集群中生效。
kubectl apply -f dev1_roles.yaml kubectl apply -f dev2_roles.yaml预期输出：
集群管理员可以通过以下命令查看集群中不同Namespace下的角色。kubectl get role -n dev1 kubectl get role -n dev2如出现下图所示内容，即完成了角色创建操作。
- 创建好权限定义文件dev1_roles.yaml和dev2_roles.yaml后，集群管理员通过执行以下命令，使之在ACK集群中生效。
- 为用户配置在集群内的权限（赋权）。
组的角色创建完成后，我们需要给用户绑定这个角色，使之作用在组里的成员上，即赋权给用户。集群管理员通过将组（Namespace）内的某些角色（Role）与用户（ServiceAccount）进行绑定，来为每位用户在组内赋权。
通过角色绑定，集群管理员可以为用户赋予多个组内的角色权限。这既包括用户所属的组内权限，也包括其他组内的权限。这样集群管理员就可以动态地管理任何用户在任何组内的权限，只需要更新用户与角色的对应关系即可。
ACK中通过定义RoleBinding和ClusterRoleBinding对象来声明用户（ServiceAccount）在不同组（Namespaces）或者整个集群所有组中可以扮演的角色而获取权限。ACK中角色绑定（RoleBinding和ClusterRoleBinding）的定义方法可以参见官方的文档Using RBAC Authorization。
- 集群管理员以root身份登录Client机器后，通过kubectl执行附录中的文件bob_rolebindings.yaml和tom_rolebindings.yaml即可完成用户和组角色的绑定，即用户赋权。
kubectl apply -f bob_rolebindings.yaml kubectl apply -f tom_rolebindings.yaml预期输出：
- 集群管理员通过以下命令查看集群中不同Namespace下对不同用户的角色赋权情况。
kubectl get rolebinding -n dev1 kubectl get rolebinding -n dev2如出现下图所示内容，即完成了权限绑定操作。
至此，本文示例已完成了上述的前三个目标任务。
- 集群管理员以root身份登录Client机器后，通过kubectl执行附录中的文件bob_rolebindings.yaml和tom_rolebindings.yaml即可完成用户和组角色的绑定，即用户赋权。
步骤四：配置用户组资源配额
AI平台通过ACK统一管理所有集群资源。为了保证不同组和用户安全、有效地使用集群资源，需要为小组分配资源配额。AI平台会在用户提交作业时，自动检查用户有权限运行作业的组配额使用情况。如果作业需求量超过配额上限，则提交会被拒绝。
在ACK中资源配额（ResourceQuota）的作用域是命名空间（Namespace），即对应本文中的用户组。ResourceQuota支持的资源类型很多，既包括CPU、Memory，也包括Nvidia GPU这类扩展资源。ResourceQuota也能够限制一个Namespace中容器及其它Kubernetes对象的使用量。有关更详细的说明，请参见Resource Quotas。
根据目标四中的描述，本文示例按照组划分当前集群的GPU、CPU、MEM等资源。示例假设划分的配置如数据配置表所示。本文示例将分配组dev1一张GPU卡，不划分CPU和MEM，即可以使用整个集群的CPU和MEM。分配组dev2两张GPU卡，八核CPU和60 GiB MEM。具体的操作步骤如下：
kubectl apply -f dev1_quota.yaml
kubectl apply -f dev2_quota.yaml# 查看组dev1下的资源配额。
kubectl get resourcequotas -n dev1
# 查看组dev2下的资源配额。
kubectl get resourcequotas -n dev2
# 查看组dev1资源配额的使用情况。
kubectl describe resourcequotas dev1-compute-resources -n dev1
# 查看组dev2资源配额的使用情况。
kubectl describe resourcequotas dev2-compute-resources -n dev2预期输出：
至此，本文完成了上述的目标四的按照组划分ACK集群计算资源。
步骤五：配置多级别共享存储NAS
根据用户组织内对数据共享的控制规则，可以为AI平台内的组和用户分别配置带有相应权限控制的数据卷挂载，方便用户间安全地共享数据。
本文示例目标五需要创建两类共享数据卷。一类用于存放全局的共享数据，所有组内成员都可以访问和使用，另一类仅仅用于各个小组内共享。本文假设共享数据卷的需求如数据配置表所示。四个数据卷dev1-public、dev2-public、department1-public-dev1、department1-public-dev2中的department1-public-dev1和department1-public-dev2指向NAS盘的同一个目录，组dev1和dev2共享这一份数据。dev1-public、dev2-public分别指向组dev1和组dev2所属NAS盘的不同目录，组dev1 、dev2独享这份数据。具体操作如下：
- 配置ACK集群的存储卷（PV）和存储声明（PVC）。
- 创建PV。分别创建4个PV。有关创建PV的具体操作步骤，请参见创建PV。department1-public-dev1和department1-public-dev2是用于dev1和dev2两组分别共享部门department1的数据。dev1-public，dev2-public是用于dev1和dev2各自组内共享数据。创建PV的参数配置如下图所示。
说明 设置挂载点时，选择上步骤创建NAS实例时创建的挂载点。
- 创建PV。
- 检查数据卷的配置。集群管理员以root身份登录Client机器，执行以下命令查看为不同组分配的NAS数据情况。
# 查看组dev1可以使用的数据卷。 arena data list -n dev1 # 查看组dev2可以使用的数据卷。 arena data list -n dev2预期输出：
至此，本文已经完成了所有目标。接下来本文将会以bob和tom账户进行登录使用Arena。
步骤六：模拟多用户操作
用户bob
- 登录Client机器，执行以下命令查看当前可以用共享数据卷。
# 使用bob账号登录Client机器 ssh bob@39.98.xxx.xx # 通过arena data list查看当前用户可用共享数据卷。 arena data list预期输出：
- 执行以下命令列出当前用户提交的作业。
arena list预期输出：
- 执行以下命令再提交一个一张GPU卡的训练作业。
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卡，所以预期这个作业不会被调度起来。
可以看到，虽然整个集群还有剩余资源，但是由于bob所在的组只被分配了一张GPU卡资源，并且当前已经有了一个作业占用了资源，所以bob后续的提交的作业就会被暂停。
用户tom
- 执行以下命令登录Client机器，查看当前可以用共享数据卷。
# 使用tom账号登录Client机器。 ssh tom@39.98.xx.xx # 通过arena data list查看当前用户可用共享数据卷。 arena data list预期输出：
- 执行以下命令列出当前用户提交的作业。
arena list此时看不到bob提交的作业。
- 执行以下命令列出当前用户提交的作业。
arena list预期输出：
执行结果
从上述操作可以看到，目前分别位于两个组的用户bob、tom可以通过自己的账号登录Client机器独立地使用Arena ，并通过Arena查看和使用用户当前所在组可访问的存储资源和计算资源，以及管理各自的作业。
附录
wget https://kubeflow.oss-cn-beijing.aliyuncs.com/arena-multi-users-demo.tar.gz