林帅康：云上构建容器化的科学计算平台

一般来讲，在云端构建大规模计算集群是难以实现完整的资源自治的。那么在计算任务运行容器化之后，应当如何进行云上构建计算集群并对大规模容器进行管理呢？请看这篇文章。

演讲嘉宾： 林帅康 | 晶泰科技云计算平台技术总监，2015年加入晶泰科技，主要负责晶泰科技高性能计算平台(majorana)的研发工作，专注于在公有云上通过mesos/k8s构建大规模的容器化高性能科学计算平台，以实现高效，低成本，灵活的云上超算系统。

我是来自晶泰科技的林帅康，今天我想和大家分享的主题是《云上构建容器化的大规模计算平台》。

晶泰科技(XtalPi)介绍

在讲之前，我会对公司有一个简单的介绍。这张图主要表现的是在药工业里面做一款药，从这个图可以看出，大概会经过七个大的步骤，会花费6-10年的时间以上，才可以有一款药真正上市。右边看，药最终到药监局审批的时候，可能需要临床实验，小白鼠或者更高级的临床实验。我们主要关注的领域不会在这里，主要是在前期的临床研究。在临床研究中，这是化合物的集合，我们需要从一万个化合物选择出250个可以符合临床研究的化合物，从这里再挑选5个精型出来做成一些药制，然后开始临床实验，最终才会有一款药真正上来，比如说可能是一个抗癌药物。所以这属于一个重磅药物，经历的时间周期比较长，毕竟生命还是很可贵的，做这种东西要非常小心才行。

晶泰主要致力于通过分子模拟平台以及药物动力学、剂型预测技术，减少在药物前期的研发周期，从6-8年可以减少到4-5年时间。它所依赖的技术，最右边会有量子算法，这主要是和科学计算相关，它可能会包括大家听说过的蚁群算法以及退火算法等东西。再结合AI的融合，最终这两部分会跑在超算的平台上面，例如我们熟知的天河2号或者新出的中国最大的超算中心。但是因为超算上面使用的资源可能会有申请的过程，而且使用量会有一定的限制，比如说一个小企业申请，有可能会限制只可用几十台或者上千台，比较困难。我们就会想到，现在云计算发展得非常快，很多企业已经从传统企业转换成云上企业，已经成功落地。能否把传统的科学计算移到云上面？当然，现在很多公有云平台已经在做，比较典型的产品可能是批量计算、高性能计算。我们把这两部分技术结合之后，借助腾讯云和AWS去构建一个大规模的HPC集群，可能会达到百万核实量级。核实在科学计算里面是一个通用的概念，主要衡量计算池的标准，和超算用浮点的计算能力是一样的，100万核实怎么换算？比如说每一台机器会有24核或者32核，1万个核需要300台机器，100万可能会到几千上万级的机器集群。

为什么会需要那么大量级的集群呢？这是我们的一个小分子药物的剂型预测流程，我简单介绍一下，大家有流程不清楚没有关系，我可以打一个简单的比方。左边是分子输入结构，你们可以理解为它是一个小的文本文件，里面包含了一些化学参数，描述分子的见长和角度的旋转。经过这个输入，我们会有一个结构的搜索算法，会产生亿级的晶体结构处理，也就是很大的输入池。我们区别一些大数据公司，大数据可能有几个T，或者PB级别的数据，在上面进行并行分析计算，而我们的输入很小，就是几KB，但是中间会产生大量的数据。我们可能还会经历在科学里面的能量筛选，以及基于CPU的聚合聚类算法，还有高精度晶体结构的排位，最终得到我们想要的能量式图的结果在里面。这个流程中每个流程都需要计算来支持，这个图是说每个过程中可能会需要多少量极资源在里面。前期的几个流程来看，需要的资源都可以在规模不大的集群里面满足需求。后面比较大，而且比较高，占据了计算的很大部分，这就需要我们借助云计算的云在里面，可能需要把多个云融合在一起，去构建一个比较大规模的资源池，在里面跑相关的计算任务。

计算平台演变

