前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >在KubeFATE中定制化部署联邦学习组件的深入分析

在KubeFATE中定制化部署联邦学习组件的深入分析

作者头像
Henry Zhang
发布2023-04-04 09:10:42
5420
发布2023-04-04 09:10:42
举报
文章被收录于专栏:亨利笔记

题图摄于国家大剧院

(本文作者系 VMware 中国研发云原生实验室架构师,联邦学习开源项目 KubeFATE / FATE-Operator 维护者。)

需要加入KubeFATE开源项目讨论群的同学,请关注 亨利笔记 公众号后回复 “kubefate” 即可。

相关文章

在Juypter Notebook中构建联邦学习任务

云原生联邦学习平台 KubeFATE 原理详解

用KubeFATE在K8s上部署联邦学习FATE v1.5

使用Docker Compose 部署FATE v1.5

KubeFATE 按照部署环境分成 Docker-Compose 与 Kubernetes 两部分。前者作为快速上手的实验环境,后者为生产系统 FATE 集群设计。本文主要针对在 Kubernetes 环境进行讨论。目标是有自定义 FATE 部署的高级用户的如何自定义部署模块,增减 FATE 模块等需求。

KubeFATE 分成两部分,KubeFATE CLI 与 KubeFATE 服务。其中 KubeFATE CLI 是可执行二进制文件,直接下载到客户机使用;KubeFATE 服务一般部署在与 FATE,FATE-Serving 一致的 Kubernetes 上,并且设置 Service Account,使得 KubeFATE 服务有权限创建 Pod, Service,Ingress, 具体的步骤可以参考之前文章:

云原生联邦学习平台 KubeFATE 原理详解

用KubeFATE在K8s上部署联邦学习FATE v1.5

KubeFATE CLI 提供了相应的命令,包括集群管理(kubefate cluster)、任务管理(kubefate job),Chart管理(kubefate chart),用户管理(kubefate user)四大部分。具体可参考kubefate help。接收用户指令后通过调用 KubeFATE 服务的 RESTful API 实现FATE, FATE Serving 的集群管理。KubeFATE 服务的底层是基于 Helm v3。用户传入的指令会经过渲染得到 Helm Chart,并通过任务分配进行部署操作。

本文提到的术语作以下约定:

  1. 客户机:指用户使用 KubeFATE CLI 的机器,可以是笔记本、Mac、Linux,不要求在 Kubernetes 集群内,但需要网络可联通到 Kubernetes 创建的 Ingress;
  2. Kubernetes 管理机:指可以使用kubectl的机器,可以在或者不在Kubernetes集群内,但需要网络联通到 Kubernetes 的 API Server ,且有足够的权限去创建 Service Account,Service, Ingress 和 Pod。如果需要执行 KubeFATE项目自带的 RBAC.yaml ,需要管理员权限;
  3. 服务器:指部署 Kubernetes 集群的机器。

Helm 3 与 Helm Chart

Helm v3.0.0 以后的版本经常简称 Helm 3,于2019 年11 月份发布。相较于之前版本(简称为Helm 2),有非常大的改变。最显著的区别是移除了 Tiller 组件。Helm 2是典型的客户端-服务器结构,Tiller 组件作为服务,与Helm客户端交互,并通过 Kubernetes API 使用 Kubernetes 集群。

可以看出,这个功能其实与 KubeFATE 服务比较雷同,我们选择了升级版本的 Helm 3 进行开发。Helm 3 没有服务器端,通过 Client 直接与 Kubernetes API 直接交互,动态抓取集群状态。Helm 3 的设计旨在简化权限的管理,避免状态同步带来的问题,但这个设计的缺点是权限管理完全依赖Kubernetes,配置繁杂,与第三方组件兼容需要在用户端做大量工作。

