直接用 kubectl top pods --all-namespaces --sort-by=cpu 查看cpu使用排名，重点关注 cpu%（是否超limit导致限频）和 cpu(cores)（无limit时看绝对值），连续多次执行确认稳定性。
怎么快速定位Kubernetes里哪个Pod在吃CPU
直接用 kubectl top pods --all-namespaces --sort-by=cpu，一眼看出 CPU 占比最高的 Pod。注意看两个值：CPU(cores) 和 CPU% —— 前者是绝对用量，后者是相对于该 Pod 的 limits.cpu 的百分比。如果 CPU% 接近或超过 100%，说明它已被内核限频（throttled），响应会卡顿但进程不挂。
常见误判点：
- 没配
limits.cpu的 Pod，CPU%显示为0%或无效，此时只看CPU(cores)绝对值 -
kubectl top是采样快照，不是持续监控；单次结果高，得连续跑几次确认是否稳定高位 - 节点级 CPU 高 ≠ 某个 Pod 高，也可能是 Kubelet、containerd 或 kernel slab 内存缓存问题（比如 cadvisor 的
housekeeping函数）
进Pod后怎么抓到真正耗CPU的Go函数
先用 top -b -n1 | head -20 找出进程内最占 CPU 的线程（PID），再用 go tool pprof 直接分析运行时 profile，比 strace 更准、更轻量。
操作步骤：
- 确保 Go 程序已启用
net/http/pprof（导入_ "net/http/pprof"并启用了http.ListenAndServe("0.0.0.0:6060", nil)） - 用
kubectl port-forward暴露端口：kubectl port-forward pod/<pod-name> 6060:6060</pod-name> - 采集 30 秒 CPU profile：
go tool pprof http://localhost:6060/debug/pprof/profile\?seconds=30 - 进入交互式终端后，输入
top查看热点函数，web生成调用图 SVG，重点关注自底向上（bottom-up）视图里的runtime.mcall、runtime.scanobject、regexp.(*machine).step这类高频函数
注意：pprof 默认采集的是用户态 CPU，不会包含 futex 等系统调用等待时间 —— 如果 strace -c -p <pid></pid> 显示 futex 占比超 90%，那大概率是 goroutine 调度阻塞或锁竞争，不是 Go 代码逻辑问题。
Go热点函数常见类型和对应优化方向
pprof 报出来的热点函数，基本逃不出这几类，每类的修复逻辑完全不同：
-
runtime.scanobject/runtime.gcDrain高：GC 压力大 → 检查内存分配，看是否频繁创建小对象（如循环中 new map、string 转 []byte）、全局 map 未加锁导致逃逸、或 GOGC 设置过高（默认 100） -
regexp.(*machine).step/bytes.Equal/strings.Contains高：字符串/正则处理低效 → 避免在 hot path 用复杂正则；用strings.Index替代strings.Contains；预编译正则表达式并复用regexp.MustCompile -
runtime.mcall/runtime.gopark高：goroutine 频繁挂起/唤醒 → 检查 channel 操作是否阻塞、mutex 是否粒度太粗、或存在大量空 select/case default 导致轮询 -
crypto/sha256.blockAvx2/encoding/json.(*decodeState).unmarshal高：序列化/加解密密集 → 考虑缓存结果、批量处理、或改用更轻量格式（如 Protocol Buffers）
为什么加了pprof还是看不到真实热点
不是所有高 CPU 场景都能被 pprof 捕获，尤其当瓶颈不在 Go runtime 时：
- 容器镜像用了 distroless，没
/bin/sh，kubectl exec失败 → 改用kubectl debug -it <pod-name> --image=busybox --target=<container></container></pod-name> - 程序没暴露 pprof 端口，或监听地址绑定错了（如只绑
localhost:6060）→ 必须用0.0.0.0:6060，且防火墙/NetworkPolicy 允许访问 - 采集时间太短（60s），样本不足或失真 → 生产环境建议 15–30 秒，避开 GC STW 瞬间
- 热点在 syscall 层（如
futex、epoll_wait）→ 此时pprof显示为runtime.goexit或空白，得切回strace -T -p <pid></pid>看单次系统调用耗时
真正难的不是看到热点，而是判断那个函数高占比，到底是它自己慢，还是被上游拖累（比如一个 HTTP handler 里调了三次低效 DB 查询，pprof 会把时间全算在 handler 上，而不是 DB 驱动里）。