刚才的介绍是想说明未来支撑比较特别的场景，可能需要一个大规模的资源池的支撑。在构建这个资源池的时候，有一个计算平台演变的过程，这个演变过程就不放太多的架构图，稍微解析一下。我们公司从2015年成立的时候，也是从超算这边开始脱离出来使用的。当然了，我们第一代平台有一个PBS调度系统，一般跑在超算上面都会有一个任务调度系统。相对于K8s这种复杂的容器编排来说是比较轻量级的。

还有一个NFS，可能大家对此比较清楚。当然了，超算的NFS工程和我们自己建的NFS肯定不一定，它是高通量以及IOPS都是几十兆到上百万兆网卡的支持。我们第一平台很简单，都是使用开源的，在云上主结点搭建PBS几个G的内核就可以支持了，NS也是直接用开源的ABD Get一下，就可以产生一个挂载点，然后再挂几十台，这样基本满足了我们前期使用的需求。

但是随着业务的递增，我们需要计算量越来越大，这两个也有它们的局限性，例如有些资源利用率的不足以及LPS的性能不足，LPS压测可能会焊住以及假死等等状况。这样我们就会有第二代平台的迭代更新在里面，蓝色这边是我们开使用Mesos。我们2016年也有关注K8s，有一个简单的转型，但是当时K8s还处于比较早期的状态，而且也没有太支持批量计算服务在里面，我们就选用了mesos。当时mesos比较火，在国内有很多公有云都会根据它做一些第三方的插件调度软件之类，我们也会拿mesos来管理我们的集群。

2016年2月份，我们开始用mesos，以及开始我们的容器化之路，真正开始用Docker去封装一些高性能的计算算法。在2016-2018年这两年之间，基本还是沿用了mesos。中间这些都是为了去拓展、递增我们资源池的实力数，比如我们开使用竞价实力，一开始国内的竞价实力还没有兴起，会使用不同的类型，这两个也是出于成本的考虑，竞价实力以及多个实力类型的搭配可以降低我们的计算成本。然后用Golang去重构我们的调度系统，因为任务量比较大，用来只用排产，性能上面会有一些瓶颈。使用多个公有云厂商，也开始接触国外的谷歌、亚马逊，以及国内的腾讯云，我们有个多云资源弹性伸缩与监控，最终就会开始使用K8s集群去管理现在超算上面也能跑的任务。这里基本介绍了我们平台演变的历程。

下面是现在的三代平台技术站。上面是我们现有的计算产品，主要是晶形搜索服务以及高峰量、精度比较高的计算服务，以及最终产出的报告工具。中间是刚才说的我们自研的算法，以及融合现有算法进行二次开发、封装，打包成一个Docker镜像，业务人员只要去使用这个Docker镜像，就可以运行在超算上面的高精度的一些分子计算以及一些通用力场的计算。下面是支撑上面计算的平台架构的高性能平台，最上面就是云资源。

它的架构是这样的。左边是业务前端，我们使用的Jupiter的Web服务，Jupiter大量用于科学家在线编程以及机器学习。下来是我们对输入的文件进行一键化清洗和初步的分析，最终会到以对象存储以及其他存储空间组成一个数据壶，中间融合了一定的workflow操作在里面，业务人员随着提交任务计算，会不停的在每个阶段对计算出来的结果进行分析，再去重新生成新的任务。最右边是计算平台的架构图，有任务的管理、任务队列、中间件，例如使用一个MQ对接了不同云的集群，下面是某一个公有云集群，例如是腾讯云TKE容器集成在里面。当然，我们还是会有兼任mesos集群在里面管理。

腾讯云容器服务实践

这是我站在使用腾讯云TKE的场景去做一些讲解，没有涉及K8s太深入的东西。我会在使用腾讯云中做一个大集群构建时遇到的问题，也是大家可能面临过，以及通用的一些解决方法，希望和大家有技术上的交流。

