OKD 资源调度与弹性管理实践报告：面向 AI 工作负载

1. 实验背景与目标

随着企业级 AI 应用的普及，如何在有限的 Kubernetes/OKD 集群资源中保障 核心 AI 推理服务 (Inference Service) 的稳定性，成为基础设施团队面临的关键挑战。AI 模型（如 LLM）通常具有“高内存占用”和“计算密集”的特征。

本实验旨在通过实战验证 OKD 的高级调度机制，为构建高可用的 AI 基础设施提供理论依据和最佳实践。

核心验证点：

• QoS (服务质量) 分级：不同资源配置对 Pod 稳定性的影响。
• OOM (内存溢出) 保护：验证系统对内存泄漏或配置不当的防御机制。
• Priority & Preemption (优先级抢占)：模拟资源拥塞场景下，保障核心业务（如 AI 模型）优先运行的机制。

2. 实验环境配置

• 平台版本: OKD 4.x (基于 Kubernetes)
• 实验命名空间: resource-lab
• 实验镜像: hpa-example:latest (模拟业务负载)
• 安全策略: 配置 anyuid SCC 以模拟特定的运行权限需求。

---

3. 实验过程与深度分析

3.1 实验一：QoS 服务质量等级验证

Kubernetes 根据 Pod 的资源请求 (requests) 和限制 (limits) 配置，自动赋予三种 QoS 等级。这决定了节点资源紧缺时，谁先被牺牲。

3.1.1 对比测试

我们部署了三组具有代表性的 Pod：

Pod 名称	配置特征	预期 QoS	适用场景
qos-besteffort	未设置 requests/limits	BestEffort	开发测试、临时任务、低重要性日志收集
qos-burstable	requests < limits	Burstable	这里的 Web 服务、微服务（允许短时突发）
qos-guaranteed	requests == limits	Guaranteed	AI 推理服务、数据库、金融交易核心

3.1.2 实验结果

通过 oc get pod -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass 验证，系统正确识别了三种配置：

NAME             QOS
qos-besteffort   BestEffort
qos-burstable    Burstable
qos-guaranteed   Guaranteed

3.1.3 结论

对于 AI 业务（如 DeepSeek/LLaMA 部署），必须且只能使用 Guaranteed 等级。

• 原因：AI 模型加载到显存/内存后，其占用量是相对固定的。如果允许 Burstable（突发），在节点内存紧张时，AI 服务可能会因为 QoS 优先级较低而被内核强制杀掉（OOM Kill），导致服务中断。

---

3.2 实验二：内存溢出 (OOMKilled) 防御机制

AI 工程师常遇到的问题是模型加载超过显存/内存限制。本实验模拟了这一场景。

3.2.1 模拟场景

• 限制 (Limit): 100 MiB
• 实际申请: 200 MiB (通过 dd 命令瞬间申请)

3.2.2 观测结果

Pod 启动后迅速崩溃，状态变更为 OOMKilled，退出码 137 (SIGKILL)。

State: Terminated
Reason: OOMKilled
Exit Code: 137

3.2.3 结论

• 硬限制：limits.memory 是绝对的硬底线。对于 AI 应用，Limit 设置必须留有 Buffer（缓冲），通常建议为模型权重的 1.2 倍以上，以容纳推理时的上下文 (KV Cache) 增长。
• 监控告警：生产环境必须对 OOMKilled 事件配置高优告警。

---

3.3 实验三：PriorityClass 优先级抢占 (核心业务保护)

在资源有限的边缘计算或私有云场景下，非核心业务（如离线报表、日志分析）不应阻塞核心 AI 业务的调度。

3.3.1 优先级定义

创建了两个自定义 PriorityClass：

• High-Priority-AI: 权重 1,000,000 (模拟核心推理服务)
• Low-Priority-Log: 权重 1,000 (模拟非核心任务)

3.3.2 抢占过程

1. 资源填满：先部署 5 个低优先级 Pod，占满集群可用 CPU 资源。
2. 强制插入：提交一个高优先级 Pod (high-priority-ai-job)。
3. 调度决策：OKD 调度器检测到资源不足，但发现新 Pod 优先级更高。
4. 执行抢占：调度器向 Kubelet 发送指令，驱逐 (Evict) 了一个正在运行的低优先级 Pod。
5. 最终状态：高优先级 Pod 成功 Running，被驱逐的低优先级 Pod 转为 Pending 等待资源。

3.3.3 结论

PriorityClass 是混合部署架构的基石。
在构建 AI 平台时，应默认将“模型推理”设为高优先级，“模型训练”设为中优先级，“数据预处理”设为低优先级。这样可确保在算力吃紧时，对外服务不受影响。

---

4. 最佳实践总结

基于上述实验，针对 AI 工程化落地提出以下建议：

1. 资源锁定：核心模型服务务必配置 requests == limits，确保获得 Guaranteed QoS，防止被邻居干扰。
2. 容量规划：Memory Limit 应包含模型权重 + 最大 Context Window 预估 + 20% 缓冲。
3. 分级保障：利用 PriorityClass 建立“业务分级金字塔”，确保 CEO 演示环境或线上推理服务永远有资源可用。