13.3 FinOps for Kubernetes

传统数据中心的成本比较固定，但云上环境就不一样了，首先云上服务大部分按量计费，其次计费规则复杂，对于许多特殊的云上资源，云服务商并未提供更细致的成本分析手段，Kubernetes 集群成本就是其中之一。

Kubernetes 集群本身并不提供成本拆分能力，只能查到集群整体成本、节点组成本等粗粒度的成本信息，缺乏细粒度成本分析能力。此外，Kubernetes 集群是一个动态的运行环境，节点数量、节点规格、Pod 所在的节点/Zone/Region，都可能会随着时间动态变动，这为成本分析带来了很大的困难。

对于以上的困难，要做好 Kubernetes 成本管理工作，有如下三个要点：

• 理解 Kubernetes 成本构成，准确分析 Kubernetes 成本有哪些难点
• 寻找优化 Kubernetes 集群、业务服务手段
• 确定 Kubernetes 集群的成本拆分手段，建立能快速高效地分析与管控集群成本的流程

13.3.1 Kubernetes 的成本构成

云上的 Kubernetes 成本除了节点、集群的费用外，还包含存储、流量、负载均衡等费用，以阿里云 ACK 为例，它的成本有这些组成部分：

总结 Kubernetes 有三部分成本：计算、存储、网络。其中计算与存储成本相对固定，而网络成本则是动态的，跟是否跨区、是否通过 NAT 等诸多因素有关。

13.3.2 Kubernetes 资源分配方式

Kubernetes 提供了三种资源分配的方式，即服务质量 QoS，不同的分配方式，成本的计算难度也有区别

• Guaranteed resource allocation(保证资源分配): requests 与 limits 设置相等，确保预留所有所需资源
  • 保守的策略，服务性能最可靠，成本最高
  • 这种方式分配的资源，由于计算成本是静态的，拆分起来也最方便。
• Burstable resource allocation(突发性能)： requests 设置得比 limits 低，相差的部分就是服务可 Burst 资源量
  • 最佳实践，选择合适的 requests 与 limits，可达成性能与可靠性之间的平衡
  • 由于 requests 计算成本是静态的，Burstable 部分的计算成本是动态的，成本计算相对复杂
• Best effort resource allocation(尽力而为): 只设置 limits，不设置 requests，让 Pod 可以调度到任何可调度的节点上
  • 这个选项会导致服务的性能无法保证，通常只在开发测试等资源受限的环境使用
  • 这种方式分配的资源，完全依赖监控指标进行成本拆分

13.3.3 Kubernetes 云成本管理原则

• 按产品或者业务线来划分名字空间，以命名空间为成本划分的维度，我们还可以在名字空间设置资源上限与预警。
• 为 Kubernetes 服务设计与其他云资源一致的成本标签，通过 kubecost 等分析工具，进行统一分析 Kubernetes 与其他云资源的成本。
• 将成本上升的压力与成本下降的效益覆盖到开发人员，授权开发人员可跟踪服务利用率与成本，以激励开发人员与 SRE 合作管控云成本。
• 将资源标签准确率维持在较高数值，准确率低于一定数值即自动告警，触发标签修正任务。
• 定期检查云成本变化，并建立自动化异常检测与告警机制。

13.3.4 多云下成本统一分析

如果涉及多个云服务提供商的场景，需要把不同云服务商的数据转换成统一的格式，这个时候可以搭建一个平台无关的成本分析与管控平台，然后在自有的成本平台上进行统一分析。

多云成本管理平台大概需要以下几个功能模块：

• 成本数据转换模块：把不同云的成本数据，转换成与云服务无关的格式，进行统一处理
  • 折扣模块：处理不同资源的折扣，比如 CDN 在用量高的时候通常会有很高的折扣比例
  • 各类促销、资源置换、合作等特殊资源也需要进行特殊处理
• 标签修整模块：随着标签体系的发展，总会有些标签的变更，不方便直接在资源上执行，就需要在成本计算这里进行修正、增补或者删除
• 成本拆分模块：Kubernetes 集群很多情况下是各业务共用，这个时候就需要进行成本拆分。
• 成本报表： 使用类似 Grafana 报表工具将最终的数据制作成符合各类人员需求的可视化图表