AWS Spot EC2部署的K3s集群中Job Pod转为Unknown状态的原因排查

你观测到的Reason: Unknown + Exit Code: 255不是你的批处理作业代码主动触发的退出状态，本质是控制面无法从对应节点获取到Pod的真实运行状态时，记录的兜底异常状态。255是K8s生态里kubelet丢失容器运行状态时的通用默认返回码，并非应用本身运行时抛出的错误。

• AWS Spot实例的CPU/资源节流触发进程饥饿
  故障前节点CPU长期打到99%的场景下，首先需要排查AWS层面的实例节流：如果你使用的是burstable规格的Spot实例（比如T系列、部分低成本M/C系列规格），当vCPU信用额度被跑批作业快速消耗殆尽时，AWS会强制对实例做性能节流，极端情况下可将可用计算能力压缩到原性能的5%以下。此时节点上的k3s agent、kubelet进程因为拿不到足够的CPU时间片，会连续数十秒无法完成Pod状态上报，控制面收不到固定周期的心跳后，就会将已经长时间运行的Pod标记为Unknown终止状态。
• K3s轻量化部署的组件资源争抢问题
  K3s为了压缩部署体积，默认将kubelet、containerd、flannel网络组件、控制面（单节点模式下）全部和业务批处理容器运行在同一个节点内核空间，默认没有为系统组件预留独立的CPU/内存配额。当跑批作业把节点CPU吃满到99%时，Linux CFS调度器会将没有优先级保障的kubelet、containerd进程长时间排在运行队列后方，出现响应超时。等CPU资源被释放后，kubelet可能已经丢失了正在运行的容器状态缓存，无法再和containerd完成状态同步，最终控制面侧就会记录为Unknown终止、255退出码。
• Spot实例驱逐前的隐性性能降级
  多数使用者对Spot实例的认知停留在“提前2分钟收到通知后被回收”，但实际上当Spot资源池容量不足时，AWS会先对池内实例做隐形的网络带宽、CPU性能节流，直接表现为节点CPU利用率拉满但实际业务处理性能骤降，节点上的k3s agent和控制面之间的长连接会因为通信延迟过高被超时切断，此时控制面在连接断开瞬间兜底标记的Pod状态就是Unknown，甚至很多场景下根本等不到正式的Spot驱逐通知发出，Pod状态已经先出现异常。

• 拉取对应故障节点的CloudWatch监控指标，定位故障时间点是否存在CPUCreditBalance归零、网络带宽突降、CPU突发性能节流的记录
• 查看节点上/var/log/k3s-agent.log的故障时段日志，确认是否存在连续的containerd connection timeout、keepalive to server timeout类的超时报错
• 为k3s核心系统组件预留固定的CPU配额（通过K3s的--system-cpu参数配置），避免被高负载的批处理作业抢占调度资源

内容的提问来源于stack exchange，提问作者sborpo