前言干运维久了我最清楚一个问题大部分 K8s 集群乱不是部署乱是调度乱、资源乱。前面我们搞定了迁移、监控、日志、灾备、网络集群已经很稳。但线上长期跑下来一定会出现这些头疼问题测试服务抢占生产资源导致核心业务卡顿部分节点负载爆满部分节点空闲浪费资源流量高峰期 Pod 卡死、低峰期资源空跑浪费重要业务被普通业务挤掉频繁重启没人管资源配额集群资源越跑越少、节点资源泄露这周我带大家完整落地生产级 K8s 调度体系从资源限制、资源配额、亲和性调度、污点容忍最后落地 HPA 自动扩缩容。全部是我线上长期运维沉淀的真实配置解决 90% 的集群资源乱象。一、为什么生产集群必须管控调度和资源新手部署应用直接裸跑 Deployment不写资源、不做限制、不打调度策略。看着能跑上线半个月直接出大事某个日志服务疯狂打日志CPU 内存打满挤挂核心业务所有 Pod 扎堆调度在几个节点集群负载极度不均高峰期流量暴涨Pod 撑不住直接 502低峰期几十副本空跑浪费大量服务器资源生产运维铁律所有业务必须带资源限制 调度策略 自动扩缩容二、基础落地容器资源请求与限制requests/limits这是所有调度的根基也是新人最容易忽略的点。requestsPod最小申请资源调度器依据这个选节点limitsPod最大可用资源防止单容器打爆节点生产标准资源配置模板resources: requests: cpu: 100m memory: 256Mi limits: cpu: 1000m memory: 1Gi完整 Deployment 示例apiVersion: apps/v1 kind: Deployment metadata: name: web-demo spec: replicas: 2 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: nginx:1.24 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 256Mi limits: cpu: 1000m memory: 1Gi运维实战经验requests 绝对不能为 0不然调度器乱分配节点负载失衡limits 必须配置防止 OOM、资源抢占雪崩核心业务预留高 requests普通业务压低配置三、生产资源隔离Namespace 资源配额 ResourceQuota集群多团队、多项目混用必须做资源配额隔离。不然测试环境随便起 Pod、乱开副本直接吃光生产资源。1. 编写资源配额 yamlapiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: dev spec: hard: requests.cpu: 4 requests.memory: 8Gi limits.cpu: 8 limits.memory: 16Gi pods: 202. 生效命令kubectl apply -f resource-quota.yaml效果dev 命名空间下最多 20 个 Pod整体 CPU 内存有上限超配额无法创建新资源完美隔离测试环境四、精细化调度节点亲和性nodeAffinity生产场景非常常用指定业务跑在指定节点比如高 IO 业务跑磁盘高性能节点高 CPU 业务跑计算型节点核心业务跑专属节点1. 先给节点打标签# 给计算节点打标签 kubectl label node k8s-worker01 node-typecpu-high # 给存储节点打标签 kubectl label node k8s-worker02 node-typeio-high2. 节点亲和性调度配置强制调度apiVersion: apps/v1 kind: Deployment metadata: name: cpu-business spec: replicas: 2 selector: matchLabels: app: cpu-app template: metadata: labels: app: cpu-app spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-type operator: In values: - cpu-high containers: - name: cpu-app image: nginx:1.24 resources: requests: cpu: 500m memory: 512Mi运维经验required强制匹配不匹配无法调度preferred优先匹配没有匹配节点也能正常调度五、生产核心污点与容忍Taints Tolerations这是核心业务保稳的杀手锏。作用普通业务禁止调度到核心节点核心业务专属节点独占资源1. 给核心节点打污点# 禁止所有普通Pod调度 kubectl taint node k8s-master01 node-rolecore:NoSchedule2. 核心业务增加容忍spec: tolerations: - key: node-role operator: Equal value: core effect: NoSchedule完整带容忍 DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: core-business spec: replicas: 2 selector: matchLabels: app: core-app template: metadata: labels: app: core-app spec: tolerations: - key: node-role operator: Equal value: core effect: NoSchedule containers: - name: core-app image: nginx:1.24 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2000m memory: 2Gi三种污点模式区别生产必懂NoSchedule新 Pod 无法调度最常用PreferNoSchedule尽量不调度NoExecute直接驱逐现有 Pod节点维护、故障隔离用六、自动扩缩容HPA 动态负载均衡手动改副本是最 low 的运维生产必须流量自动扩容、低峰自动缩容。HPA 可以根据 CPU、内存、自定义指标自动调整副本数。1. 前置条件集群必须安装 metrics-server资源采集依赖helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/ helm repo update helm install metrics-server metrics-server/metrics-server -n kube-system2. 编写 HPA 规则apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-demo minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 753. 生效并查看状态kubectl apply -f hpa.yaml kubectl get hpa效果CPU 使用率超过 70% 自动加副本低负载自动缩容最低保留 2 副本兜底彻底解放双手不用半夜改副本抗流量七、本周生产真实踩坑 详细解决方法带完整代码坑 1不写 requests 导致调度扎堆、节点负载不均现象部分节点 CPU 跑满部分节点空闲集群资源极度不均衡。原因没有 requests 参数调度器无法评估资源占用随机调度。解决方法所有业务强制配置 requestslimits统一规范上线模板如下resources: requests: cpu: 100m memory: 256Mi limits: cpu: 1000m memory: 1Gi坑 2只写 requests 不写 limits节点被 OOM 打崩现象某个业务内存暴涨直接占满节点内存导致节点卡死、集群雪崩。原因没有 limits 限制上限容器可以无限占用节点资源。解决方法生产强制要求所有容器必须配置 limits杜绝资源溢出。坑 3测试服务抢占核心节点资源现象测试服务流量异常挤占生产资源导致核心业务卡顿。解决方法核心节点打污点核心业务加容忍普通服务无法调度kubectl taint node k8s-master01 node-rolecore:NoSchedule坑 4HPA 不生效、无法采集指标现象HPA 状态显示 unknown无法监控 CPU 内存不会自动扩缩容。原因metrics-server 没装、或者证书、权限异常。解决方法重装 metrics-server开启资源采集helm uninstall metrics-server -n kube-system helm install metrics-server metrics-server/metrics-server -n kube-system --set args[0]--kubelet-insecure-tls坑 5节点打标签错误业务调度失败现象Pod 一直 Pending调度失败提示节点不匹配。解决方法核对标签、重新打标签、清理错误标签# 删除错误标签 kubectl label node k8s-worker01 node-type- # 重新打正确标签 kubectl label node k8s-worker01 node-typecpu-high八、本周总结这周我们彻底搞定K8s 资源调度整套体系属于生产运维进阶的核心能力掌握容器资源请求与限制杜绝资源抢占用 ResourceQuota 做多命名空间资源隔离用节点亲和性实现业务定点调度用污点 容忍保障核心业务独占资源落地 HPA 自动扩缩容实现集群智能化运维做完这一套你的集群不再是简单跑服务而是可控、可调度、可扩容、资源不浪费、核心业务不被抢占的标准生产集群。