云上成本管理如何做

如果无法正常显示，请先停止浏览器的去广告插件。

1. Content Title 2 Content Title 3 Content Title 4 Content Title 5 Content Title 6

3. 企业上云，云上资源整体成本优化管理如何做？郭志宏腾讯云资深容器解决方案架构师

4. 目录 01 云原生资源利用现状 02 深入理解Kubernetes的资源管理 03 基于云原生技术的成本管理最佳实践 04 GPU 资源成本优化

5. 成本优化成为企业上云的核心关切云原生基金会2021年调查显示，云原生的部署率已经达到调查样本的历史性新高 Flexera 发布的《2021 云计算市场发展状态报告》 96%的组织已经在调研或使用Kubernetes 30%-35% 的云支出被浪费了 TKE 客户数据分析和调研，客户集群中资源成本浪费非常严重，有众多客户提出关于提高资源利用率的诉求。物理机利用率：10% 虚拟机利用率：12% 容器化利用率： 14%

6. 后云原生时代的成本管理挑战去中心化不断上涨动态变化浪费严重随着以Kubernetes为核心的云 CNCF调查显示，随着业务的快与原生的动态环境和弹性能力业务上云以后缺乏资源优化意原生应用的蓬勃发展，传统的速发展，企业的云费用以24% 导致云费用随业务负载不断变识，依然以传统资源配置思维集中式财务预算和IT管理模式的年增长率快速增加。化。管理资源，浪费严重。在向以业务为导向的分布式决策转型。

7. 目录 01 云原生资源利用现状 02 深入理解Kubernetes的资源管理 03 基于云原生技术的成本管理最佳实践 04 GPU 资源成本优化

8. 深入理解 Kubernetes 中的节点资源

9. Kubernetes 中的资源分配 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx resources: limits: memory: 1Gi Cgroup: cpu.cfs_quota cpu: 1 requests: memory: 256Mi Cgroup: cpu.share 调度器参考 cpu: 100m Deployment Container: nginx Pod:nginx Pod: otherpod Node: node1 apiVersion: v1 kind: Node metadata: name: node1 spec: podCIDR: 192.168.0.0/24 podCIDRs: - 192.168.0.0/24 status: allocatable: cpu: "4" memory: 12095184Ki capacity: cpu: "4" memory: 12197584Ki Node

10. 典型资源利用率资源总量资源总量以及用量实际资源用量未分配资源资源分配率和使用率过多分配资源业务波谷闲置资源云成本管理的核心：在保障业务的前提下，最小化资源需求

11. 横向伸缩和纵向伸缩应用扩容是指在应用接收到的并发请求已经处于其处理请求极限边界的情形下，扩展处理能力而确保应用高可用的技术手段 Horizontal Scaling 所谓横向伸缩是指通过增加应用实例数量分担负载的方式来提升应用整体处理能力的方式负载均衡 Vertical Scaling 所谓纵向伸缩是指通过增加单个应用实例资源以提升单个实例处理能力，进而提升应用整体处理能力的方 CPU 内存 Pod Pod Pod Pod 式实例数量 11

12. Kubernetes原生能力的不足业务现状资源配置配置手段  基于经验的资源配置不准导致大量浪费弹性  业务稳定性基于阈值的弹性的滞后性导致业务来不及弹  当CPU发生抢占时以cpu.shares 公平分配时间片  无法确保延迟敏感型业务的稳定性面临挑战不会配不敢配不能配

13. 目录 01 云原生资源利用现状 02 深入理解Kubernetes的资源管理 03 基于云原生技术的成本管理最佳实践 04 GPU 资源成本优化

