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

阅读数:66 2019 年 10 月 29 日 18:00

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

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

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 就能适应这样的场景。

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

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 退出。

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

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 页面。

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

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

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

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

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

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

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

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

计算平台演变

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

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

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

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

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

腾讯云容器服务实践

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

需要注意的是,超算和信息服务的计算有较大的差异。科学计算的特点是计算密集型,计算时间长,通常是异步计算,追求算法的执行效率并行化,主要以工作站或超算为主;信息服务的特点则是 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 任务.

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

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

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

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

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

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

容器云 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

评论

发布