需要说明一下，我们关注的更多是超算计算和现在做的服务发布以及编排，可能有比较大的差异。科学计算工作负载的特点，主要是计算是密集型，时间持续比较久。虽然时间比较久，但是还是一次性任务，可能会持续几个小时，几天或者几个一星期，最终有一个完成态的结果。它会追求算法的执行效率，算法直接导致了我们计算的成本，如果算得越快越准确，计算成本就可以压缩下来。它会以一些工作站以及超算为主，传统来说都是这样的，直到这几年超算开始搬上云，才有云超算系统。右边是信息服务的特点，K8s应用的主要模式。

容器镜像

云容器服务，我可能会分几部分来讲。一个是镜像，可能大家都使用过，但是对于超算，镜像会和大家平时使用的镜像不一样，可能会包含一些比较大的科学计算软件在里面，每个科学软件可能达到GB的级别，我们曾经打成一个包，可以达到10GB的镜像在里面，后面也有优化和分解，但是分解也有2-3G级别。

下面说集群空间以及集群扩容。扩容集群对于我们很重要，也是关于到成本的问题。因为我们扩容对于云服务还是要求比较苛刻的，我们要构建一个一台台到三台台24核的机器，要求在20分钟完成，有不停的任务去提交。而且在提交的过程中，我们要求这个集群里面的负载是达到80-90%以上的。

我们使用CI也比较简单，触发一个drone的CI，然后输入的SDK库，SDK库是我们一些科学家和量化工程师开发的专有算法，去打包或者其他软件，通过这个私有库下载到Docker镜像，根据Dockerfile去构建。拉取一些基础的镜像。然后把镜像同步了AWS或者腾讯云上面来，最终有一个发布通知的过程。右边有一个镜像分层的结构在里面，基础镜像比较熟悉了，第二块比较特别一些，有HPC Images在里面。我们会使用一些现有比较有名的二进制软件在里面，这些软件都是在固定的平台去编译的，有的有源代码，有的没有源代码，他们在固定平台编译的时候，因为云服务发展得比较快，例如腾讯云可能又推出一些新的机器类型，它的CPU指定级以及其他一些架构有变化，老的NEG系统跑起来，可能跑着跑着就会死掉，还有一个性能的问题，它可能没有用到一些优化的CPU指令集，比如说ABS的一些指令集，然后会导致效率上下降20-30%。如果大批量使用，这是很大的成本量。我们会针对不同的平台有智能化的构建，去适配不同的当前在腾讯云上面用的机型，以便它能对应在某一台机器跑的时候，不至于是跑了一个错误的镜像在里面。下面有一个工程的镜像在里面，就是刚才说的算法开发组上传的一些SDK，最终是Docker跑起来运行池状态。

镜像负载我刚才稍微解析了一下。有一些科学技术软件可能会达到GB的级别，打包几个进去可能就会达到几个G或者上10G的样子。我们可能会对镜像进行一些裁减，裁减完之后可能会有一个镜像预拉取，也会考察当前能否有一些方法可以加速镜像的拉取。因为我们最终裁减还会会有一些软件保留在镜像里面，所以在公有云这边，例如腾讯云提供的TKE来进行镜像任务编排的时候，有时也会发现大批量拉取的时候，镜像拉取比较慢，而且会有超时操作动作，有可能是云服务镜像仓库的问题，也有可能是因为网络的问题以及等等问题。虽然腾讯云已经在上面提供了自建的平台，但是我们也要看是否有一些优化的方案。现在是K8s集成云来托管，但是也许有一天我们可以提供A准的主机径下功能可以定制化开发的，我们可以改变参数。后来我发现，最新版的K8s已经支持动态修改Kubulet参数。

下面这三个参数可能会涉及到镜像拉取的性能以及并发率。第一是串行镜像拉取，通常情况下是forest，官方文档上面说，如果执行错，可能会对老版本的Docker以及使用NUSFS的后端存储会造成一些影响。我们现在平台上的Docker版本都比较新，这个参数开启可能会对我们有一些帮助。第二是镜像拉取超时，到底要设多久，可能和我们大镜像经验值有关，可能会有10分钟。Docker这边可能会有并发拉取的参数在里面，也可以去调节，加速任务分发时减少镜像拉取时间，尽快把任务跑起来，毕竟时间就是金钱。

