怎么从K8s API实时拿到Pod的CPU使用量
直接调用 /apis/metrics.k8s.io/v1beta1/namespaces/{ns}/pods/{pod} 是最轻量的方式，但前提是集群已部署 metrics-server。没装的话所有请求都会返回 NotFound 或 ServiceUnavailable，不是代码写错了，是服务根本没起来。
实操建议：
- 先用
kubectl top pod -n {ns}验证能否查到数据，失败就别急着写Go——90%的问题卡在这步 - Go里用
rest.InClusterConfig()获取集群内配置，别手动生成Bearer Token或硬编码API地址 - 注意
metrics-server默认只保留2分钟窗口的数据，超时查询会返回空，别误判为Pod没上报 - 响应里的
usage.cpu是字符串格式，如"123m"，得自己解析成毫核（123）或纳秒（123000000），别直接当整数用
用Prometheus查Pod CPU利用率为什么总对不上kubectl top
因为两者数据源和计算逻辑不同：kubectl top 拿的是 metrics-server 的瞬时采样值，而PromQL查的是Prometheus抓取的指标，比如 container_cpu_usage_seconds_total，必须做速率计算才能得到“利用率”。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 直接用
avg(container_cpu_usage_seconds_total{pod="xxx"})—— 这是累计秒数，不是百分比，数值会随时间线性上涨 - 漏掉
by (pod)导致多容器Pod结果被合并，单个容器CPU飙高却看不出来 - 时间范围选太短（如
[1m]），遇到抓取间隔抖动就出NaN
正确写法示例（单Pod单容器）：
rate(container_cpu_usage_seconds_total{pod="my-pod", container!="POD"}[5m]) * 100 / (count(node_cpu_seconds_total{mode="system"}) by (node) * 5 * 60)注意分母要对应Pod所在Node的CPU总核数，不能硬写 4 或 8——云上VM核数可能动态变化。
Go里调Prometheus API拿CPU利用率的坑在哪
别直接拼URL发HTTP请求。Prometheus的 /api/v1/query 返回结构固定，但错误不走HTTP状态码：即使返回 200，body里也可能有 "status":"error" 和 "errorType":"bad_data"。
实操建议：
- 用官方库
github.com/prometheus/client_golang/api，它自动处理重试、认证头、JSON解包 - 查询参数中
time字段必须是Unix时间戳（秒级），传字符串如"2024-05-01T12:00:00Z"会静默失败 - 如果Pod刚启动，
rate()在前2个采样点内无法计算，返回空数组，Go里解包时要检查result.Data.Result长度，别panic - 别在循环里反复创建
api.Client，复用一个实例，否则容易触发连接池耗尽
为什么按CPU request算利用率反而更稳定
因为 container_cpu_usage_seconds_total 受调度器抢占、cgroup限制、节点负载影响大，同一Pod在不同节点上波动可能差3倍；而 sum by (pod) (rate(container_cpu_usage_seconds_total[5m])) / sum by (pod) (kube_pod_container_resource_requests_cpu_cores) 把分母固定为request值，更适合做SLO对比或告警阈值判断。
关键点：
-
kube_pod_container_resource_requests_cpu_cores来自kube-state-metrics，不是Prometheus自带指标，没装这个Exporter就查不到 - request可能为0（比如没设limits/requests），除零会导致整个表达式返回NaN，得加
or vector(0)容错 - 该比值理论上可超100%，说明Pod在“超卖”运行，监控时别直接过滤掉 >100% 的数据点
真实环境里，request-based利用率比node-core-based更适合作为横向扩缩容（HPA）依据，但要注意它掩盖了节点实际过载风险——这点容易被忽略。
