架构

image.png

组件

autopilot-controller: 一个基于metacluster场景开发定的VPA + HPA组件, 并具备自动化、安全的节点下线流程，是成本优化和可用性提升的利器，目前已在tke/eks/mesh等业务场景中成功落地
workload-controller: 通过监听Deployment、Statefulset自动生成Workload资源，此资源描述了对应的Deployment/Statefulset服务的资源预测、分类等信息。当对应的Deployment、Statefulset被删除时，Workload资源也会自动被删除。
workload-recommender: 定时监听、获取集群内所有Pod、Workload，结合从metrics-server获取的实时数据、Prometheus中的历史数据，输出Workload的资源预测及画像信息，并将此信息更新到Workload资源上。
metrics-server: 实时查询集群中的Pod监控数据(仅支持cpu、内存两个指标，storage为空时默认从metrics-server查询)
prometheus: Pod监控数据历史存储、实时数据(支持八个指标，storage为prometheus时，实时数据、历史数据都从prometheus查询)

核心原理 推荐算法

移动窗口(moving window)/直方图(Histogram)

  • 什么是直方图?直方图（Histogram）是一种可视化在连续间隔，或者是特定时间段内数据分布情况的图表，经常被用在统计学领域。简单来说，直方图描述的是一组数据的频次分布， 例如把CPU分成“0.00-0.01,0.01-0.02，……，”等N个组，统计一下CPU的分布情况。 直方图有助于我们知道数据的分布情况，诸如众数、中位数的大致位置、数据是否存在缺口或者异常值。
  • 如何构建直方图?为每个资源如CPU、内存等维护一个直方图，定时从metrics-server获取container metrics,将metrics添加到直方图中。

  • 资源预测的原理?直方图构建就绪后，我们可以通过直方图的Percentile接口获取资源的推荐，它会返回给定第百分位的资源分布的近似值。workload上有三个资源预测值，本质上核心分别对应不同的第百分位资源分布值, 如下所示: targetCPUPercentile := 0.9 lowerBoundCPUPercentile := 0.5 upperBoundCPUPercentile := 0.95 targetMemoryPeaksPercentile := 0.9 lowerBoundMemoryPeaksPercentile := 0.5 upperBoundMemoryPeaksPercentile := 0.95

    指数级衰减直方图（Exponential Decay Histogram）

  • 什么是指数级衰减直方图? 为什么需要它在直方图中新、旧的数据权重一样，因此在服务负载预测方面，它对资源快速变化、增长会反应迟钝，我们需要一种机制对最新的样本数据给予更高的权重，让老的数据逐渐过期。 这就是指数级衰减直方图。这种直方图可以为较新的样本提供比旧样本更高的权重，逐渐衰减过去的样本。通过指数级衰减直方图，我们可实现workload的Limit上限，随着使用量的增加而迅速增加，但要在负载减少后缓慢减小，以避免对负载暂时下降的过快响应。 为了平滑对负载尖峰的响应，也就是我们通过指数衰减权重𝑤[𝜏]对样本进行加权。每个样品的权重乘以2 ^（（sampleTime-referenceTimestamp）/ halfLife）。 默认CPU和内存的半衰期分别为24小时和24小时，可根据业务负载情况调整相关参数。

    机器学习算法

    移动窗口(moving window)算法是基于业务deployment/statefulset的历史数据、当前数据来实现的对未来资源使用量的预判。 此外我们还支持机器学习算法，如xgboost等，针对不同的workload类型，后续将支持不同workload选择不同的推荐算法（移动窗口(moving window)、机器学习xgboost等其他时间序列预测算法）等。

    服务分类定义

  • 方法一，Pod配置了Limit，资源当前使用量 / Pod Limit业务的Deployment、Statefulset指定了Pod的资源Limit, 当实际使用量 / limit的比例大于某个阈值时（比如60%）就定义为某资源密集型。 这里为了避免负载波动等对服务分类预测的影响，也同样会使用指数级衰减直方图来维护此比例值，比如当CPU的第95的百分位值值接近0.6(pod cpu usage/pod cpu limit)的时候，我们就认定其为CPU密集型。

  • 方法二，资源当前使用量大于指定阈值同时针对部分业务Pod未配置资源Limit的场景，我们也将支持根据资源使用量是否大于某指定阈值来判断， 比如内存使用大于8G，我们认定为内存型，CPU使用核数大于2核，我们认定为CPU型等。 同样也是使用指数级衰减直方图来维护此值。

    已支持的服务分类

  • cpu密集型、内存密集型CPU密集型、内存型，都可通过资源当前使用量/资源limit值的比例、以及是否大于固定阈值来判断。

  • 磁盘IO型基于container_fs_writes_bytes_total和container_fs_reads_bytes_total指标判断

  • 网络IO型基于container_network_transmit_bytes_total和container_network_receive_bytes_total指标判断，

    基于业务http指标

  • qps和latency目前支持基于业务http qps和latency进行资源预测

    服务副本数推荐

    服务副本数推荐依赖业务声明Pod的可分配的最大CPU和内存资源，期望的CPU使用率阈值、内存阈值等，然后根据当前的Pod实际资源使用量，调整副本数，这个功能应是HPA本身具备的，建议此特性融合到HPA中。

    相关论文

    资源预测业界相关论文可参考Google的Autopilot: workload autoscaling at Google

    依赖

  • k8s 1.10+(RBAC)

  • 部署prometheus
  • 部署metrics-server