KubeFATE升级功能演示和技术解析

KubeFATE v1.9.0版本中发布了升级功能，该功能可以帮助FATE集群的使用者使用一个KubeFATE命令来一键升级自己的FATE集群并完成数据迁移。在此之前只能通过“先卸载，再安装，手动迁移数据”来完成“升级”。本篇文章会对此新功能的使用提供示例并解释其背后的实现原理。

KubeFATE服务和FATE是解耦的。使用KubeFATE服务v1.4.5，可以部署任何一个版本的FATE集群。假设有用户使用KubeFATE服务v1.4.5部署了一个v1.8.0的FATE集群，那么现在此用户可以一键将FATE集群升级到v1.9.0。这就是我们实现的KubeFATE升级功能。

这四个pv/pvc分别是给FATE集群的四个模块：Jupyter notebook（client），MySQL，fateflow（python）和eggroll（nodemanager）准备的。

b.安装一个v1.8.0的FATE集群

安装成功之后，可以使用”kubefate cluster list”命令来查看FATE集群的uuid，使用”kubefate cluster describe”命令可以查看此FATE集群的状态。这里可以看到所有的pod和deployments都是处于就绪状态。

c.留下一些持久化数据

i.kubectl exec -n fate-9999 -itbash

ii.flow init --ip fateflow --port 9380

iii.flow test toy -gid 9999 -hid 9999

然后我们打开了jupyter notebook的UI，跑了“Pipeline Upload Data Tutorial”这个上传数据的示例Python程序。

然后打开fateboard UI，观察到5个成功的任务，上面三个是上传了3个数据集，下面两个是toy example的任务记录：

fateboard中展示的数据是从FATE的MySQL数据库中读取的。