讲完镜像，开始真正讲K8s集群的构建。我们当然是基于腾讯云服务器的TKE来构建，之前是叫CCS，现在叫TKE了。它现在的构建方式相对于之前我们自己手动构建的方式更加方便，基本一键就可以构建出一个带有Master的K8s小集群在里面，有点像集群即服务，我这个集群可以通过一种服务的方式提供出来，你可以随时删掉或者创建。腾讯云这边也打通了和其他每个一些云服务的服务，例如监控、hap、安全的以后一些服务在里面，用起来还是比较方便的。TKE会提供一个API出来，但是它提供的API主要还是针对一些服务编排，真正去做高性能计算的任务提交，我们现在还是用原生的client-go来做的。右边是一个K8s高可用的集群架构。

我们来看一下，现在K8s已经发布到1.11。现在它支持不超过五千个结点，在集群里面不超过1.5万个pod，以及不超过30万个容器，大概结点不超过100个pod。会有这些限制在里面。对应到我们的应用需求，我们当前的大概集群规模可能会达到100-3000个结点，可能大家会觉得这会小于它的结点数，应该比较安全。但是因为我们用的是大机器类型，每个机器都是24核或者32核类型，如果稍微拆小一点，用18核或者16核，可能机器数就会翻倍。

下面有一个红色标，这个pod数就会超出了它的限制，可能是1000-70000个pod。容器和上面相同，稍后我会解释为什么相同。pod单个结点一般会有1-24，我们目前是用24的机器。下面产生这个数据的原因有这么几点，我们的SBC单机的配置要求比较高，可能是24核或者32核的大机器类型，现在一个pod对应一个tast，就是一个pod会跑一个任务。我们最小的一个pod是多少？需要的CPU是一个核，24核在最极端的情况下会跑24个任务，就会有24个pod在跑，这样算起来就超过它的限制。我们还会有单次提交任务量比较大的情况，例如我们单次会提交10万个任务，如果你不控制任务提交速度，把10万个任务都提交到K8s里面去，即使资源都起来100台，但是已经有9万多个任务在等待了，这对它的其他组件是有一个冲击性的，特别是一些周期性查询的组件在里面。

我之前使用腾讯云，坦白讲还是遇到了一些问题，毕竟现在国内公有云上的K8s集群还相对来说不是完全的特别成熟，特别是面对我们这种使用情况比较特殊的，构建集群也比较大，任务队列也比较长，这需要有个定制化开发，或者慢慢去调试的过程。左边是我们遇到的一些问题，比如说Kubectl请求超时，推荐一个命令，加-V可以打印每请求一步请求到哪里，以及到哪里去超时，可以定位到相应的问题是请求到一个API还是别的地方。K8s调度严重延时，这也是因为任务队列过长的一个主结点集群性能下降，可能会有调度的退避算法在里面，即使Node上面有资源，但是这里卡住了，不会把相应的pod调进去。还有K8s-dns负载过高，如果每个pod里面都会有一个dns请求，就可能单次有上万个pod去跑，对K8s-dns去请求。因为K8s-dns还是比较轻量级的，它虽然有一个负载过程在里面，但是还有可能会拉垮它，API不可能开始出来，以及ETCD读取延时变大，因为提交任务比较大，每个任务通过job去创建，那么在ETCD上面就会有对相应的数据存储，以及ETCD可能还会有一个事件对象存储在里面。K8s容器网络不可用也是和其他相关的。

