设置CPU限制后Kubernetes Pod性能测试中重启而非扩容求助

问题详情 #

• 基于.NET 8.0构建的微服务做性能测试时，给Pod设置CPU限制后，TPS达到20就会触发Pod重启
• 用Dynatrace和kubectl系列命令监控，确认CPU、内存使用率远低于设定阈值——重启前甚至不到40%，从未超过60%
• 移除部署文件里的CPU限制后，Pod能正常扩容，完全不会重启

现有部署配置 #

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app-image:latest
        resources:
          requests:
            memory: "1512Mi"
            cpu: "2"  # CPU请求值
          limits:
            memory: "2Gi"
            cpu: "4"  # CPU限制值
        ports:
        - containerPort: 80

排查与解决建议 #

1. 排查CPU节流（Throttling）问题 #

K8s的CPU限制不是只看平均使用率，短时间内的CPU突发也会触发节流，这会卡死.NET线程池的调度——线程拿不到CPU时间片处理请求，最终导致应用无响应被K8s重启。

• 用kubectl top pod <你的Pod名称>查看CPU throttled指标，或者kubectl describe pod <你的Pod名称>看事件里有没有CPU限流的记录
• 调整.NET线程池初始配置，避免线程饥饿，在应用启动代码里加：

  ThreadPool.SetMinThreads(workerThreads: 100, completionPortThreads: 100);
  

  数值可以根据实际负载调整。

2. 检查节点资源分配与QoS等级 #

你的Pod是Burstable QoS等级（request < limit），如果节点上其他Pod占用了大量CPU，哪怕你的Pod使用率没到自己的limit，也可能拿不到足够的CPU时间片。

• 用kubectl describe node <节点名称>看节点的CPU分配情况，确认剩余可分配资源是否充足
• 缩小request和limit的差距，比如把limit设为3核，或者把request提到3核，让Pod能更稳定地获取CPU资源。

3. 排查.NET 8 GC与线程亲和性问题 #

.NET 8的GC在高负载下可能有CPU波动，搭配K8s的CPU限制可能触发隐性冲突：

• 开启GC日志排查异常，在部署文件的容器里加环境变量：

  env:
  - name: COMPlus_GCLogFile
    value: "/tmp/gc.log"
  - name: COMPlus_GCVerbose
    value: "1"
  

  之后用kubectl exec <Pod名称> -- cat /tmp/gc.log查看日志
• 尝试关闭CPU亲和性，加环境变量COMPlus_Thread_UseAllCpuGroups=0，避免和K8s的CPU限制规则冲突。

4. 确认Pod重启的真实原因 #

别只盯着资源使用率，可能是应用本身崩溃，刚好在TPS到20时触发：

• 用kubectl logs <Pod名称> --previous查看重启前的应用日志，找未处理的异常、崩溃信息
• 用kubectl get events --field-selector involvedObject.name=<Pod名称>看K8s事件，确认是不是CrashLoopBackOff这类应用主动退出的情况，而非资源超限。

5. 调整CPU限制的粒度 #

K8s的CPU单位是毫核（1核=1000m），当前2核request、4核limit的设置太粗犷，试试调小粒度，比如request设为1500m，limit设为3000m，看是否还会触发重启。

内容的提问来源于stack exchange，提问作者Mysterious288