上一篇已讲解 PriorityClass 基础配置与核心原理本文依托四阶段全流程可复现实验完整验证 Pod 调度优先级、资源竞争排队、高优先级抢占三大核心机制深度剖析 Kubernetes 资源紧缺场景下的调度决策逻辑与生产落地规范。目录实验前置条件实验阶段一部署系统基础服务实验阶段二部署关键业务应用实验阶段三触发资源竞争实验阶段四模拟紧急抢占场景实验收尾资源清理规范生产级核心问答题实验核心总结实验前置条件Kubernetes 集群 1.14 及以上版本集群默认自带 Pod 抢占机制无需额外开启至少包含一个工作节点推荐配置 2 核 CPU、2Gi 内存保证实验现象标准可复现。提前预定义三级 PriorityClass划分系统、业务、后台任务调度优先级。优先级配置文件priorityclasses.yamlapiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: sys-essential value: 10000000 globalDefault: false description: 系统核心组件最高调度优先级禁止被抢占 --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: business-critical value: 8000000 globalDefault: false description: 核心业务应用中高优先级仅低于系统组件 --- apiVersion: scheduling.k8s.io/v1 kind: best-effort value: 100000 globalDefault: false description: 后台非核心任务最低优先级资源不足时优先被驱逐执行创建命令kubectl apply -f priorityclasses.yaml实验阶段一部署系统基础服务实验目标是以 DaemonSet 方式部署最高优先级系统核心组件集群每个节点固定运行一个实例抢占底层资源作为实验资源基线同时保障系统组件永不被低优先级服务抢占。配置文件essential-system.yamlapiVersion: apps/v1 kind: DaemonSet metadata: name: node-essential spec: selector: matchLabels: app: node-essential template: metadata: labels: app: node-essential spec: priorityClassName: sys-essential containers: - name: essential image: busybox command: [sleep, 3600] resources: requests: cpu: 300m memory: 200Mi limits: cpu: 300m memory: 200Mi部署与验证命令kubectl apply -f essential-system.yaml kubectl get pods -l appnode-essential -o wide实验预期集群每个节点自动调度运行 1 个 Pod状态均为 Running单节点固定占用 300m CPU、200Mi 内存该级别系统核心组件不会被任何中低优先级 Pod 抢占驱逐。实验阶段二部署关键业务应用实验目标是部署中高优先级核心业务订单服务进一步消耗节点资源让集群整体资源达到饱和临界状态为后续资源竞争、抢占机制测试铺垫环境。配置文件business-critical-app.yamlapiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: replicas: 1 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: priorityClassName: business-critical containers: - name: order image: busybox command: [sleep, 3600] resources: requests: cpu: 800m memory: 500Mi部署与资源核查命令kubectl apply -f business-critical-app.yaml kubectl get pods -l apporder-service -o wide kubectl describe nodes | grep -A 5 Allocated节点资源占用状态系统基础 Pod 占用 300m CPU核心业务 Pod 占用 800m CPU单节点合计占用 1100m CPU节点剩余可用 CPU 不足 900m集群资源临近饱和无充足资源调度新 Pod。实验阶段三触发资源竞争实验目标为部署最低优先级后台批处理任务故意设置多副本超出现有剩余资源验证资源不足时低优先级 Pod 无法正常调度、进入 Pending 排队状态且高优先级业务服务完全不受影响。配置文件background-tasks.yamlapiVersion: apps/v1 kind: Deployment metadata: name: background-task spec: replicas: 3 selector: matchLabels: app: background-task template: metadata: labels: app: background-task spec: priorityClassName: best-effort containers: - name: task image: busybox command: [sleep, 3600] resources: requests: cpu: 500m memory: 300Mi部署与状态观察命令kubectl apply -f background-tasks.yaml kubectl get pods --sort-by.spec.priority -o wide实验现象与结论3 个低优先级后台任务仅部分调度成功其余大量处于 Pending 状态Pod 事件提示 Insufficient CPU、Insufficient Memory 资源不足已运行的系统组件、核心业务 Pod 状态稳定无波动。由此可证资源紧缺时高优先级 Pod 拥有绝对调度优先权低优先级 Pod 只能排队等待集群释放空闲资源。实验阶段四模拟紧急抢占场景实验目标是部署最高优先级紧急任务申请 1 核 CPU 资源刻意超出节点剩余可用资源强制触发 Kubernetes 原生抢占机制验证高优先级任务可驱逐低优先级 Pod、抢占资源完成调度。配置文件emergency-scenario.yamlapiVersion: apps/v1 kind: Deployment metadata: name: emergency-scaler spec: replicas: 1 selector: matchLabels: app: emergency-scaler template: metadata: labels: app: emergency-scaler spec: priorityClassName: sys-essential containers: - name: emergency-handler image: busybox command: [sh, -c, echo EMERGENCY TASK RUNNING; sleep 600] resources: requests: cpu: 1000m memory: 400Mi部署与观察抢占行为命令kubectl apply -f emergency-scenario.yaml kubectl get events --field-selector involvedObject.kindPod --sort-by.metadata.creationTimestamp kubectl get pods --sort-by.spec.priority -o wide抢占现象高优先级紧急任务创建后因资源不足调度失败集群自动触发抢占机制调度器优先选择最低优先级后台 Pod 进行驱逐被驱逐 Pod 进入 Terminating 状态并销毁资源释放后紧急任务立刻完成调度变为 Running系统组件、核心业务等高优先级 Pod 全程不受任何影响。抢占驱逐顺序第一顺位优先驱逐最低优先级 best-effort 类型 Pod第二顺位驱逐同优先级中资源实际使用超请求配额的 Pod同优先级同资源占用情况下优先驱逐启动时间更晚的 Pod调度器永远不会驱逐同级或更高优先级的系统、核心业务 Pod。实验收尾资源清理规范按照优先级从低到高顺序清理资源避免清理过程中再次触发抢占调度保证集群环境干净无残留。kubectl delete -f emergency-scenario.yaml kubectl delete -f background-tasks.yaml kubectl delete -f business-critical-app.yaml kubectl delete -f essential-system.yaml kubectl delete priorityclass sys-essential business-critical best-effort验证清理完成kubectl get pods kubectl get priorityclass终端无任何实验相关 Pod 与 PriorityClass 资源输出即代表清理完毕。生产级核心问答题Q1K8s 抢占机制发生的前提条件是什么A1需同时满足三个条件集群 CPU、内存等核心资源已耗尽无法满足新 Pod 的资源请求新高优先级 Pod 无法正常调度且无可用空闲节点集群已开启 Pod 抢占功能1.14 版本默认开启。满足条件后调度器会主动驱逐低优先级 Pod为高优先级应用腾出资源。Q2集群资源不足时Pod 被驱逐的先后顺序是什么A2遵循固定调度规则优先级数值越低越优先被驱逐同一优先级下资源实际占用超过声明请求的 Pod 优先驱逐同优先级、同资源占用场景创建启动时间更晚的 Pod 优先被驱逐高优先级系统、核心业务 Pod 永远不会被低优先级服务抢占驱逐。Q3哪些工作负载适合配置高 / 低 PriorityClassA3高优先级适合集群核心组件、监控告警、日志服务、CoreDNS、数据库、服务发现等基础组件中高优先级适合订单、支付、用户中心、核心网关、核心 API 接口等关键业务低优先级适合离线批处理、定时任务、数据同步、测试环境服务、非核心后台 Job 等可容忍延迟的任务。Q4被抢占驱逐的低优先级 Pod 后续会怎样A4被驱逐 Pod 立即进入 Terminating 状态执行优雅终止逻辑后被删除若 Pod 由 Deployment、StatefulSet、Job 等控制器管理控制器会自动重建新 Pod新 Pod 重新进入调度队列等待集群出现空闲资源后再完成调度被驱逐 Pod 不会自动原地迁移也无法保留原节点运行环境。实验核心总结PriorityClass 优先级数值越大调度优先级越高资源充足环境下所有优先级 Pod 均可正常调度运行资源紧缺时高优先级应用拥有天然调度优先权低优先级只能排队等待高优先级任务无法调度时会自动触发抢占机制仅驱逐更低优先级 Pod抢占机制不会跨级别驱逐高优先级服务保障核心业务稳定性生产环境需按业务重要性分级配置 PriorityClass从调度层面杜绝核心业务被后台低优先级任务挤垮。