这边中间是我们和腾讯云这边有一个测试过程，发现了一些问题，刚才的导师也说针对一些特殊的任务，要做定制化Master集群的构建，要把大集群拆分，以及把Master配置上升，通用可能会上升到最顶配，32核或者是60G的内存级别。ETCD原来只是一些机械存储，也可以改成SSD的存储。etcduf的分离和读取时延时优化相关，数据拉取和数据事件响应可以分开，通过前面的负载可以保证Kubernete、Kubecontrol以及其他一些事件请求可以得到及时的响应。右边是我们自己做的调度系统的优化过程，尽量用K8s的job类型，因为经过测试，相比job类型，它在EDG上面存储的数据会多一些，数量比较大，可能就会有上G、上10G的差别在里面。我们也会控制任务的提交速度，我们之前也有考虑过这一点，但是当时也是比较信任K8s，所以一股脑把很多任务都积压上去，不用去管，让它慢慢去调度，保证整个集群都是一直高负载的，不然我们可能调度这边还要周期性轮巡当前K8s的自营状态。而我们从mesos切换到K8s这边，就是想不需要管控当前集群中结点的资源状况，我们只需要把任务提交上去，它就负责把我们的job合理编排到合适的结点上面去，以达到集群的高负载状态。原来mesos是一个二层的调度框架，第一层调度框架是把整个集群的资源返回给我们，我们开发一个二层调度框架，根据这些资源去匹配任务队列里的不同任务，去分发到对应的结点。这里会有一个装箱问题，这是一个非常难的问题，有几个箱怎么去通过装箱算法达到最高的利用率，K8s解决了我们部分的装箱问题，减轻了我们对资源式图的依赖。在Netwook host方面，一些批量的任务之间没有网络通信，都是独立的离线任务，它用容器网络和不用区别不大。DNS host方面，腾讯云的同事反映，访问外部服务时可以直接通过主机的DNS host就可以，不需要走K8s-dns。后面我们还有另外一些任务类型需要DNS host、K8s-dns来支持。这边主要是一些优化的点。

K8s官方也提供了一些构建大集群的辅助文档在里面，但实际上你在构建的时候还是会有形形色色的问题在上面是没有提及到的。

K8s主结点集成已经由腾讯云给我们构建出来了，接下来肯定是要添加计算结点在里面，通常情况下都会提供弹性伸缩组融合在里面。目前大多数都会实现了K8s官方的社区版实现。我们的要求主要出于节约成本的目的，一定要高度弹性的以及快速扩缩容，因为它会涉及到我们案例报告产出，我们有一个案例有一个周期，需要在特定的时间内输出这个报告。但是我一次性提交10万个任务，可能会要求几天之内要把这个任务算完，所以单次的弹性资源有可能是0-1000/2000个结点一起跑，然后跑完之后又从2000个结点缩放到0的结点，会有这种场景在里面。大概是这样子，也就是说我8点的时候就开始提交任务资源，从8：20提交得队列比较长在这里了，我们就会限制一个流控。稍微了解一下K8s弹性伸缩的原理，是根据pending pod的数目进行触发的。我们可能要求20分钟之内扩到4万个资源在里面，也就是2000台机子在里面。这个任务量比较大，算的时间比较久，可能从今天8点算到明天9点大概会算完，因为任务的输出很多时候都会有相似性，所以计算的周期相似，那么就会有一大批任务会释放出来。到这里就会有一个比较长的曲线在里面，这也会影响我们的成本，我们称之为长尾的任务，也是一个遗留的装箱问题，我们还没有实现K8s的重调度以及任务可重调度断点去算的功能在里面。