由于 FATE 本身的配置比较复杂,为了简化用户的配置使用难度,以及与上层系统的兼容,我们把状态信息管理在 KubeFATE 服务内。明白这个架构后,可以总结两点:

  1. 由于 Helm 3 与 Helm 2 本身不兼容,KubeFATE 必须与 Helm 3 使用,不兼容Helm 2。如果发现调用出问题,请检查是否客户机是否预先安装了 Helm 2。如是,需要删除。
  2. 同步 Helm 3 与 KubeFATE 的状态是一个难题,在某些极端意外情况下,可能出现两者状态不统一,一个常见解决方法是通过Helm的命令去删除已有集群。这部分会随着版本更新逐渐修复各种意外情况,如果发现也可通过 Github 的 issue 提到 KubeFATE 项目。

Helm Chart 是 Helm 使用的包格式。Chart 就是一个 Kubernetes 相关资源的文件集合。Helm Chart 有特定的目录布局要求,它们可以打包到部署的版本存档中。另外,Helm Chart 有一个(https://artifacthub.io/),提供很多现成的 Chart 下载部署。可以通过helm pull ${chart_repo}/${chart_name}来下载。

(下文本节介绍部分引用 Helm Chart 官方文档)

Chart 的文件结构

Chart 是一个组织在文件目录的集合,名称就是 Chart 的名称。譬如 WordPress 的Chart 可以存在wordpress/目录中,结构如下:

用户如果需要开发Helm Chart,可以使用helm create NAME [flags],其中[flag]为:

代码语言:javascript
复制
--debug                       enable verbose output
--kube-apiserver string       the address and the port for the Kubernetes API server
--kube-as-group stringArray   Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
--kube-as-user string         Username to impersonate for the operation
--kube-context string         name of the kubeconfig context to use
--kube-token string           bearer token used for authentication
--kubeconfig string           path to the kubeconfig file
-n, --namespace string            namespace scope for this request
--registry-config string      path to the registry config file (default "~/.config/helm/registry.json")
--repository-cache string     path to the file containing cached repository indexes (default "~/.cache/helm/repository")
--repository-config string    path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml")

来初始化 Chart 目录。其中关键的文件有:

Chart.yaml文件

为该Chart 的 metadata 描述,里面包括apiVersionnameversiondependencies等字段。我们可以通过该文件对 Chart 进行版本控制。这里还有一个重要的概念叫 Chart 的依赖,通过 Chart.yaml 的dependencies来描述。前面讲到 Helm Chart 有社区提供现成的 Chart 供下载部署,那我们在实现自己的 Chart 的时候可通过添加依赖,使用社区中已有的 Chart,作为集群部署的一部分。譬如,部署一个Wordpress 需要依赖一个 Apache 作为 HTTP 服务器,MySQL 为数据库,可以在Chart.yaml里添加类似以下的内容,

代码语言:javascript
复制
dependencies:
  - name: apache
    version: 1.2.3
    repository: https://example.com/charts
  - name: mysql
    version: 3.2.1
    repository: https://another.example.com/charts

其中,

  • name字段是你需要的chart的名称
  • version字段是你需要的chart的版本
  • repository字段是chart仓库的完整URL

在定义好dependence后就可以通过helm dependency update下载依赖的Chart到chart/目录下。

Templates目录 和 values.yaml

Helm Chart 模板是按照 Go 模板语言书写的,增加了部分函数。所有的模板文件存储在template/文件夹下。当 Helm 渲染 Chart 时,它会通过模板引擎遍历目录中每个文件。用户通过value.yaml文件包含模板的默认值。Values通过模板中的.Values对象访问values.yaml文件。譬如一个Deis数据库的Chart, 定义模板文件如下:

代码语言:javascript
复制
apiVersion: v1
kind: ReplicationController
metadata:
  name: deis-database
  namespace: deis
  labels:
    app.kubernetes.io/managed-by: deis
spec:
  replicas: 1
  selector:
    app.kubernetes.io/name: deis-database
  template:
    metadata:
      labels:
        app.kubernetes.io/name: deis-database
    spec:
      serviceAccount: deis-database
      containers:
        - name: deis-database
          image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}
          imagePullPolicy: {{ .Values.pullPolicy }}
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_STORAGE
              value: {{ default "minio" .Values.storage }}

