腾讯业务及组织架构现状
先简略和大家介绍一下腾讯外部的业务及相干组织架构的现状，有助于帮忙大家了解为什么咱们会基于前面的架构来设计整套计划。
下图的利用大多数人常常会用到，比方微信、腾讯视频、游戏等等 APP，其背地承载的技术也不尽相同，波及了 NLP、计算机视觉、强化学习、语音等不同的 AI 技术。
比方咱们玩的《王者光荣》或者下围棋，背地所对应的就是用强化学习训练进去的一个机器人，玩游戏没有队友陪同时，机器人能够满足咱们对战单干等游戏需要。
不同的业务部门，APP 对外需要也不同，均会针对本人的业务场景做一些 AI 平台的定制。咱们做的是底层算力，给业务部门提供服务时，在思考整体资源利用率的状况下，也要为各业务便捷地去做些定制服务，这就是腾讯外部的一个多租户的现状。
业务特点与规模
接下来，介绍一下腾讯外部业务的一些特点以及大略规模。
目前的环境是基于开源我的项目 TKEStack，TKEStack 是腾讯私有云 TKE 的开源版本，是一个开源的容器云平台解决方案，用的 KubernetesV1.14 版本，操作系统是腾讯自研的 Linux 操作系统，曾经为 GPU 或者腾讯外部业务做了一层性能的调优和 bugfix。
GPU 节点是 NVIDIA 的 V100、P100，个别会有一些 M40 的机器。网络联通应用 100G 的 RoCE，既可能提供以太网的反对，又可能提供 RDMA 的网络协议反对，对于用户去做一些多机通信的优化有事倍功半的成果，也从硬件层面保障了整体的应用效率。
残缺流程设计思路
接下来介绍一下咱们是怎么欠缺、开发以及设计这一整套流程的。
Kubeflow 是什么
这里先介绍一下对于 Kubeflow 以及 Kubeflow 外面一些次要的组件，帮忙大家了解其中的一些具体业务，或者设计。
Kubeflow 是什么呢？
Kubeflow 自从 2017 年底公布，目前逐步成为支流的在 Kubernetes 下面跑机器学习、深度学习等训练或者推理工作的次要工具。
Kubeflow 蕴含十分多的组件，比拟多的像 Operator，或者像主动调参的工具。
Operator
先介绍一下 Operator，它是 Kubernetes 中的一种概念，次要是用来打包、部署以及治理用户的工作。但在 Kubeflow 外面，Operator 次要用来治理机器学习或者深度学习外面的工作。
那么它能帮用户做什么呢？
比方在多机的工作上面，如何去治理和保护一个工作的多个节点，以及之前通信是怎么做的，怎么可能帮忙用户治理整个 Pod 以及工作的生命周期，比方某一个 Pod 失败了，整个工作是终止还是有一些其余的容错方法，这个都是由 Operator 来实现。
目前支流的 Operator 有几种，会对应每一种框架。比方用的最多的 TF-Operator，次要对应的是 tensorflow，MPI-Operator 次要对应 Horovod，Pytorch 和 Caffe2 的 Operator，它们针对各自的框架都有一些定制的场景。
这里着重介绍两种 Operator 以及咱们对它做的一些重点优化，也是咱们用的比拟多的两个 Operator 以及框架工作。
MPI-Operator
MPI-Operator 是为了 MPI 的工作或者 Horovod 的工作提供一个多机的管理工作。它有 V1 α1、V1 α2 以及 V1 的版本，V1 正在大规模开发中，所以咱们举荐用 V1 α2。将来 V1 release 之后，能够举荐应用。
在这种版本上面，它有两个概念：一个 Launcher，另一个是 Worker。Launcher 相当于一个启动器的角色，它会等 Worker 都就位之后，去启动 MPI 的工作。然而在这里，Launcher 自身就会占用一些 CPU 的资源，其实咱们是能够将它合并到一起的，也的确做了一些改良并提交到社区，去掉一些无用的 CPU 的 Pod，让某一个 GPU 节点起到这种角色。
此外，为了晋升 Pod 的创立速度，以及晋升 Job 的启动速度，咱们也做了一些优化。
比方 Launcher 在期待其余 Worker 就位的时候，是从其余 Shell 脚本的版本变成了多线程的工具，能够极大晋升整体的等待时间。
除此之外，比方再减少一个额定的 init container 去下载用户的 docker 镜像，这样来做 docker 镜像相似于并行加载这种形式。
咱们举荐是间接参照 Kubeflow 的 MPI Operator 的 GitHub 去查看更多的详情，大体的流程也在上图右侧展现进去，次要是将 MPI Job 换成对应的 Kubernetes 能够辨认的一些资源，比方应用 CRD、应用 Configmap 以及 RBAC 管制权限等等。
TF-Operator
除了 MPI-Operator，还有另外一个用得更多的是 TF-Operator，TF-Operator 次要就是帮忙用户启动多机的一个 PS-Worker 这种架构的状况下的一个多机的工作，因为这个集群全副是 GPU 相干的集群，所以咱们举荐用户是将 PS 和 Worker 放在一个 Pod 外面启动，缩小一些通信的老本。
除此之外，咱们还做了一些额定的优化。比方像就近部署的计划以及脱库调度的计划。为了放慢 image 加载的工夫，也是用 IfNotPresent 这种形式去放慢整个的速度。
目前 TF-Operator 还是比较完善的，其余各家公司也都会有比拟多的投入。
多租户场景下应用 Kubeflow 构建训练平台
介绍完 Kubeflow 目前的一些 Operator，言归正传，明天的主题也是多租户的场景上面应用 Kubeflow 构建一个训练平台。
惯例构建计划
先来看一下目前 Kubeflow 的多租户平台是如何构建的。
目前，在这个平台有两种形式，一种是用原生的 Kubernetes RBAC，就是 Role based access control 去做权限的管控。另外一种是应用 Istio，Istio 这种形式更偏差于推理场景。通过这种形式对用户的拜访进行一个管制。
能够简略来看这张图，当咱们为用户提供一个集群，个别有两种形式。一种是通过命令行的形式应用，另外一种就是提供 Web 端，Web 端通过 Istio 的 gateway 接入整个集群，而后 Istio 的 RBAC 去做权限管控、去做流量的散发、去保护整个集群的权限。
另外一点，如果是客户端，除了集成的客户端，另外还引入 Kubernetes 的 RBAC 去做容许或禁止，帮忙用户解决权限管控的问题。
但它有一个小的问题，就是所有的用户都会共用所有这些资源，像 Operator、Controller，用户只能应用定义好的资源，比方咱们设计好一种 Job 的类型或者 Operator 的类型，那么用户就必须这么应用。
然而对于多个事业群，大家会有一些自定义的需要或者定制的 Operator，在这种场景下，就会有些顾此失彼。为此，咱们也引入了一些其余的形式改善这种需要。
优化构建计划
用户分层
当初咱们做的多租户的 Kubeflow 训练平台，首先在资源层将 GPU 资源汇集到一个或多个集群，在此 GPU 集群之上提供多个用户的集群，也是 K8s 的集群。用户能够通过 Virtual Kubelet，而后接入到底层的算力集群，分成两层：
- 在用户的集群，这些租户的管理员去治理或者去创立，去本人定义一些 Operator 或者 Controller，用户接入的是这些租户的 K8s 原生的 KPI；
- 在底层算力集群，咱们对立集中调度，晋升资源利用率。
当有工作下发的时候，通过 Virtual Kubelet，或者用 Kubernetes 实现的 Virtual Node 转发到算力集群，在底层算力层面而言，能够通过 Namespace 隔离不同的租户以及不同租户的工作，将一些特定需要的节点划分造成一些小的资源池，更多就是通过 Namespace 进行隔离。
然而对于下层用户而言，他们有一些自定义的权限，也能够本人开发一些本人的组件，相当于将权限分来到。
咱们这里实现的 Virtual node，相当于用 Virtual Kubelet 实现的，Virtual Kubelet 相当于 Kubernetes 下面一个开源的 Kubernetes kubelet 实现，最开始是由微软的一个团队开发并保护，后募捐给了 CNCF 成为 sandbox 的我的项目。Virtual Kubelet 前面是能够接入像 ACI、AWS forgate、IOT 等等可扩大的组件或者服务。比方 OpenStack 也是能够接入的。
而咱们这里其实相当于接入了一个新的性能，它是一个比较简单的，次要定义为用户有一个 Pod 下发申请或者有一个其余资源下发申请，咱们间接转发到底层的一个 K8s，同时 Virtual Kubelet 也会监控底层它关注的资源状态，并将状态汇报给下层，它相当于一个桥梁的作用，承前启后去同步整体的状态。
这张图就是一个比较完善的用户的集群或者用户的一个架构图。在左侧有用户的集群，对应的是通过 Virtual Kubelet 连贯到底层不同的算力集群，这些算力集群都是有 GPU 资源的算力集群，也是 K8s 的集群。
如果用户比较简单，能够间接接入咱们举荐的组件，造成一个整体的简略管控策略。比方用户想跑一些工作，以及有本人的 controller 去定义整个的规定，其实能够接入像 MPI-Operator、TF-Operator 等 operator 资源。
这里也多提一句，当用户下发一个 MPI 的 Job，MPI-Operator 就会转换成像 Configmap、Secret，像 RollBinding，以及像多个 Pod 这种资源。
当这些转换产生实现之后，Pod 通过调度器到具体的某一个 Virtual Kubelet，Virtual Kubelet 发现资源到本人的节点后，会将其转发到具体的某一个 Kubernetes 集群，并关注这些 Pod 或者其余资源的状态，造成整个的一个转发和传递的成果。
对于下层集群的管理员，不再须要关注底层集群的状况以及权限管控等，只有关注上一层即可。底层的管理员须要关注更多整体资源的应用状况，造成上上层的拆散。
晋升资源利用率
介绍完上上层拆散以及怎么做多租户这种场景，转到咱们之前提到的集群全副资源归集到一起，次要指标是为了晋升资源的利用率。当整个资源买通当前，怎么晋升资源利用率？而且通过后面介绍的多租户的机制，让用户也不必感知到。
在深度学习或者机器学习场景下，大部分工作都须要批量调度性能，也就是须要保障多个 Pod 同时地调度。它次要算法就是 all or nothing 的算法，保障整个资源要么能够调度，要么就不要调度，如果无奈调度那么就排队，保障整个资源不会被饿死。这是一个比拟常见的需要。
这外面次要是用 volcano 去做 gang-scheduling。
引入工作优先级
除此之外，咱们也引入了一个优先级的工作。顾名思义，就是咱们给每个用户或者每个租户都凋谢高优先级的工作，他们能够在一个固定工夫之内被调度。当整个集群的利用率不太高的时候或者调配还有一些空间的时候，就能够开发一些低优的工作给用户，用户能够提交整个的弹性工作或者叫低优的工作。
这种工作下发下来之后，就能够以低优的工作占据这些闲暇资源，当高优工作下发的时候，就能够抢占这些低优资源，保障整个资源池是最满的状态。
策略优化
最初一点是一些优化的策略，如基于网络拓扑架构或者 GPU 的拓扑架构的拓扑调度或者应用 binpack，缩小底层集群的碎片，保障更多的资源是能够尽快被调度的。
其余的优化，如晋升 MPIJob 的一个启动速度，可能尽快地将工作下发上来，将底层闲暇的算力资源变得越来越少。
除此之外，家喻户晓，咱们跑 GPU 工作个别都会用 nvidia—docker2 版本，咱们剖析了一下，其实 nvidia—docker2 对应的版本，它的 Pod 启动速度相比于个别的 runC 的这种启动速度还是慢不少，剖析起因，次要集中在每次启动的 Pod 或者 container，它都会去查问 CUDA 或者 Nvidia 驱动的版本对应的信息，而后供 Nvidia Container 的 CLI Prehook 去操作。
然而在咱们场景外面，其实不太能用得上，因为咱们是一个公有云的平台，公有云的平台外面不波及特地多的常常更换硬件或者驱动版本常常变动的场景。所以咱们能够简化。
怎么简化呢？最简略一种方法，就相当于将 CUDA、INVIDA 这种驱动信息全副缓存下来，而后保留到某一个固定的文件，当机器重启或者将驱动变动，CUDA 的版本发生变化的时候，才会从新触发这个动作，获取更新的信息缓存下来，这样能够大大减少每一次 Pod 创立的时候都会获取这些信息的次数。
这个信息的工夫，如图中所示大概在几百毫秒。
通过这样一个优化，咱们是 能够将整个 Pod 的启动工夫晋升大略 30% 到 40% 的工夫。对于用户体验还是十分敌对的。
当然这个只能说做几百毫秒的优化，像深度学习的场景，CUDA 的版本、Nvidia 的版本，Nvidia 驱动自身就比拟大，所以如何可能优化这个 docker image 的加载，或者可能缩小它的镜像拉取，做一些预散发、预部署，这个也是咱们十分关注的一点。除了一些调度层面能够做的事件，其实业界也有一个比拟风行的形式就是做一种提早加载。
docker image 是分多层的，以及它分 metadata。考察发现，基本上大多数的镜像外面的内容个别不会被用上，能用上的也就 10 到 20%。
咱们做一些提早加载，当它在用的时候才去加载，当然这个也是一个比拟前沿或者工夫性质的性能，咱们也在重度参加。前面有一些停顿，大家能够继续关注咱们，会一直和大家来分享。
总结
基于 kubeflow 目前的架构或者一些现有的组件反对多租户以及一些前面优化的策略，为了晋升整个用户体验，咱们其实还是有很多工作去要去做。比方当初比拟风行的弹性训练任务，像基于 kubeflow、基于 horovod 自身的能够动静伸缩，去占用更多的资源，可能缩小用户的训练工夫，都是十分要害的。
另外一点，MPI-Operator 自身 V1.0 的版本咱们也在重点参加，心愿它能尽快被 release。
参考
- Virtual-Kubelet: https://github.com/virtual-ku…
- MPI-Operator: https://github.com/kubeflow/m…
- TF-Operator: https://github.com/kubeflow/t…
- Nvidia-docker2: https://github.com/nvidia/nvi…
- Tensile-kube: https://github.com/virtual-ku…
- Learn more about TKE: https://cloud.tencent.com/pro…
- Jobs: https://careers.tencent.com/h…
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！