因文章略长，故分为三篇展开呈现，本篇为最后一篇。

workflow引擎设计与实现

为什么要去做Tencent Hub的DevOps引擎呢？因为很多客户在上云的时候遇到了操作重复性的问题。而且DevOps的自动化要求还很高，再照顾到一些客户的需求，因此要做一个DevOps的工具，去帮用户来建立自己的DevOps流程。

这就需要考虑很多事情，第一，把DevOps任务编排起来，需要做到一个能尽量覆盖到尽多客户DevOps需求的编排逻辑，比如Workflow；第二，DevOps任务是差别较大，需要把这些任务交给客户自己去完成，需要设计一个插件机制Component；第三，用户的DevOps流程运行在Tencent Hub里面，需要做很简单的任务调度，最终还是选择Kubernetes来省去很多运维工作，监控都可以去复用。

按业界通用的方法把workflow设计成三级结构，每个workflow包含多个stage来完成，每个stage里面会有很多job。job这里会有并行和串行的执行方式。stage有一个类型叫past+prst。在DevOps流程当中，在合适的时候是需要人工介入的，设计可以暂停的stage就能适应这样的场景。

workflow的设计生命周期对流程推动十分重要。workflow可以被触发执行，有三种方式。一，把某一条workflow和代码关联起来，当提交代码的时候，可以触发这条workflow的执行；二，可以和Tencent Hub的镜像存储关联起来，不需要代码去触发，可以通过push一个镜像去触发；三，通过调API直接触发某一条workflow。

被触发后，就可以系统把它置成一个pending状态。Workflow被触发执行，一个新建的workflow实例被置于pending状态，经过配额检查，scheduler调用k8s API执行第一个job，workflow实例进入scheduling状态；StatusFetcher检测job在k8s中的状态，如果不是pending，workflow实例进入running状态；

Scheduler遇到可暂停的stage(type=break)，待stage中任务执行成功后，workflow实例中的job被暂停调度，workflow进入paused状态，等待外部API调用唤醒workflow的执行；end是一组状态的描述，实际上包括timeout、failure、success、canceled四种状态。处于paused状态的workflow可以被终止。

workflow上job在设计时需要考虑四点。第一，job可以都考虑成一个函数去处理输入，在内部做一些业务逻辑，通过定义的标准输出处理完的信息；第二，job可以从workflow全局环境变量中去读取，传进来做一些逻辑。第三，每个component都需要和外界接触，因此workflow里会去提供cache和artifact指令。第四，workflow没有办法去循环执行，只是一个DAG构成的关系去一条一条向前执行。

关于artifact和cache的实现和作用是不同的，设计Cache是用来在不同的job之间共享和传递数据；Artifacts则可以保存在提供的仓库里面。Cache的具体实现如保存文件夹，它会把指定的文件目录进行压缩，上传到Tencent Hub的图形存储里面。当下面有一个Job依赖它的时候，会在Component内部下载下来。

为什么要选择用容器来做DevOps呢？第一，面对的所有用户是公共服务，隔离性是第一要务。用容器可以非常方便的帮我们实现不同用户的任务隔离，有些用户可能对自己任务的安全性要求非常好，后期还会考虑和CIS做结合，直接用Clear Container来提供更高的隔离性。第二是复用，在不同的部门之外，它们的技术段可能会有相似的，后台有一些公共的DevOps任务需要去使用，通过容器Docker镜像可以共享这样的逻辑；第三则是标准，组件的开发维护可用本地Docker进行测试；第四是平滑，从而能让已有的DevOps任务可通过容器快速进行封装。

Component函数一样会有涉及到Input和Output。Input方面，输入值以环境变量的方式传入到Component中，包括workflow全局变量和上游Job的输出变量；而output方面，输出值写入到stdout，workflow通过分析日志进行提取；输出值格式为: JOB_OUT key=value ，可以通过输出多行Log来输出多个值；Component进程执行成功后以状态码0退出。

Workflow是采用了TKE去执行的，选择用DevOps做workflow引擎的执行集群是基于以下三大特性考虑的。首先，Kubernetes的可靠性使得TKE非常可靠，从而不必去担心运维难题；第二，workflow跑的很多任务可能会占用不同的资源，而TKE可以做到自动扩缩容，能为客户提供构建的能力，不需要人工介入；第三的资源分配更灵活，客户的workflow资源占用大小不同，这对Kubernetes来讲解决并不难。