那 Chart 对应的value.yaml需要包含:

  • imageRegistry: Docker 镜像的源注册表
  • dockerTag: Docker 镜像的 tag
  • pullPolicy: Kubernetes 的拉取策略
  • storage: 后台存储,默认设置为"minio"

value.yaml的设置如下:

代码语言:javascript
复制
imageRegistry: "quay.io/deis"
dockerTag: "latest"
pullPolicy: "Always"
storage: "s3"

除此之外,模板中为了使用需要,提供了默认的预定义值如下:

  • Release.Name: 版本名称(非chart的);
  • Release.Namespace: 发布的chart版本的命名空间;
  • Release.Service: 组织版本的服务;
  • Release.IsUpgrade: 如果当前操作是升级或回滚,设置为true;
  • Release.IsInstall: 如果当前操作是安装,设置为true;
  • Chart: Chart.yaml的内容。因此,chart的版本可以从 Chart.Version 获得, 并且维护者在Chart.Maintainers里;
  • Files: chart中的包含了非特殊文件的类图对象。这将不允许您访问模板, 但是可以访问现有的其他文件(除非被.helmignore排除在外)。使用{{ index .Files "file.name" }}可以访问文件或者使用{{.Files.Get name }}功能。您也可以使用{{ .Files.GetBytes }}作为[]byte方位文件内容;
  • Capabilities: 包含了Kubernetes版本信息的类图对象。({{ .Capabilities.KubeVersion }})和支持的Kubernetes API 版本({{ .Capabilities.APIVersions.Has "batch/v1" }});

Helm Chart 的基本知识如上,推荐读者前往 Helm Chart 的官方文档了解更多细节, 这些都是如何自定义FATE, KubeFATE安装的基础:

  • Chart:https://helm.sh/docs/topics/charts/
  • Chart Hook:https://helm.sh/docs/topics/charts_hooks/
  • The Chart Best Practices Guide:https://helm.sh/docs/chart_best_practices/

KubeFATE 架构以及渲染流程

KubeFATE的架构以及部署FATE的示意图如下:

KubeFATE 的服务部分,FATE 集群都部署在 Kuberentes 的环境上,需要可以访问,并有权限去操作部署 FATE 集群的 Kubernetes的kube-apiserver,一般会部署在同一个 Kubernetes 集群并使用 service account,具体做法请参考代码中示例,以及亨利笔记公众号上的系列文章。图中电脑为客户机,通过KubeFATE CLI访问KubeFATE服务的REST APIs模块进行操作。同时REST APIs也可外接其他管理软件,譬如 FATE-Cloud 作为一个组织内部的基础设施运维提供方。在 API 层下,我们使用了服务 Facade 的设计模式,并组合不同的服务接口。外部通过调用:

  1. Helm:也就是Helm 3的接口,主要做集群的部署,删除,升级等;
  2. Kubernetes APIs:FATE模块健康监控等。集群的信息,用户鉴权信息,渲染后的Helm Chart都会缓存在MySQL中。

从架构图可以看出,如果我们需要自定义部署的集群,譬如增减模块,集成第三方软件,自定义模块内容等操作,其实就是需要自定义部署的 Helm Chart。在代码中,我们提供了以下内容可参考:

  1. 每个版本都带有FATE与FATE-Serving的默认Chart,在:https://github.com/FederatedAI/KubeFATE/tree/master/helm-charts ,可通过Github的tag来切换不同版本;
  2. KubeFATE的CLI中有专门的Chart管理命令:
    • kubefate chart upload:上传新的Chart;
    • kubefate chart ls:列举KubeFATE中已有的Chart。上传过的Chart会按照类型与版本缓存在MySQL中;
    • kubefate chart delete:删除KubeFATE中已有的Chart。
  3. 我们的Chart内提供了Makefile来初始化和打包Helm Chart。一个建议是创建新的Helm Chart从我们默认Chart里修改。

