Grafana Mimir分布式部署中的KEDA自动伸缩机制解析

概述

Grafana Mimir作为一款开源的长期存储解决方案，其分布式部署模式支持通过KEDA(Kubernetes Event-driven Autoscaling)实现自动伸缩功能。本文将深入分析Mimir分布式部署中distributor组件的KEDA自动伸缩配置原理，特别是CPU和内存指标的阈值计算方式。

KEDA自动伸缩配置

在Mimir的Helm chart中，distributor组件的自动伸缩可以通过以下配置开启：

distributor:
  kedaAutoscaling:
    enabled: true
    preserveReplicas: false
    minReplicaCount: 1
    maxReplicaCount: 10
    targetCPUUtilizationPercentage: 70
    targetMemoryUtilizationPercentage: 70
    behavior:
      scaleDown:
        policies:
          - periodSeconds: 600
            type: Percent
            value: 10

这个配置会生成一个ScaledObject资源，其中包含两个Prometheus查询触发器：一个用于CPU使用率监控，另一个用于内存使用监控。

CPU自动伸缩机制

CPU自动伸缩的阈值计算基于以下公式：

阈值 = 容器CPU请求量 × (targetCPUUtilizationPercentage/100)

例如，当CPU请求量为250m(0.25核)，目标利用率为25%时：

250m × 0.25 = 62.5m → 向下取整为62m

KEDA生成的Prometheus查询会计算过去15分钟内每个distributor pod的平均CPU使用率(单位：核)，然后乘以1000转换为毫核(millicores)：

max_over_time(sum(sum by (pod) (rate(container_cpu_usage_seconds_total{...}[5m])))[15m:]) * 1000

内存自动伸缩机制

内存阈值的计算类似：

阈值 = 容器内存请求量 × (targetMemoryUtilizationPercentage/100)

Prometheus查询会监控工作集内存使用量，并考虑OOMKilled事件：

max_over_time(sum((sum by (pod) (container_memory_working_set_bytes{...}) or vector(0))[15m:]) 
+ sum(sum by (pod) (max_over_time(kube_pod_container_resource_requests{...}[15m])) 
and max by (pod) (changes(kube_pod_container_status_restarts_total{...}[15m]) > 0) 
and max by (pod) (kube_pod_container_status_last_terminated_reason{..., reason="OOMKilled"}) 
or vector(0))

HPA指标显示解析

当查看生成的HPA资源时，可能会发现CPU指标的显示有些令人困惑：

54747m/62

这实际上是Kubernetes的显示特性，其中：

• 54747m表示54.747核(54747/1000)
• 62表示62毫核(0.062核)

这种显示方式虽然看起来不一致，但实际上是正确的，只是单位表示方式需要特别注意。

最佳实践建议

1. 合理设置目标利用率：根据实际负载模式调整targetCPUUtilizationPercentage和targetMemoryUtilizationPercentage

2. 监控指标验证：定期检查Prometheus查询返回的实际值与HPA显示值是否一致

3. 资源请求配置：确保resources.requests设置合理，这是阈值计算的基础

4. 缩放行为调优：通过behavior配置控制缩放速度，避免过于频繁的扩缩容

通过深入理解这些机制，用户可以更有效地配置和管理Mimir集群的自动伸缩功能，确保系统在负载变化时能够做出适当的响应。