Kubernetes集群资源限制配置技巧

资源限制不是选修课

在数码工场日常运维中，经常遇到某个服务突然吃光内存，导致整个节点卡死的情况。这时候才想起来没设资源限制，已经晚了。ref="/tag/2020/" style="color:#B2A89E;font-weight:bold;">Kubernetes本身不会替你管资源，得自己动手，在Pod定义里明确写清楚能用多少CPU和内存。

requests 和 limits 的区别

很多人搞不清这两者。requests是调度时用的，告诉Kubelet这个Pod至少需要这么多资源，调度器会找满足条件的节点。limits是运行时上限，超过就会被限制或杀掉。比如一个应用平时跑100m CPU，但偶尔会飙到200m，那就该设requests为100m，limits为250m。

就像租办公室，requests是你签合同写的工位数，公司得按这个给你安排位置；limits是你实际能坐的人数，哪怕临时多来几个人，也不能超过消防规定的上限。

在YAML里怎么写

apiVersion: v1
kind: Pod
metadata:
  name: nginx-limited
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

上面这个例子中，容器启动时保证有64Mi内存和0.25个CPU核心，最多可以跑到128Mi和0.5个核心。超过的话，内存可能被OOM kill，CPU会被节流。

别让默认值坑了你

有些团队用Helm模板部署，图省事不填resources字段，结果所有Pod的requests和limits都是空的。这种Pod会被归入“BestEffort”QoS类，在节点资源紧张时第一个被干掉。就像公司团建坐车，没提前订座的人，最后只能站后排。

建议在命名空间上设置LimitRange，强制所有Pod必须声明资源。比如：

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
  namespace: default
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 250m
    type: Container

这样即使Deployment里没写，也会自动补上默认的request和limit，避免裸奔。

观察与调整

刚上线时预估不准很正常。可以用kubectl top pod看看实际使用情况。比如发现某个服务长期只用50m CPU，但申请了250m，这就是浪费。反过来，如果频繁接近limit，就得考虑上调。就像家里宽带，一个月下来发现天天跑满速，下个月就得升级套餐。

监控数据结合历史趋势，才能定出合理的数值。别指望一次配好，资源限制是个持续优化的过程。