14. 全链路降本 1. 问题 1. 运维侧无法从全局视角管控装箱率，每个业务单独配置超卖比步骤 2. 3. 1. 提升节点装箱率方案运维可一键配置最大装箱率(比如200%) • 业务无需关心超卖比，按实际需求配置 request 1. 2. 2. 提升资源利用率峰值 1. • request配置不合理 K8s原生调度策略是默认均衡优先在提升节点使用率时，负载过高可能影响业务稳定 2. 3. 4. Request推荐，基于业务特性智能预估 Pod原地升降配，pod无需重启定制调度器：设定目标利用率后可配置紧缩优先策略，打满节点重调度能力：保证节点负载在目标利用率内：超过目标值时进行友好驱逐（驱逐时先增加 Pod再删除旧Pod，实现平滑迁移）业务存在波峰波谷存在复杂任务类型时（高优在线任务、低优离线任务），难以动态的完成资源管理和调度，确保在线业务不受影响 3. 提升资源利用率均值 1. 2. 3. 通过机器学习聚类算法，将业务按照时间和用量两个维度进行聚类对聚类后的业务进行反相似性和错峰部署为业务设置优先级和 QoS 质量保障，在资源紧张时对低优业务进行抢占和压制，保障业务稳定性

15. FinOps Framework FinOps定义了一系列云财务管理规则和最佳实践，通过助力工程和财务团队、技术和业务团队彼此合作，进行数据驱动的成本决策，使组织能够获得最大收益。原则角色  团队协作  成本节省，人人有责  中心化团队驱动FinOps    成熟度 FinOps 从业者阶段 Crawl Walk 管理层业务/产品负责人实时报表助力决策 Rates & Usage 财务/采购业务价值驱动决策工程/运维灵活利用云上成本模型能力理解用量和成本绩效跟踪和展示 Run 实时决策费率优化用量优化组织支撑

16. Crane 开展 FinOps 布道 Cloud Resource Analytics and Economics 期待与您共建，推动科技进步，惠及更多受众！《降本之源-云原生成本管理白皮书》《云成本优化节能减排白皮书》 https://github.com/gocrane/crane FinOps “双降”讲坛 FinOps Community 公众号 • • Optimize Rate • • • • Optimize Usage FinOps 开源项目 Crane 计费方式推荐抵用券支持 • 制定 FinOps 标准资源回收再分配 Request推荐业务定级、全构混部和服务QoS 基于预测的智能弹性机型推荐 • • 牵头《云原生 FinOps 能力成熟度模型》参与《云成本优化工具技术要求》趋势和变化分析评分和PKI 内部评比、跨供应商评分对比 • • Enable Real Time Decision Making 信通院云管优秀案例参与《企业云成本优化能力与效果成熟度模型》 • Benchmark Performance FinOps 国内首家顶级会员 • 资源利用率报表异常识别识别资源浪费 • • Understand Fully Loaded Costs FinOps能力模型 • • 多维度业务成本分摊表标签管理分期账单预算和配额管理参与《云财务运营成熟度模型》成立 FinOps 产业联盟腾讯云牵头、40 家企业共同发起成立“FinOps 产业标准工作组”形成国内首个 FinOps 产业标准生态联盟，整合产、学、研、用各方力量，推动 FinOps 落地实践。荣誉信通院云原生产业联盟《2022年度云原生技术创新领航者》云计算标准和开源推进委员会《2022年度云优化优秀案例》

17. Crane架构 • 预测为王 • • • 可扩展的预测算法优化为本 • 基于预测的资源再分配 • 基于预测的成本可视化 • 基于预测的横多维扩缩容稳定性为根 • 基于业务优先级的增强QoS • 干扰检测和主动回避

18. 以Crane为基础框架的降本产品指标数据离线抓取大盘/弹性数据分析应用聚类分析优化空间测算应用画像绩效晾晒离线算法评估监控系统运营日报 InfluxDB 跨部门排名优先级管理浪费看板业务定级与SLO Prometheus 节点水位管理节点容量缩放业务运维视角平台运维视角高级CPU管理智能弹性资源再分配弹性配置规格优化 Barad 动态调度器 Metrics-Server 预测、推荐、智能弹性一体化的集中控制器高优在线Pod 低优批处理Pod 中优在线Pod 指标收集压制与重调度干扰判断指标汇聚低优大数据Pod 部署模式零侵入 Crane Agent 基于原生行为的扩展内存 CPU GPU 磁盘网络可扩展腾讯 TLinux 全资源 QoS 标准K8S集群 TKE托管节电池 EKS弹性集群一键部署

