一、资源治理不是把限制写满

Kubernetes 常见线上事故不是 Pod 起不来，而是流量上来后把节点拖慢。很多团队一开始只写 replicas，等 CPU 飙高、内存吃满、Pod 被驱逐，才补 requests 和 limits。资源治理的目标是让调度器、kubelet 和业务进程在同一套边界里工作。

requests 决定调度预留资源，limits 决定运行上限。CPU limit 过低会导致 CFS throttle，接口延迟变长；内存 limit 过低会触发 OOMKilled。常驻服务应从观测数据倒推配置，而不是批量套模板。

二、给 Deployment 写一份能落地的基线

下面是一份 Web API 服务基线配置。它把滚动发布、健康检查和资源边界放在同一个文件里。实际项目里，镜像 tag 应由流水线注入。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  namespace: prod
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      containers:
        - name: order-api
          image: registry.example.com/order-api:2026.07.07
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "300m"
              memory: "512Mi"
            limits:
              cpu: "1000m"
              memory: "1024Mi"
          readinessProbe:
            httpGet: { path: /ready, port: 8080 }
            initialDelaySeconds: 10

发布后看三类指标：Pod 是否频繁重启、CPU 是否长期 throttle、内存工作集是否贴近 limit。接口服务还要看 P95/P99 延迟和错误率。

kubectl -n prod get pod -l app=order-api
kubectl -n prod top pod -l app=order-api
kubectl -n prod describe pod order-api-xxxx
kubectl -n prod rollout status deploy/order-api

三、HPA 要和业务指标一起看

HPA 不是自动扩容的万能开关。如果瓶颈在数据库连接、下游接口或消息堆积，单纯扩 Pod 可能只是把压力更快打到后端。CPU 型服务可以先用 CPU HPA；IO 型服务建议补充 QPS、队列长度或请求延迟指标。

kubectl -n prod autoscale deploy order-api \
  --min=3 --max=12 --cpu-percent=65
kubectl -n prod get hpa order-api

扩容速度要保守。scaleUp 太慢扛不住突发流量，太快会造成冷启动和数据库连接暴涨。scaleDown 更不能激进，否则低峰刚缩容，下一波请求又要重新拉起 Pod。

四、排查顺序要固定下来

资源问题要有固定排查顺序：先看事件，再看重启，再看节点，再看应用指标。事件会直接提示调度失败、镜像拉取失败、探针失败、OOMKilled、驱逐等信息。

kubectl -n prod get events --sort-by=.metadata.creationTimestamp | tail -40
kubectl -n prod get pod -o wide
kubectl -n prod logs deploy/order-api --tail=200

实践建议：先给线上服务补齐 requests、readinessProbe、滚动发布策略和基础 HPA，再按监控数据调整数值。不要一次性把所有服务都调成高 limit，也不要把 HPA 当成容量规划的替代品；稳定集群依赖资源边界、发布节奏和监控告警。