大家好,我叫陈中东来自腾讯TG数据平台部然后下面有我和我的同事陈林鹏来给大家分享一下腾讯在GK8S宏布上的一些实践今天我们演讲的主题称为GK9T的全场景在线理线宏布这是今天演讲的主要内容随着数据量的增大,数据资源的需求越来越多但是数据成本问题越来越突出这是我们就会考虑如何给大数据寻找更多的资源大数据的特点是非实验敏感而且具有一定的融出性它的运行时间短大部分时间是在5分钟以内它的资源规格小而结合在线资源利用率低的特点它具有典型的潮信现象这是我们就会考虑可以让大数据这种利用大数据这种碎片资源来填充来填充理线作业的空前资源而且这种也是非常契合的但是宏布不仅仅是简单的把在线和理线宏布在一起这是一个需要从多方面来进行考虑比如说如何保证在线作业的服务质量我们需要底层内核的支持也需要上层干扰检测的支持所以说这是一个从底层到上层的一个松核的一个解决方案至于此我们开发了Kars再建理线宏布系统Kars它是通过k8s的beam set部署在每个节点上Kars内部集成了一些宏布相关的组件比如说干扰检测或资源隔离以及资源画像等每个Kars之间没有任何的依赖Kars不需要外部的依赖便可以计算该节点的理线可用资源并上报搞对应的master的组件而且这种设计也是非常简洁因为我们的调度器为了提合理线的高病发性所以我们增加了自扬的高性的调度器同时为了维护维持在线k8s原生的道具我们是通过一个协调器来进行统一的做出统一的调度策略在Kars研发之初我们也制定了几个原则首先是不改变理线用户的应用的提交方式这对于用户来说对于用户使用这种空前资源来说都是透明的另外不需要对在线作业有依赖性比如说需要在线作业暴露一些实验指标或者是需要在线作业是无状态服务的因为整个架构都是采用松露和扩展的架构大部分的组件都是以插件化的方式形成的都是以插件化的方式同时我们也对整个互补过程中我们要保证对Kars的零入侵所有的相关功能都是通过旁路的方式来通过旁路的方式来实现也便于兼容不同的版本因为我们是基于Kars的恐怖所以说我们就会考虑如果说我们的作业零线作业或在线作业跑在非Kars上这部分资源是如何兼容起来的比如说我们如何如果说我们的在线作业运行在不是运的Kars上那它的空前资源如何暴露出来如果说另外如果说有些零线作业本身跑的压法如何附用Kars上的空前资源针对此问题我们提出了一个全场景的概念对于大部分作业来说现在都已经运行在非Kars上但是还有一部分相当大的存量是运行在非Kars上比如说这部分作业要么还未来的机器容器化或者说不适合容器化必须存储类的服务但是这部分作业还有相当这部分资源还有相当大的一部分存量所以说我们也要充分利用起来对于零线来说如果我们可以兼容任何的Kars的一线作业但是对于大数据来说其实现在占很大比例的大数据还是运行在Hardwood生态所以说我们这部分也作了兼容对于可以让Hardwood生态这样的大数据透明地使用Kars空前资源如果说原来的一线作业已经运行在Kars上对于用户来说就无需做任何的修改因为混布是使用的在线作业的空前资源所以说我们首先要保证在线作业如何不受影响所以我们是通过资源隔离和干扰检测两个相互配合来进行对在线作业来进行全方位的保护资源隔离分为静态隔离和动态隔离静态隔离一般是用户通过一个历史经验给离线资源设置一个固定值但是这个固定值如果设置得过小的话那会造成空前那会造成资源的浪费利用率得不到提升如果配置得过大的话那会对在线资源的波风会产生一些干扰另外一个原因是其实在线的在线这本身也是在不断的升级过程中它的资源也是变化的所以说当在线资源变化的时候这个固定值也要跟随着变化所以说基于这些原因我们需要一种动态隔离方式根据在线预测在线的资源使用根据在线的资源画像来动态的对离线作为一个资源隔离在线资源画像除了动态隔离资源之外我们还动态的实施上报该节点的离线可用资源对于KPI来说我们是通过根据RESAUCE来进行上报的对于他对不下升态下的离线以大数学作业来说通过NM上报给RESAUCE Manager除了在线资源画像我们还可以对离线作资源画像离线作资源画像离线资源画像可以跟调度器相结合比如说选择一个合适根据节点的未来一段时间的资源使用趋势让选择一个合适的节点保证离线作业调度该节点上之后可以在离线可用资源回收之前离线作业也可以正常结束这对于离线作业的ASALATRA也是非常有用的当然这些其实然后需要资源如果这些画像这些画像可以正常公租的基础是我们需要一个精准的一个资源预测只有精准的资源预测它能更好地发挥资源隔离的优势然后精准的资源预测也可以更好也可以进一步提升资源运用率对此我们研究了对比了不同的资源预测的算法包括适用于长洲期的Prohibitor和LTM所谓长洲期就是预测将来一段时间比如说一个小时或一天的数据以及适合短洲期的这些算法比如说WAP短洲期就是比如说预测下一时刻比如说下一分钟不过五分钟之内的五分钟之内的一些算法对于在Overhead方面其实长洲期相对来说消耗的Overhead比较高因为长洲期需要更多的数据需要更大的比较的次数就是说它的计算还有时时时间开销可能会更大一点在稳定性方面大部分的其实大部分的预测算法就是比较稳定的但是我们发现Eryma这个算法其实在五定性分络方面有一些确实它收敛性不是特别好可能需要实施人为调整它的预测它的相关参数K-8S的PODK-8S分为Garanteed Basketball和Bass EffortBass Effort是没有资源请求的这是大家都会考虑是不是可以直接用Bass Effort之类来附用空前资源但是限于K-8S本身的C Group的C Group的C Group设计的限制机制其实Bass Effort作业只能附用部分空前资源如内存它只能附用这部分空前资源但是这部分空前资源它是用不到的而Bass Effort又是因为又是无限接收无限接收的所以说这就会产生一种矛盾的现象在它可用的方向之内它会尽量多的调度临向作业造成资源几战但是外部还有一些空前资源要解决这个问题我们就需要通过修改C Group的层职结构来扩大它的扩大扩大补补资源池这就是我们就是通过一种拦截的方式来修改了炮的C Group目录而通过拦截的方式可以无入侵的无入侵KBASS原生大码逻辑也可以做到更好的兼容最后修改的C Group目录结构如这个图说是所有的离线作业统一受Alphalan这个目录管理它不受KBASS的管理然后KBASS会对Alphalan这个目录进行实施的进行配置然后这样的话我们的离线资源就可以附用所有的空前资源扩大了可以进一步提升恐怖的效率KBASS原生的资源管理它主要是关注CPU和内存但对于恐怖来说是远远不够的还有一些磁盘L网络L等就说我们增加全维度的资源管理尽量多的来管理离线资源减小队在现在干扰资源隔离主要是通过内核的C Group来实现原生的内核其实这些隔离机制都是基本可以玩基本可以满足需求但是如果想要一些更好的隔离方式现有的内核要么需要升级高版本内核或者说本身内核不支持比如说此番L需要C GroupV2支持网络L可能需要高版本的高版本内核中的EBPF支持而我们TensenOS针对此问题专门对各个资源级做了增强比如说CPU我们增加一个白石焦度内可以高优可以完全抢占TU但是有控强资源的时候可以直接附用该资源通过各资源的纬度增强可以进一步对隔离性做进也对隔离性做了进一步的增强刚刚讲上方面下面有我的同事来给大家接着讲一下前面提到使用C Group资源隔离和内核的QoS能力可以用来保护在线作业的服务质量那么采取这些措施以后是否就不需要再担心在线服务的性能了呢其实是未必的因为由于他们运行在了同一个物理机上而对于一些物理资源来说我们目前还没有做到完成的隔离比如这里提到的CPU Catch内存带宽还有共享的磁盘和网卡等另一方面由于共享了内核也会对一些内核的资源有一些资源方面有一些竞争所以除了资源隔离在上一层我们还需要做更多的在线服务质量的一个保护措施首先通过资源的预留我们可以在一定的程度上缓解在线服务对资源波动的一个需求当然这是属于一方性的同样我们还需要使用干扰检测来做一个兜底的策略在发生干扰的时候如果通过我们的干扰检测能够及时的做出响应来驱逐一些干扰人下面主要来介绍一下我们是怎么来做干扰检测和处理对于干扰检测其实就是采集的指标和干扰算法的一个检测算法的一个结合通过数据的采集我们能够获取到能够反映在线服务质量的一些指标然后将这些指标作为数据的输入员使用干扰检测的算法判断在线服务是否已经发生了干扰对于最好的数据员当然肯定是业务自身暴露的一些指标比如说严实 错误 绿染这些指标我们开录也是支持只能从监控系统当中去拉去这些指标指标来进行一个异常的干扰的判断但是能够接入的服务毕竟还是有限的对此我们还做了更多的指标采集的方案技术方案目前CALIS主要实现的是EVPF进行使用EVPF来进行无路清的对一些相关指标的一些深度的采集包括自愿维度和应用维度首先在自愿维度上我们对IO内存和CPU进行了相关指标的采集通过对这些采集的指标来反映服务在各个自愿维度上的服务质量例如对于IO来说影响它的服务性能的通常发生在它进行IO的系统调用时我们可以通过EVPF来采集IO相关的一些系统调用拿到IO相关系统调用的一个研视数据来作为判断IO服务质量的一个指标对于内存来说通常发生在内存紧张或者碎片的情况下发生此类情况是内存申请通常会进入一个内存的物理内存的慢申请过程在服务进程的上下文区做一些内存回收和内存整理的一些操作这是比较耗时的对此我们在内核里面增加了一个EVPF的互可点用来感知这一类内存慢申请的一个事件上面说的主要是各个资源维度上微观的对各个服务质量的一个对在先服务的服务质量的一个衡量对于现在的一些微服务来讲如果能够拿到一些接口或者用户可感知的指标肯定是更加全面和容易理解的也是更加有效的例如对于HTEP类的印达类的服务业务方关心的一般是原一个重要的指标肯定是这个系统它接口处理的一个实验对于这类服务Kalus支持通过EVPF进行无感知的采集它的实验指标通过在内核的相关喊出上进行买点识别并记录请求在本地的一个处理实验上报到用户用户它的组件做一个数据的聚合用户它的组件聚合拿到的计算结果比如说能够拿到实验的一个TP99的指标和它的一个QPS的数值最终会把这些指标统一交给Kalus做一个后续的干扰的一个算法的检测处理当然这里需要在线服务提供一些配置信息来辅助我们拿到这个指标除了支持印大类的服务的指标采集Kalus还支持了对服务的函数执行效率做一个采集只要业务提供一个他们关心的一个关键函数Kalus就可以通过EBPF的Uprobe互可机制在函数的执行前后插入相关的执行点相关的一个互可点从来能够采集函数级别的一个处理实验右侧可以看到是我们线上的一个在使用这个函数采集的一个特性的一个服务业务本身的采集的指标和我们EBPF采集的指标它是在数据上能够对应是一致的有了这些指标数据之后Kalus能够通过检测算法遵够最终判断节点上发生节点上的在线服务是否发生了干扰一旦发生检测到发生了干扰之后我们就需要采取一些措施来保护在线服务例如我们会去调整理线可用的资源量减少它的理线的可用资源量来降低干扰或者是严重的话我们会去Q调部分消耗资源偏多的一些任务比如对于内存之类不可压住的资源来讲我们就是需要通过Q调理线服务来释放更多的资源此外对于一些运行时间较长的任务比如机器学系类的任务Q调容器的代价通常是比较高的此时我们还支持通过容器热潜移的方式把一些机器学系类的这一类的任务潜移到其他的节点上继续运行而不需要浪费它之前已经跑了一些计算的流过程目前容器热潜移也已经做到了在常数级别的对任务的进行潜移除了前面分享的几个解决混布实际问题的一个实践在实际的自然利用率提升方面我们还做了一些更多的一些事这里再分享两个例子比如在一些场景下我们发现磁盘空间会成为我们混布利用率提升的一个瓶颈一方面节点一方面是因为节点提供的磁盘剩余空间可能已经非常少了大数级别的服务又对磁盘空间有很大的依赖为此我们主要通过两个手段来解决这个问题一个是通过挂载通过动态挂载SFRVD的方式来扩展本地磁盘的一个容量大小另外大数据框架也适配了remote surface这样的服务技术从而不需要依赖本地的一个磁盘另一方面对于KBS原生的调度器无法满足大数据类应用的一个调度性能的需求从而会导致资源的分配率就比较低实际利用率也会有所影响为此我们自研了一个高性能的调度器来满足大数据类服务的调度需求该调度器还支持了Gun Scheduling的大数据类应用比较依赖的一个调度特性目前KALUS在腾讯内部已经部署了超过3万个节点平均的自研利用率提升大概在30%以上为公司节省了上一的成本我们在不久之前也已经对KALUS进行了一个开源希望未来有更多的同学可以一起加入空间好 今天的分享就到这里