19. 成本分析 – 业务利用分析业务资源利用率低：cpu利用率15%，内存利用率25% 有效弹性占比低：只有10%的HPA在本年度弹出过

20. 目标设定与绩效晾晒 • • • • 为优化腾讯内部业务云资源，腾讯定义了云成熟度模型该模型从平台侧以及业务侧考核各个BG的云资源使用情况总成熟度得分 = 业务侧得分 * 50% + 平台侧得分 * 50% 得分情况从作业，产品，部门维度层层汇总，并以该结果作为考核参考指标自上而下设定目标自下而上汇总绩效

21. 持续优化 – 业务优化成本可视化灵活的汇聚维度方便可信的优化能力 • 用量 • 按部门 • 可支持原地升降配的规格优化 • 基于预测的趋势分析 • 按项目 • 弹性推荐、定时弹性和预测弹性 • 按应用类型 • 三条黄金曲线展示推荐值的来源 • 按自定义标签成本和浪费识别 • 与计费API整合的费用展示

22. 平台侧优化 – 节点容量缩放和水位管理集群大盘可视化 • 集群总体利用率 • 节点利用率热力图节点容量缩放 • 可定义节点容量缩放比例，放大节点可分配资源，提升装箱率节点水位控制 • 可自定义节点水位，控制节点利用率上限 • 动态调度器依据利用率装箱，确保真实利用率与目标利用率一致 • 可配置紧缩优先调度策略，方便退还闲置节点

23. 平台侧优化 – 业务定级与混部优先级定义 • 平台运维定义基于PriorityClass的冲突处理策略 • 业务运维为业务定级冲突检测与主动回避 • 灵活的异常检测策略 • • cAdvisor，eBPF，BizProbe 综合指标考量 • CPI，Steal Time，CPU Utilization，Memory Utilization，Network IO，DiskIO 主动回避策略 • 高优业务CPU绝对抢占 • 低优业务主动驱逐通过混部技术，利用率提升3倍敏感业务稳定性不受损

24. 内部大规模落地的成效 • • • • 在腾讯内部自研业务大规模落地部署至数百个 Kubernetes集群管控数百万CPU核全面上线一个月内，大盘总核数缩减 25%

25. 目录 01 云原生资源利用现状 02 深入理解Kubernetes的资源管理 03 基于云原生技术的成本管理最佳实践 04 GPU 资源成本优化

26. GPU虚拟化业界问题 GPU 算力 & 显存利用率低 • 直通 GPU 无法多业务共享资源，利用率低成本高 • vGPU 实例资源配置固定不灵活、虚拟机实例调度成本高，非进程级调度隔离问题 • 显存 / 算力 / 故障隔离性低，不同客户、任务之间存在资源的抢占和干扰 • GPU share 等不支持 QoS • vCUDA 需要侵入式修改 cuda 库

27. qGPU 容器产品介绍 K8S • • Kubernetes scheduler 集群调度算法 qGPU 是腾讯云推出的 GPU 容器虚拟化产品，支持多个容器共享 GPU 卡并支持容器间算力和显存精细隔离，同时支持业界唯一的在 Kubernetes + GPU scheduler plugin 离线混部能力，从而在精细切分 GPU 资源的基础上，在最大程度保证业务稳定的前提下，将 GPU 利用率压榨到极致，最终帮助客户大幅节约 GPU 资源成本。 • 灵活性：精细配置 GPU 算力占比和显存大小 • 强隔离：支持显存和算力的严格隔离 • 在离线：支持业界唯一在离线混部能力，GPU 利用率压榨到极致 • 覆盖度：支持覆盖主流卡 T4、V100 及 Ampere 架构 A10、A100 pod1 ¼ GPU APP APP APP APP CUDA CUDA CUDA CUDA UMD UMD UMD UMD qGPU container runtime qGPU driver 虚拟化提供显存+算力+故障强隔离提供在离线混部能力等 • 云原生：支持标准 Kubernetes 和 NVIDIA Docker • 兼容性：业务不重编、CUDA 库不替换、业务无感 • 高性能：GPU 设备底层虚拟化，高效收敛，吞吐接近0损耗 pod ½ GPU pod 1 GPU pod0 1/n GPU nvidia driver GPU 0 GPU 1 GPU … GPU / vGPU 实例 GPU7

