3月30日，由优维联合FinOps产业推进方阵、云原生社区举办的第2期UGeek大咖说如期开播，本期主题为“FinOps，从上云到上好云”，邀请了腾讯技术产品经理王孝威做客直播间，为大家带来了一场FInOps技术盛宴。
下面，将从四个方面带大家共同回顾本次直播活动的主要内容。
- 1.云上资源效能挑战
- 2.云原生场景下的成本优化挑战
- 3.Crane智能调度助力成本优化
- 4.产品化输出服务外部客户
一、云上资源效能挑战
云原生基金会2021年调查发现，云原生的部署率已经达到历史性新高，96%的组织已经在使用Kubemetes。Flexera2022云计算市场发展状态报告显示：32%的云支出被浪费。云支出的节省与浪费，现已成为上云之后一个迫切需要解决的问题。
后云原生时代的成本管理挑战
- 去中心化：随着以Kubemetes为核心的云原生应用的蓬勃发展，传统的集中式财务预算和IT管理模式在向业务为导向的分布式决策转型。
- 不断上涨：CNCF调查显示，随着业务的快速发展，企业的运费用以24%的年增长率快速增加。
- 动态变化：与原生的动态环境和弹性能力导致云费用随业务负载不断变化。
- 浪费严重：业务上云以后缺乏资源优化意识，依然以传统资源配置思维管理资源，浪费严重。
二、云原生场景下的成本优化与挑战
抽样调查发现，绝大多数虚拟机的资源利用率普遍只有10%左右。AWS、谷歌等权威机构对外公开的论文显示，云上客户的虚拟机的利用率普遍只有10%左右，因此低用率是行业通常来讲一个普遍存在的问题。
那么如何去优化资源利用率低与成本浪费的问题？这里有几个层级：
- 从第一个层级来看，是节点容量和已分配之间的差距，节点容量本身是一个固定值，跟你买的节点的规格有关，就需要提升它的一个分配值，如何去提升？可以往这个节点上面调度进更多的业务，通过提升装箱率来提升资源利用率。
- 第二个层级，减少已分配和周峰值的差距，即设置一个更准的资源请求量，这个资源衡量最好是以你的峰值作为一个基准，这样的话可以避免这种已分配的资源占用和周峰值间的浪费。
- 第三层级，就是周峰值和日风峰值之间的差距，可以通过一些弹性的手段。
- 比如可以部署多个业务，通过扩容，增加它的副本数，增加它的资源请求量，去提升它的一个资源占用量，然后在波谷的时候去进行本数的说，或者是规格的调小，去释放出这部分资源，让给其他的业务使用。
- 第四层级，最后这一层的优化就需要比较复杂的手段，因为这里通仅仅通过弹性可能没办法能够及时的响应和满足需求，一般是需要通过混部的技术引入更多的业务，然后引入更多的业务之后，但是可能会面临到业务之间资源的抢占和竞争的问题。
Kubernetes原生能力的不足
- 第一是资源的配置，基于经验的资源配置不准导致大量浪费。
- 第二是弹性，基于阈值的弹性的滞后性导致业务来不及弹；在固定资源池弹性，成本并没有降低。
- 第三业务稳定性，CPU是可压缩资源，CPU承压时，所有Pod等比受损；独占式绑核能力造成较大资源浪费。
三、FinOps助力成本优化
FinOps是什么？
FinOps定义了一系列云财务管理规划和最佳实践，通过助力工程和财务团队、技术和业务团队彼此合作，进行数据驱动的成本决策，使组织能够获得最大收益。
上面是腾讯内部如何落地FInOps的总览。首先腾讯内部管理着数千万盒的上云规模，面对这个大规模的容量，实际推动是非常困难的，然后发现很多业务常出现一些问题：
- 资源超配普遍
- HPA有效性占比10%
- 32、64大核心占比高，装箱困难
- 不可任意调度，发生重调度就报故障单
针对以上问题，腾讯是如何去解决的呢？
- 首先是成立了一个技术委员会。技术委员会的会长是腾讯的副总裁，他是最高的决策委员。然后去做原生渗透率，成熟度，资源盘活等多方面数值运营数据的一些体系的建设。
- 其次是运营，主要是资源提供方，成立资源运营管理平台，对内部的业务，提供资源的时候去做定价，包括要求业务做一定的改造与适配原生成熟度的数值要求。
- 再然后是业务，资源的使用方，上面提到的问题，实际上一些业务普遍存在的问题，需要推动业务去做。
- 最后是云平台，提供很多工具，帮助用户和业务进行降本增效。
如何去做业务优化、成本优化？
第一个前提是业务到底应该申请多少资源，到底应该如何配置，需要业务持续配合，这也是比较难推进的一个事情。
第一阶段洞察优化与运营，做一个成本可视化的面板，对成本进行聚类和分析，可以查看到每一个业务、每一个工作负载、每一个团队、每一个部门的成本使用情况，成本的走势，利用率的走势，利用率的情况，通过量化的数据来展示出来，再做一些晾晒，比方说会把每个部门，每个团队的业务利用率的数据进行排序，然后以周报的形式抄送给上层领导。
第二阶段是规格推荐。对于很多业务来说，到底应该如何降本增效呢？推出一些优化工具：
- 资源推荐，根据历史资源情况，给业务推荐一个合适的数值，在这个合理的数值下做好资源的供给。
- 增加一个工作负载的副本数推荐，让业务灵活的应对流量的波峰波谷。
第三阶段是智能预测与自动扩缩容，根据工作负载的历史流量进行预测，得到一个提前资源的预估量，再根据提前预测的资源预估进行弹性的扩缩容。
业务优化的挑战
- 我的业务非常赚钱，成本不是问题
- 我要为可能突发预留资源的，如果优化资源配置未来出现问题的责任边界如何界定？
- 优化思路我认可，但是我当前的工作重点是业务迭代，必须在年底前交付新能力，目前没法给予支持。
- 我们部门负责1000个业务，按照当前变更的速度，可能会话6个月完成一轮调度。
针对以上挑战，如何去解决呢？
既然业务难配合，那么我们就自己干，不要业务去参与，所以我们在调度层面做了一些优化，无需业务介入和干预，这样的话就可以避免跟业务正面去battle。
负载感知调度
基于集群节点真实的利用率进行调度的能力。
真实的利用率调度有什么好处呢？可以防止一些节点资源被大量占用，但它实际利用率很低，那这样的节点在下次调度的时候，原本不会被选中，但是因为我们是考虑它的真实利用率，发现它还可以继续装，那么我们就会把它装进去，这样的话可以让整个集群的节点更加均衡，防止出现一些调度热点。而调度集群利用率不均，会导致一些业务稳定性失衡。
拓扑感知调度
每一个CPU跟内存之间、缓存之间，是有一些绑定关系的。
比方说在一个NUMA里面的CPU，它可以共享，共享一些cash这样的话，将这些CPU进行切换的时候，它的上下文的切换和代价是比较小的。传统的K8S是不看这一层的，而拓扑感知调度器是可以看，哪几个CPU的关系更近一点，可以切换的时候，防止这种上下文的切换带来的额外开销，减少资源的消耗。
支持模拟调度的重调度器
当一个节点的负载过高的时候，需要对节点上面的某些pod进行驱逐，以保证这个节点上面那些高优敏感业务的稳定性。
混部，挑战极限利用率
我们可以看一下它的场景，首先就是在计算机处理的队列里面有一些在线业务，这个时候如果又来了一些离线业务话，这些离线业务是按照正常的KS的逻辑，它不管是在线还是离线，所有的业务都是平级的，该处理啥处理啥。
那么，在线分部的场景就是会保证在线业务的稳定性。因为在线业务它是实时提供服务，提供要处理请求的，它的优先级比较高，它会跳过离线业务去运行在线业务。
如果离线业务运行完了，这个时候又来一个在线业务，那在线业务就继续运行。再如果又来一个离线业务，还有在线业务在run的话，那么离线业务就会等，等这个在线业务运行使用完这个CPU之后才会去让离线业务使用资源，这就是在线离线混部的基本概念。
混部的整体能力是这样的：
首先最上层是面向业务，需要定义业务的优先级。然后分为了两级调度，第一级就是对业务的资源清理画像，然后去看当前集群里面，每一个业务对资源的请求是什么样的。有了这些数据之后，由二级的调度能力去保障，不同优先级的业务，对资源的请求量是不一样的，它有一个资源隔离和冲突处理的能力。最底层是硬件资源提供。
四、产品化服务外部客户
商品化产品-TEK原生节点
我们推出了原生节点的概念，它是原生场景的一种优化的节点，它提供了很多特殊的能力：
1. 集群大盘可视化：集群总体利用率、节点利用率热力图；
2. 节点容量缩放：可定义节点容量缩放比例，放大节点可分配资源，提升装箱率；
3. 节点水位控制：可自定义节点水位，控制节点利用率上限；动态调度器依据利用率装箱，确保真实利用率与目标利用率一致；可配置紧缩优先调度策略，方便退还闲置节点
4. 高线任务：基于混部能力提供使用闲置回收资源运行Kubemetes Job的能力。
商业化产品-TEK超级节点
超级节点是我们推出了无节点的一个概念，就是不需要买虚拟机，不需要买任何东西，你需要多少资源，我们给你多少资源，这样的好处是不需要去管节点，可避免业务的申请量跟节点之间的浪费。超级节点的每一个业务都是运行在比较独立的环境当中，具有更好的隔离性与稳定性。
综上，本期嘉宾王孝威老师主要分享了云上资源的效能挑战，讲述了云上资源浪费的现状问题，其次就是在云原生场景下的成本优化挑战，主要给大家分析了应该如何去理解成本的分布以及成本优化的一些常用手段，最后就是关于智能调度助力成本优化方面，主要介绍了如何以云原生智能调度能力去提升资源的效能。王老师对如何“上好云，用好云”细致的讲解，相信对大家有一定的借鉴意义。
五．Q&A
Q1：能否分享一些具体的落地经验，展开讲讲落地经验这块的一个具体的情况呢？
王孝威：以一个最常见的场景，就是很多业务不知道如何去配资源。
在K8S的场景里面，每一个业务，要具体去申请资源的一个请求量，叫做数值。既然不会配，那我就告诉你这个数字该填多少好，我们会根据一个业务的历史监控数据进行画像分析，然后结合社区的推进算法给他一个相对来讲比较准确的一个资源申请值，这个申请值普遍来讲，通过我们内部几百万核的规模来讲，都比他实际申请的要小很多，因为申请的越多，相对来讲风险越小，这是一个典型的例子，叫做资源的推荐。
第二个就是资源推荐完给业务之后，他是需要去更改业务里面的这个数值，更改之后一般还涉及到业务的重建。那这是需要业务参与的过程，如何让业务不参与呢？我们提供了一个工具，叫做节点规格的一个虚拟放大，你不是申请80核吗，没关系，因为我知道你可能只用了20核，那我把一个100核的节点虚拟放大成300核，400核，这样的话就可以调度进行更多的po，这样你也不需要做业务改造，你想申请多少申请多少，那我这个节点虚拟放大了，我只要设置水位线去防止热点过载的情况。我通过这种虚拟放大，可以让更多的po进来，业务进来，承载更多的业务。所以，可以让业务参与，也可以不让业务参与，都是有相关的手段。
Q2：腾讯内部降本增效具体体现在哪些场景和业务呢？有哪些可以复制的经验吗？
王孝威：基本上每个场景，每个业务都有在做降本增效的事情。因为我们知道，整个2022年，中国乃至世界互联网的形势都不容乐观。不仅云计算行业在降本增效，整个行业都在降本增效，所以项目增效是一个自上而下公司级别的，会到每个团队，每个业务，每个的部门。
我们提到了两个例子，一个是业务层面改资源的申请量，一个是平台方去虚拟放大检验规格，还有一个例子是比方说我们的音视频团队，它是有很多那种，数据转码计算的一些需求，要做视频的转化，格式的转化，所以会有大量的计算的需求。但是云上的资源都是那种实时的在线资源，你想用多少用多少。实际上用这些资源是很浪费的，因为这些资源是很贵的。
这些在线的转码需求，对服务稳定性的要求，响应率等等都不是很高，而且大多数转码的任务可能执行几分钟，长的可能也就几个小时，不会特别长，就算被中断了，风险也不大。
那么针对这样的场景，我们提供了一个离线资源回收再用的功能。
比方说你一个节点，它是100核，100核都被别的业务用了，但这些别的业务在在日间高峰可能也就用了60核，然后到了晚上凌晨可能只用了10核或20核。那么晚上这一段时间，可以把这些资源抽出来，给这些转码的任务去使用。比方说同样的节点，白天就正常的去处理那些实时的请求和任务，到了晚上就可以把资源让出来，给那些离线转码的任务去使用，这就是一个比较典型的在离线缓步，包括离线资源复用，包括音视频，包括离线，包括这种离线资源使用的案例，很多公司内部可能也有。
有疑问加站长微信联系（非本文作者）
