无处不在的离线算力-Crane 基于 Virtual Kubelet 的实践

陈凯悦，腾讯云高级开发工程师，Crane和SuperEdge项目核心开发。专注于大规模离在线混部和资源调度，目前负责Crane离在线混部和调度相关工作。

孟凡杰，腾讯云容器专家工程师，Crane项目发起人，致力于云原生成本优化，腾讯云降本产品研发负责人。

背景

用户使用云时，为不同特征的业务完成精确的资源配置不是一件容易的事情。FinOps 时代如何玩转应用资源配置 提供了诸多最佳实践。我们再来借助下图的单节点资源使用情况探讨一下资源合理利用的挑战，为简化问题，我们只关注核心资源 CPU。

• 假设该节点总计有100个 CPU 核心，体现为图中该节点的容量（Capacity）水平线。
• Kubernetes 调度器会基于用户 Pod 的资源申请规格寻找最适合的节点进行调度决策和绑定，并再完成绑定后对该节点已分配资源进行扣除，体现为图中该节点的资源申请（Request）水平线。
• 位于该图中最下面的曲线是运行在该节点的 CPU 资源持续一周的真实用量情况。评估资源利用率高地通常需要关注：
  • 业务周峰值：每周最高的资源用量，60C
  • 日均峰值：每日峰值用量的均值，40C
  • 平均利用率：所有采样点的平均值，20C

  

为提升资源利用率，常见的手段包括：

• 业务优化：优化业务资源申请规格以及弹性扩缩容提升以缩减已申请但未使用的资源
• 调度优化：通过调度优化提升装箱率
• 混部：回收节点的闲时资源，并供给低 SLA 业务复用，常见的形态是在线+离线的组合，详情参见 Crane如何做到利用率提升3倍稳定性还不受损？。

闲置资源回收的挑战

如下图所示，为回收节点闲置资源，运行在每个节点的 Crane Agent 在初始化时会为每个节点按预定模版创建一个 TimeSeriesPrediction 的 CRD 对象，该对象包含目标节点信息和资源预测算法以及参数信息。为此 Crane 中的资源预测器会拉取该节点的资源用量历史，按既定预测算法进行预测，并将预测结果写入TSP对象的状态属性中。

运行在 Crane Agent 中的 Node Resource Controller 监听 TSP 对象的状态变换，并基于预测结果计算接下来该节点可复用的闲置资源，并将可复用 CPU 更新为节点 Allocatable 中的扩展资源gocrane.io/cpu，将可复用 Mem 更新为节点 Allocatable 中的扩展资源gocrane.io/mem。随着节点负载的不断变化，扩展资源的值也会实时调整。

而低优业务可在Pod中声明使用gocrane.io/cpu这类扩展资源，Kubernetes调度器天然支持扩展资源的调度，而 Crane Agent 确保调度完成后的资源分配和管理。通过以上步骤就完成了闲置资源回收、重新分配、调度、保障的完整闭环。

但是在该能力的规模化推广过程中，我们发现了如下痛点：

• 复用资源以gocrane.io/cpu这种扩展资源形式出现，而众多大数据业务都是以 Operator 启动的作业 Pod，使用扩展资源需要通过修改 Operator 代码或者增加Webhook将cpu修改成gocrane.io/cpu，侵入性较大。
• 一些用户的在线类业务和大数据类业务不仅仅是业务形态上的差异，从公司组织架构也有天然区分，在线集群的用户、离线集群用户的集群入口、权限、配额、资源运营和计费模式等等都有较大差别。而直接在在线集群中直接抽取离线算力，让离线用户接入在线集群这种模式对这类用户的改造成本较大，且与公司组织架构拉通程度高度相关。

基于 Virtual Kubelet 的离线算力复用

那么，有没有更优雅的做法，既能减少 Crane 能力的侵入性，又能从权限隔离层面天然灵活契合组织的组织架构呢？

基于内部的大量实践，参考了腾讯 IEG 主导开源的 GitHub - virtual-kubelet/tensile-kube: A Kubernetes Provider，我们开创性地提出了基于虚拟节点的离线算力模式。

假设用户有一个在线业务集群 Cluster1，该集群部署了 Crane 套件，默认情况下，每个节点上运行的 Crane Agent 会基于预测结果更新节点状态中的gocrane.io/cpu和gocrane.io/mem。

运行一个我们专门为 Crane 闲置资源回收而开发的 Virtual Kubelet Pod。Virtual Kubelet 的工作原理很简单，参考下图，只需完成 NodeProvider、（Pod）Provider和PodMetricsProvider 的接口实现，我们就能构造一个虚拟的 Kubernetes 节点。

NodeProvider 职责包括：

• 创建 Kubernetes Node
• 完成虚拟节点的健康检查和状态上报
• 注意该节点是虚拟的，因此没有具体的计算节点跟它状态中的可调度资源对应，我们要做的事情是将 Cluster1 中的所有闲置资源都抽取出来挂给该虚拟节点。因此 NodeProvider 会监听 Cluster1 中的所有 Node，汇总gocrane.io/cpu，并完成扩展资源到原生资源的转换，以节点可调度资源 cpu, mem 上报。

Provider 的主要职责包括：

• Pod 的生命周期管理，Virtual Kubelet 承担了代理的角色。
  • 当有 Pod 被调度至该虚拟节点时，读取 Pod 清单，并下发至 Cluster1
  • 当被调度的 Pod 被删除时，Virtual Kubelet 要将下发至 Cluster1 中的 Pod 删除，以完成资源释放。

PodMetricsProvider 的主要职责包括：

• 该虚拟节点所有 Pod 的状态汇总上报

Crane 的 Virtual Kubelet Provider 实现了对单集群所有节点闲置资源的监听汇总，并更新至虚拟节点可分配资源中。一个节点就能代表整个集群的所有离线算力。

多集群视角

将一个集群的所有离线算力抽取到一个虚拟节点以后，如何面向离线用户提供服务呢？针对在线、离线集群分离的组织，假设用户 Cluster1 和 Cluster2 是用户在线集群，Cluster3 是用户离线集群。

基于 Crane 虚拟节点的我们就可以很轻易的将所有在线集群（Cluster1和Cluster2）的离线算力抽取出来，并注册到离线集群（Cluster3）中。

这样的体系架构下，在线集群用户是资源供给方，离线集群用户是资源使用方，两个用户群体入口不同，权限完全隔离。而通过 Virtual Kubelet 的虚拟节点，我们以较低成本实现了在线集群闲置资源都离线集群的资源流转，在无侵入的前提下实现了基于混部的在线集群资源利用率提升。

衍生阅读

GitHub - virtual-kubelet/tensile-kube: A Kubernetes Provider：

https://github.com/virtual-kubelet/tensile-kube

Crane 已成功加入 CNCF Landscape，欢迎关注项目，合作共建：

• Crane Github：GitHub - gocrane/crane: Crane (FinOps Crane) is an opensource project which manages cloud resource on Kubernetes stack, it is inspired by FinOps concepts.（https://github.com/gocrane/crane）
• Crane 官网：Introduction - Crane - Cloud Resource Analytics and Economics（https://docs.gocrane.io/dev/）
• Crane 核心模块：（https://github.com/gocrane/creator）