可以看到v1.9.0 FATE集群的pod，deployment和statefulSets均处于就绪状态。(注：在v1.9.0版本中我们将所有需要数据持久化的FATE组件改为了更为合适的StatefulSets形式，https://github.com/FederatedAI/KubeFATE/pull/681)

升级到v1.9.0之后我们再一次进入client容器跑了toy example，然后查看fateboard，会发现之前跑过的任务记录都还在：

进入eggroll nodemanager容器中，发现升级之前上传过的数据集也还在:

这表示升级到v1.9.0已经成功了，且在v1.8.0时代产生的所有持久化数据都已经成功地挂载到了v1.9.0的FATE的各个pod上。

不仅是安装，在升级的过程中KubeFATE仍然利用了Helm SDK。当用户把cluster.yaml文件中的chartVersion从v1.8.0改成v1.9.0并执行安装指令时，给到 KubeFATE的信号是下载v1.9.0版本的Helm Chart（我们每一次发布都会将Helm Chart上传到Github仓库的gh-pages分支中）。然后KubeFATE通过调用Helm SDK中的升级API，将K8s集群中v1.8.0版本的计算资源停止，再启动v1.9.0版本的计算资源。

FATE集群是由多个pod组成的，其中一部分pod需要挂载持久化卷，即pv，来存储化一些生产数据。当我们选择使用existingClaim方式挂载持久化卷时，这些持久化的数据是不在Helm的管辖范围之内的。因此当KubeFATE操纵Helm来摧毁v1.8.0版本的资源时（pod，service，ingress）等，这些pv/pvc可以被保留。又因为我们在v1.9.0的版本中继续指定这些pv/pvc作为existingClaim。因此下个版本的pod在启动时会直接挂载这些存储卷。从用户的角度来看就是FATE升级了，且以前老数据还在的效果。

除了existingClaim的方式，KubeFATE还允许FATE用户使用storageClass（https://kubernetes.io/docs/concepts/storage/storage-classes/）的方式来创建存储卷。使用这种方式创建的存储卷同样也不在Helm的管辖范围之内。因此我们也可以支持使用storageClass的FATE用户用KubeFATE来升级FATE。当pod的形式StatefulSets时，pod的命名是固定的。因此v1.9.0的mysql-0 pod所绑定的存储卷，也必定会被v1.10.0的mysql-0 pod所绑定。为了支持这种更为简便的数据迁移，我们在v1.9.0版本中把所有可能挂载存储卷的FATE组件都改成了StatefulSets 的形式。只有100%无状态的组件还保留Deployments的形式，例如Spark Worker。

使用KubeFATE部署的FATE，如果版本小于v1.9.0且使用了storageClass来实现持久化，不推荐使用KubeFATE来直接进行升级。建议手动备份数据后，安装v1.9.0的FATE后手动完成数据迁移。具体原因可以参考https://github.com/FederatedAI/KubeFATE/blob/master/docs/FATE_Upgrade.md。如果从v1.9.0向未来的版本升级，KubeFATE可以完美支持storageClass和existingClaim两种方式。

在FATE系统中，MySQL是一个非常重要的模块。里面存储了很多FATE系统的重要数据。例如：

• 算法组建的注册信息，元数据信息

• 运行中产生的任务元数据

• 存储，联邦，计算引擎的元数据和配置信息

• 已经上传的数据集的元信息

• 训练好的机器学习模型信息

• 执行完毕的任务的metrics信息

• 和存储、计算、联邦引擎连接的会话信息

为了能在用户使用KubeFATE对FATE集群进行升级的过程中， 帮助用户无感地升级MySQL数据库，我们开发了FUM（FATE Upgrade Manager）。并在FUM中放置了任意两个连续FATE版本的数据库升级脚本。

FUM是KubeFATE的一个插件。当用户升级FATE时，KubeFATE会自动从DockerHub或上拉取FUM的镜像并使用Helm SDK来安装FUM。FUM会启动一个K8s job。这个job是一个一次性的任务，会按顺序执性以下操作：

•终止旧版本fateflow pod的运行，切断对数据库表的修改

•根据旧版本的chartVerison和新版本的chartVersion，计算所有需要顺序执行的脚本

当以上步骤完成后，KubeFATE会调用Helm SDK来完成所有资源的升级，包括StatefulSets, Deployment, Ingress等资源。在所有的pod都升级到新版本之后。KubeFATE会调用Helm SDK来卸载掉FUM，因为作为一个单次任务，FUM的生命周期已经可以结束了。此时用户再去观察FATE集群，看到的就是升级完成的状态。中间的过程无需用户干预。

利用这种方式KubeFATE实现了跨多版本升级。假设用户现在要从v1.7.2直接升级到v1.9.0。FUM会计算出需要顺序执行的脚本是1.7.2-1.8.0.sql和1.8.0-1.9.0.sql。两个脚本依次执行完成之后，我们终止所有v1.7.2的pod再启动v1.9.0的pod，从用户的角度来看就是无损地完成了整个FATE系统的升级，跨过了v1.8.0版本。

如上所述，FUM会帮助用户自动升级MySQL数据库的schema（模式）。但在此之前，用户必须先手动备份自己的数据库。未来一个工作的方向是升级前自动帮助用户完成数据库的备份。一个值得思考的点是当MySQL的pv剩余存储空间不足时，如何解决备份文件放置在哪里的问题。

KubeFATE的最新发布v1.4.5帮助用户解决了FATE的升级问题，目前是FATE自动升级的唯一解决方案。

在KubeFATE服务代码（https://github.com/FederatedAI/KubeFATE/blob/master/k8s-deploy/pkg/job/fate_upgrade_manager.go）中，我们使用了可扩展的代码编写方式。未来当KubeFATE进一步支持更多的联邦学习框架时，进一步以插件方式支持其他框架的Upgrade Manager也会比较容易 。

KubeFATE和FATE都是FederateAI社区（https://github.com/FederatedAI）中的开源项目，我们欢迎社区贡献者帮助我们进一步优化KubeFATE的升级功能。