稍微提及一下，因为了解K8s的可能都会知道。刚才我们提到了扩容机制，可能调度失败的pending pod数量同我们配置伸缩组里面的配置，例如有一个1万个是调度失败的，那么我们现在配置的伸缩组可能就是每个机器类型是24核，它就会计算出相应的机器类型，会有分批的添加计算资源，达到调度的效果。缩容方面，目前官方文档也有一个触发条件，是当前Node一个（英文）的CPU可能会少于50%，K8s这边伸缩容不会考虑实际上的机器负载，主要是针对pod来调度，如果pod没有可调度的资源，它就会进行扩容，如果Node结点有一些CPU的（英文）值，例如24核当前只跑了8核任务，它也可能会触发调度，最终从三个结点把pod漂移到两个结点上面去，这种情况对于我们做HPC jop会有影响，我们HPC jop是一次性的，并不像服务可以随时漂移，它需要一次性算完就算完，中间如果打断，有可能浪费前面10个小时计算的机时。基于这种情况，我们会想怎么阻止pod被重调度漂移，官方提供了一些参数，例如在cistern上面的空间，这些pod不会漂移，还有一些外部存储的pod也不会漂移。但是我们不让它漂移，刚才有一个长尾的情况在里面，最终到9点的时候，因为这一千台机器的任务都是分散调度的，在调度时并不知道这个任务是多长多久的，最终会导致有一些长任务分布到每一台机器上面去，所以大部分任务跑完之后会发现有很多机器上面单独跑了一两个任务，每个任务可能就占8核，那可能每台机器有16核的浪费，有几百台机子都是16核，其余去等待几小时让它算完，就有资源浪费的情况。当时我们考虑支持断点续算的功能，断点续算在我们这边的实现原理也比较简单，可能说当HPC job周期性算的时候，我们有（英文）的动作在里面，把中间的结果保存下来，就像进程调度一样，有上下文压占和出占一样，就是说开个（英文）上传到对象存储，过了几个小时，发现有大批量的释放之后，整个集群的资源利用率会下降，这时候就可以触发这个重调度，把这些占用了结点资源，但是只是占用了小部分可以做一个漂移，它漂移到另外新的结点，就可以从对象存储里面把之前的上下文下载下来，重新开始它上一步计算。当然，这个重调度计算还是会有一定的机时在浪费，因为（英文）这边有一个周期，可能会浪费一个小时，我们通过这个情况缩短了它浪费的力度。这里主要是资源利用率的问题。

搞定了集群的构建以及快速的扩缩容之后，就开始提交任务。稍微解释一下，现在高性能迁移的任务过来有哪些。从时候维度来看，分短时间任务和长时间任务。当然，其实它对应的具体实现算法可能是只要在单结点里面跑就OK了，还有需要多个结点协同去跑的，比如说那些流体计算，可能一个任务拆解成了几十个小任务，需要在几十台或者上百台机器上面去跑单个任务。二是低精度和高精度任务。在药物计算里面中会有精度要求，从右边图来说，不同的科学计算软件对于输出进行不同的算法计算，会有一个精度的差别，也会反映在时间上面。往往低精度的算法要求的时间比较低，但是高精度算法比较耗机时，使用资源量比较大，最终计算的精度就比较高一些。上K8s，我们选择过用developm还是用job类型，我们曾经用过developm来做，但是对于K8s主结点还是产生压力比较大，job类型在今年算是比较成熟的类型了，也是面向高性能计算来定义的。我们的任务类型从核数来说，分为1、2、4、8、16核，也是为了实现装箱的问题，提高资源利用率。当然，可能还会从其他维度来分，它是一个计算型，里面可能又分为计算需要的内存比较大一级计算需要的存储比较大。当然，目前大部分都是普通的计算型，就是说存储和内存一般按机器分配1：2，比如说按4核来说，就会有48G内存，1：2就OK了。右边是我们现在使用到的job类型，可能看得不太清楚，里面会有红颜色标志下来比较重要的参数。我们会用到一些外部挂载，例如腾讯云的CFS这种情况，还会用到一些Docker或者K8s默认的内存共享会比较小，比如说几十兆、上百兆，其实有的科学计算软件可能需要几百兆共享内存，如果运行池比较小，就会导致宕机，目前我们会通过某些解决方案让它扩大，我们之前也在K8s上有提及这种方案，挂载了外部一个Net host进入里面去充当共享文件存储，但是往往挂载的是一个的文件类型，会导致pod无限重启的问题，有待后续开发方面有更新的支持。任务装箱现在主要是依赖K8s，我们后期也会考虑有一个对等调度K8s支持的定制化调度，这样K8s本身的功能会退化成资源的管理者，有点像回到了mesos开发模式在里面，但是它提供了其他的特性，我们还是可以用到，例如它的容器网络以及一些外部可插拔的硬件，例如一些GPU、IP网络或者是一些高性能的网卡。然后是job的生命周期管理，这比较简单，每个job都会有一个生命周期管理，我们定义成它是一个rending或者是被杀死、休眠状态以及被（英文）状态，最终会反映到我们的队列数据库上面，它是实时和K8s的job pod状态去同步的。