在普通的 Helm Chart 基础上,我们做了另外一层抽象,也就是 KubeFATE 的渲染流程。拿 FATE v1.5.0 为例子,过程如下图:

我们kubefate cluster install命令传入cluster.yaml文件,里面包含了chartName以及chartVersion字段。在 KubeFATE 服务会现在 MySQL 中查询是否已经有对应的本地 Chart,如果没有会在FATECLOUD_REPO_URL中去查找。这个字段在部署 KubeFATE 服务的 yaml,也就是代码中的k8s-deploy/kubefate.yaml中定义。在部署 KubeFATE 时,可以选择自定义的 http 地址。在离线部署环境下,可以选择用kubefate chart upload上传需要的 chart 文件,或者按照Helm Chart Repository的标准 创建内部仓储。另外,因为 Harbor 符合 OCI 标准,可以直接使用 Harbor 作为私有内部 Chart 仓储,参考 Managing Helm Charts.

在 KubeFATE 服务找到部署需求的 Helm Chart 后,会读入。在原生的Helm 3基础上,我们多做了一层 template 的渲染。在 KubeFATE 中,cluster.yaml是用来供用户设置部署 FATE 什么模块,各模块的设置的。所以,每个KubeFATE的Chart中,会有一个value-template.yaml,我们还是使用标准的Go Template 为模板语言,渲染出标准Helm 3的value.yaml

得到用户自定义的value.yaml后,KubeFATE调用Helm 3根据value.yaml与Helm Chart template目录,创建出FATE v1.5.0集群。

总结一下自定义 KubeFATE chart 的注意点:

  1. 如果需要新建一个FATE, FATE-Serving的chart,建议拷贝已有的chart进行修改,保证value-template.yaml已经包含;
  2. cluster.yaml是用户的接口,需要考虑哪些变量需要透给用户。在决定一个变量往上透传到cluster.yaml,请保证value-template.yaml已经设置,可以生成合适的value.yaml,供Chart使用;
  3. 生成value.yaml后,就是标准的Helm 3的流程,建议熟悉Helm 3的Chart制作流程,本文没有提到的如 hook 这些功能也是可以使用的;
  4. Helm Chart 是一个社区,我们可以通过 dependencies 集成其它系统。也欢迎大家PR自定义的 Helm Chart 到 KubeFATE。目前 KubeFATE 的 Chart 目录为./helm-charts,PR 时可以取合适的名字作为文件夹放在该目录下。

需要加入KubeFATE开源项目讨论群的同学,请先关注亨利笔记公众号,然后回复 “kubefate” 即可。

相关链接

  • KubeFATE:https://github.com/FederatedAI/KubeFATE
  • FATE:https://github.com/FederatedAI/FATE

要想了解云原生、人工智能和区块链等技术原理,请立即长按以下二维码,关注本公众号亨利笔记 ( henglibiji ),以免错过更新。

欢迎转发、收藏和点 “在看”,或者点击阅读原文。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-02-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 亨利笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • (本文作者系 VMware 中国研发云原生实验室架构师,联邦学习开源项目 KubeFATE / FATE-Operator 维护者。)
  • Helm 3 与 Helm Chart
    • Chart 的文件结构
      • Chart.yaml文件
      • Templates目录 和 values.yaml
  • KubeFATE 架构以及渲染流程
相关产品与服务
联邦学习
联邦学习(Federated Learning,FELE)是一种打破数据孤岛、释放 AI 应用潜能的分布式机器学习技术,能够让联邦学习各参与方在不披露底层数据和底层数据加密(混淆)形态的前提下,通过交换加密的机器学习中间结果实现联合建模。该产品兼顾AI应用与隐私保护,开放合作,协同性高,充分释放大数据生产力,广泛适用于金融、消费互联网等行业的业务创新场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档