资源限制**：CPU/内存/磁盘上限是多少

资源限制**：CPU/内存/磁盘上限是多少

1️⃣ 考察意图

面试官想看的不是你会背K8s资源单位，而是你在真实Agent系统中如何做资源规划与弹性伸缩的工程判断。考察类型是系统设计+工程取舍。刁钻点在于：Agent任务不是纯Web服务，它混合了LLM推理（GPU/CPU密集）、向量检索（内存密集）、文件处理（I/O密集），资源模型必须按任务类型分拆。答好了能展示你对容器化、资源隔离、动态调度、成本控制的硬实力，以及从单机到集群的扩展思维。

2️⃣ 标准答

Agent系统的资源限制不能一刀切，必须按任务类型分层设计。核心原则：静态配额保底，动态调度弹性，监控驱动调整。

1. 任务类型与资源画像

• LLM推理任务：CPU密集+内存大。例如加载7B模型需14GB内存（FP16），推理时CPU占用高。配额：CPU 4-8核，内存16-32GB，磁盘无特殊要求。
• 向量检索任务：内存密集。例如100万条768维向量，HNSW索引约占用1.2GB内存。配额：CPU 2-4核，内存按索引大小*1.5预留，磁盘用于持久化索引。
• 文件处理任务：I/O密集+磁盘大。例如PDF解析、图片OCR。配额：CPU 2-4核，内存4-8GB，磁盘需临时空间（如10GB）。
• 编排与调度任务：轻量级。例如Agent状态机、工具调用。配额：CPU 1-2核，内存1-2GB。

2. 容器化资源限制

使用Kubernetes的resources.requests和limits。关键取舍：requests设低（保证调度），limits设高（允许突发）。例如推理Pod：requests为CPU 4核、内存16GB；limits为CPU 8核、内存32GB。磁盘用ephemeral-storage限制，避免日志写爆。

3. 动态弹性伸缩

• HPA（Horizontal Pod Autoscaler）：基于CPU/内存使用率，目标值设为70%。但Agent任务有冷启动（模型加载），HPA反应慢。解法：用KEDA（Kubernetes Event-driven Autoscaling），基于队列长度或请求延迟触发扩缩容。例如队列积压>100条时，立即扩容2个Pod。
• VPA（Vertical Pod Autoscaler）：调整单个Pod的CPU/内存配额。适合推理任务，因为模型加载后内存需求稳定。但VPA会重启Pod，需配合PodDisruptionBudget避免服务中断。

4. 监控与告警

• Prometheus+Grafana：采集Pod级别的CPU、内存、磁盘、网络I/O。关键指标：container_cpu_usage_seconds_total、container_memory_working_set_bytes。
• 告警规则：CPU使用率>85%持续5分钟 → 告警并触发HPA；内存使用率>90% → 告警并检查内存泄漏；磁盘使用率>80% → 清理日志或扩容PV。
• 实际坑：Agent任务中，Python的gc不释放内存给OS，导致container_memory_working_set_bytes虚高。解法：用memory.force_empty或限制PYTHONMALLOC，或设置Pod的memory.limit_in_bytes硬限制。

5. 优化策略

• 限制并发：Agent的LLM调用用信号量控制，避免打满CPU。例如单Pod最大并发4个推理请求。
• 缓存：向量检索结果缓存到Redis，减少内存压力。例如相同query的Top-K结果缓存5分钟。
• 资源回收：定时清理临时文件，用cronjob执行find /tmp -type f -atime +1 -delete。推理Pod用preStop钩子卸载模型，释放GPU内存。

6. 成本控制

• Spot实例：推理任务可容忍中断，用AWS Spot或GCP Preemptible VM，成本降60-70%。但需配合PodDisruptionBudget和重试机制。
• 资源超卖：非关键任务（如日志分析）用Burstable QoS，允许超卖。但监控要跟上，避免OOM。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，按Agent任务类型（推理、检索、文件处理）分别设定CPU/内存/磁盘的静态配额，例如推理Pod用4核16GB；第二，用KEDA基于队列长度做动态扩缩容，避免HPA的冷启动延迟；第三，用Prometheus监控并设置告警，同时注意Python内存不释放的坑。总结一句：资源限制要按任务画像分层，静态保底、动态弹性、监控驱动。”

4️⃣ 高频追问 & 应对

追问 1：如果Agent任务中有GPU推理，你怎么管理GPU资源？

用K8s的nvidia.com/gpu资源字段，每个Pod只能请求整数GPU（如1个）。但GPU显存不能超卖，否则OOM。解法：用MIG（Multi-Instance GPU） 切分A100为7个实例，每个分配5GB显存。或者用vGPU方案，但需商业许可。监控用dcgm-exporter采集显存使用率。实际坑：GPU显存泄漏常见，用nvidia-smi定期检查，配合Pod重启策略。

追问 2：你的Agent系统要支持1000个并发用户，资源规划怎么做？

先压测：用Locust模拟1000用户，每个用户触发3个Agent步骤（推理+检索+工具调用）。估算：推理Pod需100个（每个处理10并发），检索Pod需20个（每个处理50并发），文件处理Pod需10个。总资源：CPU约500核，内存约2TB。用K8s集群（5台8核64GB节点）加HPA弹性。成本优化：推理用Spot实例，检索用内存优化型实例（如AWS r5系列）。

追问 3：如果磁盘写爆了，怎么自动恢复？

用K8s的ephemeral-storage限制，设置limits.storage=10Gi。写爆时Pod被驱逐，自动重建。但数据丢失。解法：关键数据写持久卷（PV），用emptyDir只放临时文件。监控用Prometheus的kubelet_volume_stats_used_bytes，告警阈值80%。自动清理：用cronjob执行du -sh /var/log，超过1GB就压缩归档。

5️⃣ 避坑 · 常见错误答法

• ❌ 说“CPU和内存按最大负载设置，比如32核128GB” → ✅ 正确做法：按任务类型分层，推理用4核16GB，检索用2核8GB，避免资源浪费。
• ❌ 说“用HPA基于CPU使用率自动扩缩容就行” → ✅ 正确做法：Agent任务有冷启动，HPA反应慢，需用KEDA基于队列长度或请求延迟触发，同时配合VPA调整Pod配额。
• ❌ 说“磁盘不用管，K8s会自动清理” → ✅ 正确做法：磁盘写爆会导致Pod驱逐，需设置ephemeral-storage限制，并用cronjob定时清理日志和临时文件。

6️⃣ 简历呼应

• 如果你有K8s运维经验：从实际集群资源规划切入，举例你如何用Prometheus监控发现内存泄漏，并调整Pod的limits和requests比例。
• 如果你有Agent开发经验：从任务类型画像切入，说明你如何为LLM推理和向量检索分别设定资源配额，并用KEDA实现弹性伸缩。
• 如果你是校招无项目：聚焦理论，引用K8s官方文档和KEDA论文，说明资源管理的设计原则，并给出一个Demo：用Minikube部署一个Agent服务，设置HPA并压测。
• 《Kubernetes in Action》第15章：资源管理与Pod QoS
• KEDA官方文档：Event-driven Autoscaling for Kubernetes
• Prometheus + Grafana 监控最佳实践（CNCF博客）
• 《Designing Data-Intensive Applications》第6章：分区与资源隔离
• NVIDIA MIG 用户指南：GPU资源切分与隔离