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 中国研发中心

有任何疑问，欢迎扫描下方公众号联系我们哦～