28. 如何使用qGPU • 开启 qGPU 功能：安装 qGPU 组件 • 创建 qGPU 资源：新建 qGPU 节点池 • 使用 qGPU 资源：Pod 指定 qGPU 资源

29. qGPU 支持的3种隔离策略 Label 值 best-effort（默认值） fixed-share burst-share 英文名 Best Effort Fixed Share Guaranteed Share with Burst 中文名含义争抢模式默认值。各个 Pods 不限制算力，只要卡上有剩余算力就可使用。如果一共启动 N 个 Pods，每个 Pod 负载都很重，则最终结果就是 1/N 的算力。固定配额每个 Pod 有固定的算力配额，无法超过固定配额，即使 GPU 还有空闲算力。保证配额加弹性能力调度器保证每个 Pod 有保底的算力配额，但只要 GPU 还有空闲算力，就可被 Pod 使用。例如，当 GPU 有空闲算力时（没有分配给其他 Pod），Pod 可以使用超过它的配额的算力。注意，当它所占用的这部分空闲算力再次被分配出去时，Pod 会回退到它的算力配额。

30. qGPU 性能分析 • • 测试环境测试模型 • CVM 配置：20 vcpus + 80G mem + 1 nvidia T4 16G显存 passthrough • native: 在 CVM 上启动 nvidia docker，容器里使用整张 T4 • qGPU：在 CVM 上启动 N 个 nvidia docker，所有容器共享使用 T4 • 准确性：基于 tensorflow，采用 ImageNet 网络，使用 Resnet50 跑 Image_classification • QoS：使用 Benchmarks 插件，Resnet50，跑不同的 batchsize(1/4/8/16/32/64/128） • • • 性能指标 +期望结果性能指标 • 期望结果 • 精度 • 精度不降 • Throughput • Throughput 总数据不降 • overhead • overhead：引入多 Pod 共享 GPU 后，软件的 overhead 大小，通过 TP 分析 • Latency • Latency(ms)，推理同一张图片需要的时间 • QoS • QoS：各个 Pod 之间的算力与配置的 weight 一致 • 抖动性 • 抖动性：在一定时间内，thoughput 稳定，没有忽高忽低的异常抖动

31. qGPU 性能分析-单pod

32. qGPU 性能分析 – 多pod

33. 业界GPU虚拟化方案对比指标项 qGPU vCUDA 业内某产品 MIG 精准算力隔离 Y（nvidia 外唯一） Y N Y 在离在线混部 Y（业界唯一） N N N 精细分卡 Y Y Y N 多容器共享 Y Y Y Y 显存隔离 Y Y Y Y 故障隔离 Y Y Y Y 无 overhead Y N Y Y 无抖动 Y N 有微弱抖动 Y 无侵入 Y N Y Y 兼容性 Y N Y Y

34. 性能对比-Throughput qGPU 吞吐在各 batch 下始终稳定

35. 性能对比-QoS y轴表示： value = (Pod1 TP / Pod2 TP) ，理论值为：2；算力权重的2倍关系 MPS：小 batch 不太明显（workload 较轻，高算力的 Pod 无法发挥优势），但是当 batch 增加之后，两个 pod 的算力符合预期 qGPU 算力 QoS 在各 batch 下始终稳定

36. 回顾和展望 01 现状，困境，解题思路，技术手段，内部实践，qGPU 02 进一步完善crane 产品能力，一起共建 03 让更多的企业享受到云原生的技术红利

37.

38.