FedLCM (Federation Lifecycle Manager,联邦生命周期管理器)是 VMware 在 2022 年贡献到 FATE 社区的开源项目,通过 FedLCM 的部署管理服务和任务管理服务,我们可以用图形化的方式完成包括 FATE 集群的云原生部署、联邦运维以及联邦学习任务创建、数据和模型管理等功能。(点击此链接可查看 FedLCM 的基本介绍和使用指南。)本文将围绕着 FedLCM 的基础设施管理、FATE 集群创建等几个方面的部分重点功能展开介绍。
K8s “基础设施” 的特别用法
1. 省略输入 Kubeconfig
FedLCM 是基于 KubeFATE 来完成 FATE 在 Kuberentes 集群上的部署的,因此在部署 FATE 之前,我们需要将 K8s 集群添加到 FedLCM 系统中,这里一般的方式是我们需要输入 K8s 集群的 Kubeconfig 内容。而如果 FedLCM 本身已经部署在同一个 K8s 集群上,用户可以直接使用 FedLCM 所在的 Kubernetes 集群而无需输入 Kubeconfig 文件。想要这样使用,部署 FedLCM 的时候就需要提供必要的权限,我们可以通过修改 rbac_config.yaml 文件来添加所需的权限,包括 Role 和 RoleBinding 或者 ClusterRoleBinding。如下是绑定 ClusterRole 的 RoleBinding 示例:
#add below settings to enable FedLCM to operate in the specified namespace when adding the cluster as an infra using in-cluster-config
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: admin-binding-for-fedlcm
namespace:
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
-
kind: ServiceAccount
name: fedlcm-admin
namespace: fedlcm
其中 “” 修改为我们想要使用的 namespace 名称即可。添加完权限,我们就可以在添加基础设施的时候,选择 “使用当前服务的 Service Account”,就可以使用到 FedLCM 所在的集群了。
(无需输入Kubeconfig内容)
2. 仅使用 K8s 某个命名空间权限
在很多生产环境的实际场景中,我们对于所操作的 K8s 集群往往只有单个或某几个命名空间(namespace)的权限,或者即便我们有着整个集群的操作权限,我们也希望部署的 KubeFATE 和 FATE 以及它们的权限也仅存在于某个命名空间。
为了满足在这种权限限制下的 FATE 部署运行的需求,我们可以使用 FedLCM 在添加 K8s 集群作为基础设施的时候,打开界面上的 “限定命名空间” 的开关,并输入 namespace 名称。这样,之后在该基础设施上创建的 KubeFATE 和 FATE 集群以及衍生的权限都会仅存在于这个 namespace。使用这种方式的时候需要注意的是,一个 namespace 下只能部署一个 FATE 集群或者一个 FATE Exchange。如果我们想要部署多个 FATE 集群,就需要多个 namespace 的权限。
与非当前 FedLCM 部署的 FATE 互联
一般情况下,我们通过一个 FedLCM 服务在一个联邦里部署 Exchange 和多个 FATE 集群,集群间通过 Exchange 互联。但是有时候联邦学习是发生在不同组织、单位之间的,在这种情况下一般无法使用一个 FedLCM 服务管理不同组织各自的 K8s 和 FATE 集群。而 FedLCM 也支持这样的形态的联邦,即我们可以通过 FedLCM 部署 FATE 集群,并让其与其他组织的、非当前 FedLCM 部署的 FATE 集群互联,这里其他方的 FATE 集群可以是用另外的 FedLCM 实例部署的,也可以是用 KubeFATE、AnsibleFATE 等方式部署的。
假设有两个组织 Party-9999 和 Party-10000,他们各自部署了自己的 FedLCM,并想要组成联邦。如果 Party-9999 部署了 FATE-Exchange 和自己的 FATE 集群,那么另一方 Party-10000 可以通过 “导入外部的 FATE-Exchange” 的方式来让自己部署的 FATE 集群连接到对方 Party-9999 的 FATE-Exchange 上。然后 Party-9999 再通过 “导入外部的 Cluster” 来让自己的 FATE-Exchange 可以连接到 Party-10000 部署的 FATE 集群。在这个过程中各方的 FedLCM 不会访问和操作对方的 K8s 集群和 FATE 实例,各方只需要提供用于互联的服务的连接地址即可。
(导入外部的 Exchange,需要提供 Exchange 中 Traffic Server 和 Nginx 的地址)
(导入外部的 Cluster,需要提供该 FATE 集群中 Pulsar 和 Nginx 的地址)
对接现有的基础引擎
通过 FedLCM 部署的 FATE 集群使用的基础引擎是 Spark、HDFS 和 Pulsar。企业或组织在部署 FATE 时,默认情况下 FedLCM 会部署一套以容器形式运行的基础引擎服务。同时,若组织内已经部署和运行有这些服务,FedLCM 也支持直接让 FATE 系统对接这些资源,而不再另行部署这些组件。这样可以充分利用组织内现有的稳定的服务,更好地管理和分配这些资源,并进一步提升效率。在使用 FedLCM 部署 FATE 的时候,可以在 “选择是否使用已存在的基础引擎服务” 页面中,打开服务名字后面的开关,并配置这些服务的相关信息。这种方式的配置内容和和注意事项(比如如何全部或部分使用已存在的基础服务,对 Spark 集群的要求等),可以参考 FedLCM 项目仓库中相关深入介绍的文档。
(配置对接外部已存在的基础引擎)
升级 FATE 与 Exchange
过往的文章中介绍了 KubeFATE 对升级 FATE 集群的支持,升级的时候 KubeFATE 首先会停止原来的 FATE 集群,然后使用升级脚本升级 FATE 集群的持久化数据,最后启动新版本的 FATE 集群。
基于 KubeFATE 的这个功能,FedLCM 也支持了对 FATE 集群和 FATE-Exchange 的升级,当然,需要先升级 FedLCM 本身到新版本,然后才能升级它管理的 FATE 到新版本。对于 FedLCM 的升级,如果数据库使用了持久化的卷,那么可以直接使用新版本部署覆盖原来的版本就可以完成升级。如果数据库没有使用持久化的卷,那么需要先备份数据库,然后部署新版本的 FedLCM,再使用备份的数据库恢复数据。
在升级 FedLCM 之后,新的 FedLCM 将会含有新版本 FATE 的部署 chart,如下图所示,如果当前管理的 FATE 和 Exchange 不是最新版本,那么在 FATE 和 Exchange 的集群操作操作页面上就会出现升级选项:
(第一步:找到并点击待升级的 FATE 集群)
(第二步:选择目标版本并等待升级完成)
此时我们点击升级,并在升级操作页面选择升级版本即可,之后我们等待升级成功就可以使用新版本的 FATE 了。同样需要注意的是,升级功能需要在部署 FATE 时开启持久化,同时升级前请做好数据备份。
总结
以上就是 FedLCM 在 v0.2 和 v0.3 版本中引入的部分实用功能,除了这些之外,FedLCM 中还有很多其他新增的功能,如自定义镜像仓库和登陆信息、Site Portal 服务支持单独部署、支持纵向联邦学习算法等等,详细的介绍都可以在项目的文档目录中找到。项目地址是 https://github.com/FederatedAI/FedLCM,欢迎大家关注,如果有任何想法或建议,以及代码贡献,也欢迎发起 Issue 和 Pull Request 与开发者交流。后续 FedLCM 会增加更多适用于真实环境的功能支持,同时期待和社区一起进一步探索联邦学习落地实践中的方方面面。
作者团队介绍
本文由 VMware 中国研发中心云原生实验室贡献,该团队属于 VMware CTO 办公室的 AI Labs 部门,负责 AI/ML、云原生等前沿技术领域的创新项目。VMware 作为 FATE TSC Board 成员参与 FATE 开源项目的开发和维护工作,贡献了包括 KubeFATE、FedLCM 等项目以加速 FATE 的运维管理。本文主要作者为该实验室工程师、KubeFATE 和 FedLCM 项目维护者马陈龙和王方驰。
内容来源|公众号:VMware 中国研发中心
有任何疑问,欢迎扫描下方公众号联系我们哦~