这边是一个单结点的任务定义，下面说我们现在支持的HPC多结点并行的任务。了解过高性能计算的人，都会通常意识到现在一些公有云的普通网络没有办法满足MPI数据并行任务。MPI需要一个高性能的网络，可能是几倍、几十倍的万兆网卡，需要一些专有的网卡去支持远程的直接内存访问。通用的概念是，有两台机子，这台可以通过网络去访问那一台的内存，就像我在本机访问的速度一样，延时是非常低的。当然，这需要一些专有的网卡。运行任务的运行周期会相对长一些，右边是我们在K8s实现的MPI任务。刚才提及现有的TKE提供的网络没有达到通用的MPI的网络要求，但是我们会其中筛选出一些可以在云上面跑的MPI任务。它们结点之间的数据交互通常是比较少的，这样它们走的网络数据传输也比较少，这样就可以避免高性能网络的限制，但是还是会有很大的局限性，在网络发展里面肯定会接触很多流体力学计算在里面，现在这种情况是没有办法满足的。但是刚才看老师的解析，我们也关注到现在公有云陆陆续续会上一些裸金属的机器在里面，机器上面会配备一些高性能的网卡。并且K8s这边有一个叫做（英文）插件支持的机制在里面，可以直接把RDMA网卡或者其他高性能的网卡插到上面去，跨过了OS以及TCBIB网络层，可以实现低延时的数据分发在里面。右边这个图是InfiniBand性能和百兆网卡性能（英文）区别，可以看到它的测序是OpenMPI以及MPICH两个开源的MIP库，右边时间明显比左边时间长很多，因此它是依赖于高性能网络提高计算效率的。可能大家还是接触比较少，我稍微提及一下。

任务的性能监控刚才已经提及到了，容器云这边已经提供了比较健全的服务监控。当然，我们可能会出于一些其他的需求，需要实时监控pod CPU以及内存。目前不会去监控网络吞吐，所以我们也会搭一个heapster+influxdb+grafana开源架构在里面，去收集我们想要的信息，去对比算法版本更新的时候会否导致CPU的运行效率下降和内存变多，但是因为任务量比较多，所以存储的数据会比较大。

下面有个kubelet10250端口的参数，我们之前碰到一次，刚刚创建集群的时候，在安全组上面太粗心大意了，没有把计算结点10250端口封掉，导致会被人家入侵，因为它开启了enable-debugging-handlers=true 的情况下，外部可以直接通过这个端口，到pod里面进行集群调试，我们发现有人通过扫描机器，在上面跑了一些外挂程序。大家使用的时候稍微注意一下，官方已经有一个PR在里面。

日管理依赖腾讯云，对接了Kafka和ELK，不详细说了。前面是腾讯云的容器服务实践，遇到了一些痛点。腾讯云容器发展得还是比较快的，但是它也不可能覆盖所有的应用场景，通过我们和它的合作，一是满足业务的需求，一是可以推进它更好的做一些比较少见的服务，例如高性能计算，在这方面可以完善得更好。

未来规划

下面是我们对未来的一些规划。我们也比较关注云容器实例服务，这已经在K8s TKE层面上再推进了一步，集群的主结点创建和弹性伸缩都不需要管理了直接通过腾讯云这个接口提交相应的任务，上面就可以跑起来了。所以这方面落地更加方便一些，serverless lambda大家也比较了解，在高性能应用中也会使用到，一些比较小的排位任务，可能是一分钟的任务，但是它有几百万量级的东西，就可以通过serverless lambda来实现。完善的作业工作流管理刚才在架构图中也提到过，对于一些复杂的预测流程，任务之间有严重的依赖关系。例如这个图中，job2、job3、job4是依赖job1的输出文件作为输入文件，后面的job5、job6也是依赖前面文件的。如果中间有一个任务出错了，在开发的过程中可以重走这个工作流去，节省到前面几个任务的计算流程直接到job6，继续往上面走，继续修复以及类似的循环这样去做。

我就大概介绍到这里。