在仅有特定 namespace 的 admin 权限时部署 KubeFATE 和 FATE

背景介绍

使用 Kubernetes 部署 KubeFATE 时，用户并不总是拥有整个 K8s 集群的最高管理权限。正常部署 KubeFATE 并运行 FATE job 需要在特定 namespace 下绑定 Kubernetes 默认提供的 admin 角色，这种情况下需要修改部分配置文件的内容。

部署步骤

环境介绍

从一个可用的 K8s 集群开始，该集群中没有安装好的 KubeFATE，但已经存在 fate-exchange，fate-9999，fate-10000 三个 namespace 和两个不同的用户：

• 用户 9999 在 fate-exchange 和 fate-9999 namespace 下绑定了 admin 角色。
• 用户 10000 在 fate-10000 namespace 下绑定了 admin 角色。

与部署多成员参与的联邦学习网络类似，本文档目标是在该 K8s 集群中部署 2 个 Party 和 1 个 Exchange 并成功运行 FATE job。

party	party ID	owner	namespace	K8s version	KubeFATE version	FATE version
exchange	1	user-9999	fate-exchange	v1.24.3	v1.4.4	v1.8.0
party-9999	9999	user-9999	fate-9999	v1.24.3	v1.4.4	v1.8.0
party-10000	10000	user-10000	fate-10000	v1.24.3	v1.4.4	v1.8.0

安装 KubeFATE

因为 K8s 集群中并没有安装 KubeFATE 且用户仅有部分 namespace 的权限，所以各用户需要分别安装 KubeFATE 服务。但是在安装之前需要修改默认的配置文件。

本示例中用户 9999 使用的 rbac-config.yaml 文件如下（用户 10000 类似但没有创建 fate-exchange namespace 中的 rolebinding）：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubefate-admin
  namespace: fate-9999
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sc-9999-edit-binding
  namespace: fate-exchange
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
  - kind: ServiceAccount
    name: kubefate-admin
    namespace: fate-9999
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sc-edit-binding
  namespace: fate-9999
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
  - kind: ServiceAccount
    name: kubefate-admin
    namespace: fate-9999
---
apiVersion: v1
kind: Secret
metadata:
  name: kubefate-secret
  namespace: fate-9999
type: Opaque
stringData:
  kubefateUsername: admin
  kubefatePassword: admin
  mariadbUsername: kubefate
  mariadbPassword: kubefate

相应的 kubefate.yaml 文件中默认的 namespace 也需要修改为有操作权限的 namespace。

全部修改完成后即可通过如下命令安装：

$ kubectl apply -f ./rbac-config.yaml
$ kubectl apply -f ./kubefate.yaml

配置 Exchange

本示例中使用 Nginx 和 ATS 部署 Exchange，所以需要先解决各个 Party 和 Exchange 之间的证书配置，详细步骤请参考pulsar与ATS的证书生成。

Exchange 所使用的配置文件参考 trafficServer.yaml。其中 nginx 和 trafficServer 的 route_table 需要根据 Party 部署成功后相应服务的地址及端口配置。

配置好 YAML 文件后，用户 9999 使用其 kubefate 服务部署至 fate-exchange namespace 下：

kubefate cluster install -f ./cluster-exchange.yaml

可以查看 cluster 的状态是否是 Running 确认是否成功运行：

kubefate cluster ls

配置 Party

本示例中的 FATE 使用 Spark(Pulsar) 作为计算引擎。同样需要先将证书导入。

cluster 的相关配置参见cluster-spark-pulsar.yaml，注意需要修改其中 exchange 服务的地址。

配置好 Party 9999 和 Party 10000 后需修改 cluster-exchange.yaml 文件中相应的路由表以添加新的 Party。然后使用如下命令更新到 exchange（需等待一小段时间更新完成）：

kubefate cluster update -f ./cluster-exchange.yaml

测试

完成以上部署步骤后，集群中已经有了一个通过 Exchange 互联的联邦学习网络，包含 2 个Party。在 Party 9999 的 notebook 中新建 terminal 并执行测试命令检查联邦学习网络的可用性：

flow test toy -gid 9999 -hid 10000

注意事项

在同一个 K8s 集群中安装多个 KubeFATE 时，其域名不能重复，可以通过修改 ./kubefate 目录下 config.yaml 中的服务地址来访问不同的 KubeFATE 服务。

局限说明

当用户只有特定 namespace 下的 admin 权限时，会产生以下局限：

1. 部分命令无法正常执行:
   • kubefate namespace ls
   • kubefate cluster describe
2. 无法支持 PodSecurityPolicy。