关于job的两个hook，在实现的时候需要注意到这些事情。Flow引擎通过分析Component的config，保存Component定义的Entrypoint和Command；实现CommandWrapper程序，Job运行指定该程序为Pod的Command；CommandWrapper启动后处理PreStart动作，如下载依赖的Cache；CommandWrapper fork子进程运行Component定义的Entrypoint和command；子进程退出后，CommandWrapper处理PostStop动作，如上传Artifact、Cache等；最后，CommandWrapper以子进程的返回码作为返回码退出。

每一个构建的workflow的job需要去关心它的Log。Job是一次性任务，利用k8s api读取日志，比独立的日志收集通道更简单；dispatcher读取日志之后，使用multi writer将日志交给StatusFetcher保存，同时可以通过websocket将日志推送给web页面。

到此，workflow引擎实现和设计就基本完成。通过Tencent Hub，经过思考，如何搭建自己的DevOps流程是千差万别的，以上方法站在公有服务的提供商角度，考虑给用户最大的便利而建立的一套工具。

云上构建容器化的大规模计算平台

看了这么多的技术解析后，那么究竟腾讯云的容器技术在其用户的手中是怎样的状态呢？晶泰科技是腾讯云在药物工业领域的合作伙伴，他们在云端部署大规模科学计算平台与腾讯云有着紧密的合作。

晶泰科技是一家以计算驱动的创新药物研发科技公司,在药物工业中，一款药的上市需要经过复杂的研发工序以及10年以上的漫长研发周期，而且越是重磅的药物，经历的周期就越长；因此腾讯云的合作伙伴晶泰科技致力于通过分子模拟平台、药物动力学等技术，借助云端大规模HPC、AI驱动、量子算法等预测技术，提升药物工业中临床前期的研发效率,为患者带来更优质的药物。

科学计算平台通常是跑在像天河这样的超算上, 但超算上大规模资源的申请需要排队, 对任务的调度管理, 数据存储都不太灵活, 而且在计算性价比上优势也不明显，综上我们提出, 能否把传统的科学计算搬到云端？目前一些批量计算、高性能计算已经迁移到云端。在把两部分技术结合之后，借助云端去构建一个大规模的HPC集群，可能会达到百万核实量级，可能会用到上万级的机器集群。

晶泰科技的小分子药物晶型预测流程中，需要用到构像分析、力场训练、晶体结构预测、结构聚类及排位算法等，每个流程都需要大量计算支持，而且越靠后计算需求越高这就需要借助云计算，甚至需要多个云融合在一起以便构建一个比较大规模的计算资源池，在里面执行大批量科学计算任务。

计算平台演变

计算平台在这几年发生了较大的变化。从2015年晶泰成立的时候推出了第一代计算平台，基于PBS调度系统以及NFS文件共享存储，架构上类似于超算的PBS/LSF+SAN。系统都是使用开源组件搭建，命令行方式对任务进行提交及管理, 基本满足了前期使用需求。但是随着业务的发展，计算量需求越来越大，而第一代平台的计算资源利用率不足、PBS动态管理能力有限, 以及NFS的IOPS压力等问题开始出现。

从第二代平台的迭代更新开始，我们使用Mesos对资源进行管理，自研Mesos的Framework, 使用Docker打包科学计算的软件以及算法, 从此开始了云上科学计算的容器化之路。通过添加不同的计算资源, 计算池得到了进一步扩大。当我们单个资源池突破1000台机器时, 我们使用Golang重构了调度系统，以便支持更高性能的任务分发。接着我们通过接入多个公有云厂商，实现多公云资源弹性伸缩与监控。18年开始, 随着k8s的高速发展, 调度平台也正式开始使用K8s去管理云上的超算集群。

第三代平台技术产品上主要是CSP, Faces晶型预测系统服务，以及最终产出计算报告的全自动工具XtalVision。第二层主要是是预测流程中使用到的各种核心算法，融合了现有的科学计算算法进行二次开发、封装，打包成一个Docker镜像，业务人员只需要去使用这个Docker镜像，就可以在平台上提交对应的预测计算任务, 如一些能量计算以及一些通用力场的计算。然后是我们支撑大规模科学计算的高性能计算平台，最下面就是公有云的基础资源。

腾讯云容器服务实践

需要注意的是，超算和信息服务的计算有较大的差异。科学计算的特点是计算密集型，计算时间长，通常是异步计算，追求算法的执行效率并行化，主要以工作站或超算为主；信息服务的特点则是IO 密集型，低延时高可用，利用架构提高系统容量及服务质量，大量使用云计算。

在开始之前我们简单介绍一下在云上构建科学计算的镜像, 科学计算使用的镜像跟服务化的镜像会有一些不太一样的地方, 一般科学计算的镜像大小会达到GB级别，因此需要对镜像进行剪裁和分层优化，以便加速镜像拉取速度。

