K8s 生产部署实战：从 Pod 调度到资源配额的完整配置与排障路径

K8s 生产部署实战从 Pod 调度到资源配额的完整配置与排障路径一、线上 Pod 频繁 OOMKill——资源治理才是 K8s 的第一课凌晨两点告警群炸了。前端渲染服务连续 OOMKillPod 反复 CrashLoopBackOff页面白屏。排查发现资源请求没设限制没配所有 Pod 在节点上野蛮抢占内存最终被内核 OOM Killer 一刀斩掉。这不是个例。K8s 集群上线第一步不是搞什么花哨的 Service Mesh而是把资源模型吃透。Pod 调度、资源配额、LimitRange——这三件事没搞明白集群就是一颗定时炸弹。核心痛点清单资源请求未设置调度器无法准确评估节点负载Pod 被调度到已满节点Limit 缺失单 Pod 可无限制吞噬节点资源拖垮同节点所有业务QoS 等级混乱全部 BestEffort资源紧张时最先被驱逐的就是关键业务ResourceQuota 未启用命名空间无资源上限一个团队就能吃掉整个集群二、Pod 调度与资源模型的底层机制K8s 资源模型的核心请求Request是调度的依据限制Limit是运行的边界。调度器只看 Requestkubelet 执行 Limit。graph TD A[Pod 提交] -- B{Request 是否满足?} B --|否| C[Pending - 资源不足] B --|是| D[调度器打分排序] D -- E[选择最优节点] E -- F[kubelet 启动容器] F -- G{运行时超 Limit?} G --|CPU| H[Throttle 限流] G --|Memory| I[OOMKill 终止] G --|正常| J[稳定运行]QoS 等级由 Request 和 Limit 的配置关系决定QoS 等级条件驱逐优先级GuaranteedCPU/Memory 的 Request Limit最低最后被杀Burstable至少一个容器设置了 Request中等BestEffortRequest 和 Limit 都没设最高最先被杀调度器的打分策略中NodeResourcesFit插件会根据 Request 计算节点剩余资源NodeResourcesBalancedAllocation插件会尽量让 CPU 和内存均衡分配。这两者都只看 Request不看实际使用量。三、生产级资源配置与调度策略3.1 Pod 资源配置模板apiVersion: v1 kind: Pod metadata: name: frontend-render namespace: production labels: app: frontend-render qos: guaranteed spec: containers: - name: render image: registry.example.com/frontend-render:v2.3.1 # Request调度依据必须与 Limit 一致以获得 Guaranteed QoS resources: requests: cpu: 500m # 0.5 核调度器按此值分配 memory: 512Mi # 调度器按此值判断节点剩余 limits: cpu: 500m # CPU 硬上限超限被 throttle memory: 512Mi # 内存硬上限超限被 OOMKill # 存活探针检测进程是否存活失败则重启容器 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 10 failureThreshold: 3 # 就绪探针检测是否可接收流量失败则从 Service 摘除 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 # 优先级类高优先级 Pod 可抢占低优先级 priorityClassName: high-priority # 亲和性调度到标记了 SSD 的节点 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: disk-type operator: In values: - ssd tolerations: # 容忍专用节点的污点允许调度到高配节点 - key: dedicated operator: Equal value: frontend effect: NoSchedule3.2 LimitRange命名空间级默认值兜底防止有人提交无资源声明的 Pod用 LimitRange 兜底apiVersion: v1 kind: LimitRange metadata: name: default-limits namespace: production spec: limits: - type: Container # 默认值未设置 Request/Limit 时自动注入 default: cpu: 200m memory: 256Mi defaultRequest: cpu: 100m memory: 128Mi # 上限单个容器不允许超过此值 max: cpu: 4 memory: 8Gi # 下限单个容器不允许低于此值 min: cpu: 50m memory: 64Mi3.3 ResourceQuota命名空间资源总量硬限制apiVersion: v1 kind: ResourceQuota metadata: name: team-a-quota namespace: team-a spec: hard: # 计算资源总量上限 requests.cpu: 16 requests.memory: 32Gi limits.cpu: 32 limits.memory: 64Gi # 对象数量限制防止资源泄露 pods: 50 services: 10 persistentvolumeclaims: 203.4 HPA基于指标自动扩缩容apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: frontend-render-hpa namespace: production spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: frontend-render minReplicas: 3 maxReplicas: 20 metrics: # CPU 利用率超过 70% 触发扩容 - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # 内存利用率超过 80% 触发扩容 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 behavior: scaleDown: # 缩容稳定窗口5 分钟内不缩容防止抖动 stabilizationWindowSeconds: 300 policies: # 每次最多缩掉 25% 的 Pod - type: Percent value: 25 periodSeconds: 60四、资源模型的边界与架构权衡Request 设大了浪费设小了 OOM——这个度怎么拿捏Request 偏大节点资源利用率低成本浪费。生产环境建议用 VPAVertical Pod Autoscaler推荐值作为参考起点Request 偏小节点超卖资源争抢性能抖动。CPU 超卖可接受throttle 降速但不杀进程内存超卖不可接受OOMKill 直接终止Guaranteed 的代价Request Limit 意味着资源独占集群整体利用率偏低。核心服务用 Guaranteed批处理任务用 BurstableBestEffort 的禁用场景生产环境必须通过 LimitRange 禁止 BestEffort Pod否则一个无资源声明的 Pod 就能拖垮整节点调度亲和性的坑requiredDuringSchedulingIgnoredDuringExecution硬性要求满足不了就 Pending。节点故障时 Pod 不会迁移因为新节点可能也不满足preferredDuringSchedulingIgnoredDuringExecution软性偏好调度器尽量满足但不保证。生产环境优先用这个污点容忍Taint/Toleration与亲和性组合使用时容易出现调度死锁——所有 Pod 都想去同一批节点但污点又挡住了HPA 的局限指标延迟Metrics Server 采集间隔 15-30 秒扩容响应有滞后冷启动问题新 Pod 启动到就绪需要时间突发流量下可能来不及缩容抖动必须配置stabilizationWindowSeconds否则流量波动时 Pod 数量反复增减五、总结K8s 资源治理的核心逻辑Request 管调度Limit 管运行QoS 管驱逐优先级。生产集群必须做到三点——所有 Pod 设置 Request 和 Limit、通过 LimitRange 兜底默认值、通过 ResourceQuota 限制命名空间总量。Guaranteed QoS 适用于核心在线服务Burstable 适用于批处理和可降级服务BestEffort 在生产环境应被禁止。HPA 配合 VPA 可以实现动态资源调整但需注意冷启动延迟和缩容抖动问题。调度亲和性和污点容忍要组合使用避免硬性约束导致调度死锁。