Go应用在Kubernetes中变卡主因是CPU限制（如250m）导致CFS throttling，且未配GOMAXPROCS：250m即每100ms仅获25ms CPU时间，而Go默认按节点核数设P数，造成goroutine排队、调度延迟飙升；须手动设GOMAXPROCS=limits.cpu（单位m）并对齐整数毫核。
Go应用在Kubernetes中跑得慢、响应延迟高，十有八九是CPU限制没配对——不是设太低导致被 throttled，就是没设 GOMAXPROCS 导致调度器浪费资源。
为什么cpu: "250m"会让Go服务变卡
Kubernetes 的 CPU 限制（如 250m）本质是 CFS 配额：每 100ms 周期只允许用 25ms CPU 时间。Go 运行时默认把 GOMAXPROCS 设为系统逻辑 CPU 数（比如节点有 8 核，它就开 8 个 P），但容器里实际只被分配了 0.25 核——结果大量 goroutine 在 P 上排队等待，调度延迟飙升，HTTP 超时频发。
-
250m≠ “最多用 25% 的 CPU”，而是“每 100ms 只给 25ms 时间片”，超了就 throttle，top看不到高 CPU，但cat /sys/fs/cgroup/cpu/cpu.stat里nr_throttled会持续增长 - Go 1.19+ 默认启用
GOEXPERIMENT=loopvar和更激进的 GC，若内存压力不大但 CPU 限得太死，GC worker 线程抢不到时间，反而推高延迟 - 不显式设置
GOMAXPROCS时，Go 会读取/sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us自动推算，但推算逻辑在低配（如100m）下常出错，建议手动覆盖
Deployment里怎么写CPU限制和请求才合理
关键不是“设多少”，而是“请求和限制要匹配运行时行为”。Go 是强 CPU-bound 的语言，requests 决定调度位置，limits 决定是否被掐断。
- 先测基准：本地用
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/profile?seconds=30看 CPU 火焰图，确认峰值负载下真实需要多少核 -
requests设为100m～200m即可（足够调度器安排到非争抢节点），但limits必须 ≥requests，且建议设成整数毫核（如400m），避免 CFS 小数周期计算误差 - 必须加
env显式控制运行时：env: - name: GOMAXPROCS valueFrom: resourceFieldRef: resource: limits.cpu divisor: 1m - name: GOGC value: "30"这样400m限制 →GOMAXPROCS=4，和实际可用 CPU 对齐
kubectl top pods 显示 CPU 使用率低，但服务卡顿怎么办
这是最典型的误判场景：kubectl top 取的是 cAdvisor 汇总后的平均值，掩盖了瞬时 throttling。真正要看的是容器内部指标。
- 进 Pod 执行：
kubectl exec -it <pod-name> -- sh -c 'cat /sys/fs/cgroup/cpu/cpu.stat'
重点关注nr_throttled和throttled_time；只要后者 > 0，说明正在被限频 - 检查 Go 运行时指标：
curl http://localhost:6060/debug/pprof/goroutine?debug=1 | grep -E "(running|runnable)"
如果runnablegoroutine 数长期 > 50，大概率是 P 不够或被 throttle - 别信
docker stats—— 它在容器内看到的是宿主机视角的 CPU，和 Kubernetes cgroup 限频不是一回事
镜像构建阶段就要为CPU限制做准备
Dockerfile 里不光要 CGO_ENABLED=0 静态编译，还得埋好运行时钩子：
- 构建阶段用
golang:1.22-alpine（支持GOEXPERIMENT=fieldtrack优化 GC 停顿） - 运行阶段 Alpine 镜像必须装
ca-certificates，否则 HTTPS 健康检查（livenessProbe）失败导致反复重启，掩盖真实 CPU 问题 - 入口命令改用
sh -c './app -port=$PORT'，确保环境变量能透传给 Go 应用，而不是硬编码端口 - 加一句
HEALTHCHECK --interval=10s --timeout=3s --start-period=30s --retries=3 CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1，让镜像自带健康语义，避免 YAML 里 probe 配置和实际端点脱节
真正难的不是写对 YAML，而是理解 Go 运行时和 Linux cgroup 的耦合点——GOMAXPROCS 怎么映射到 cpu.cfs_quota_us，runtime.LockOSThread 在 throttled 状态下如何表现，这些细节一旦忽略，压测时的毛刺就永远找不到根因。