下面的参数会涉及到镜像拉取的性能以及并发率。如:kubelet --serialize-image-pulls=false是串行镜像拉取，通常情况下是false，如果设置为true，需要更高版本的Docker支持, 同时docker storage需要使用overlay作为镜像存储。kubelet --image-pull-progress-deadline=10mins是镜像拉取超时， Docker本身也会有并发拉取的参数在里面(如:dockerd --max-concurrent-download=5)，以便在任务分发时减少镜像拉取时间。对于kubelet来说, 目前最新版的K8s已经支持动态修改Kubulet参数。

腾讯云的TKE容器服务，基本实现了一键就可以构建出一个带有Master的K8s集群。同时腾讯云打通了TKE和腾讯云其他云服务交互通道, 更易于系统的快速集成。TKE会提供一个容器服务API出来，但是它主要还是针对一些信息服务编排, 对于高性能计算批量提交任务还不是特别适用, 因此我们使用了k8s原生API进行平台构建。

现在K8s已经发布到1.11版本，支持不超过五千个节点，在集群里面不超过1.5万个pod，以及不超过30万个容器，单个节点不超过100个pod。K8s官方也提供了一些构建大集群的辅助文档在里面，但实际上在构建的时候还是会有形形色色的问题。

K8s主节点集成已经由腾讯云构建出来，接下来需要要向集群中添加计算节点，TKE提供了弹性伸缩组对集群资源进行动态扩缩容。但出于节约成本的考虑，伸缩组需要是高度弹性, 可以快速扩容大批量资源, 同时也能在任务计算完成时快速回收资源。比如晶泰就会有如下业务场景:

平台一次性提交10万个任务，每个任务需要8核的cpu去计算, 同时由于案例时间上的要求, 要求几天之内要把这些任务算完，所以此时需要让资源池从0扩容到1000/2000个节点一起跑。任务的计算复杂度很多时候都是有相似性的，因此计算的周期也比较相似，某个时间点就会有大批任务同时跑完, 大批量资源被释放出来, 这个时候又需要快速回收资源。经过与腾讯TKE团队一起排查, 目前基本在快速扩缩容这块满足了计算的需求.

到目前为此利用TKE构建了K8s集群并通过其快速弹性扩缩容组件实现资源的管控, 接下来我们看看计算平台上所支持的HPC任务.

简单地从时间维度来看，可以分为短时间任务和长时间任务。从精度来看可以分为低精度和高精度任务。在药物分子预测中的能力/排位等流程中都会对精度要求有，从右边图来说，不同的科学计算算法在不同的流程中都会有一个精度及时间的差别，通常精度越高需要的计算周期越长。

在支持的HPC多节点并行任务中，一些公有云的普通网络是没有办法满足像MPI这种多节点并行任务的。通常MPI任务多节点需要有一个高性能的网络, 如IB网络，需要一些专有的网卡去支持远程的直接内存访问(RDMA)。

MPI任务的运行周期会相对长一些，右图是在晶泰基于K8s实现的MPI任务。刚才提及现有的TKE提供的网络没有达到通用的MPI的网络要求，但是一些数据并行化的MPI任务还是可以在一般性能的容器网络上面进行运算。它们特点是节点之间的数据交互通常是比较少的，这样网络数据传输也比较少，能避免高性能网络的带宽限制。其实k8s对构建高性能容器网络也提供了插件支持, 通过k8s Device Plugins可实现NVIDIA/AMD GPU及RDMA/Solarflare等外部组件接入。

容器云TKE提供了健全的服务监控，能够实时监控pod CPU以及内存。同时也提供了定制化的接入的方案，通过heapster+influxdb+grafana架构可以收集计算任务的cpu/memory信息，对于高性能计算关注的核心算法效率问题来说, 这些监控数据对我们平台算法的不断改进提供了很好的指导方向。

值得一提的是, kubelet 10250端口的参数，在安全组方面不能大意，如果没有把计算节点10250端口封掉，容易导致入侵，因为在开启了enable-debugging-handlers=true 的情况下，外部可以直接通过这个端口，到pod里面进行集群调试。

综合来看，Kubernetes的出现降低了容器服务的入门门槛和复杂性，解放了企业的技术精力,使之能够完全投入到行业所处的技术领域之中。而如CIS、Tencent Hub等技术工具的发展，容器服务的部署、监控、运维和管理都在变得更加高效，无论是医药交通，还是科算超算，都已开始享受技术发展的红利。可以看到的是，2018年的Kubernetes技术，就如繁星之上的皓月，望眼可见，普照各地。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/_v6ZDG-eehCWBe-nOpclDA

创作场景

小白也能玩转 Kubernetes 你与大神只差这几步（三）