近期在测试环境中遇到某个微服务频繁重启的问题，最终排查发现是由于k8s节点的 ephemeral-storage 资源不足被系统驱逐。
🕵️ 异常现象与初步排查
通过 Rancher 查看微服务状态时，发现该服务所在的 Pod 被频繁重启。
为了进一步定位问题，使用如下命令查看 Pod 详细信息：
实际返回信息如下（重点内容已摘录）：
主容器状态：
可以看到：
- Pod 被驱逐（Evicted）
- 驱逐原因是 节点的临时存储空间不足
- 容器的退出码为 137，说明是系统强制终止（SIGKILL）
这表明问题并非出在服务本身，而是底层资源调度层面。
💡 什么是 ephemeral-storage
ephemeral-storage 是 k8s 中的短期本地磁盘资源，与 Pod 生命周期绑定，Pod 一旦终止，其中的 ephemeral-storage 数据也会被清理。它常被用于：使用方式 | 是否占用 ephemeral-storage | 说明 |
emptyDir 卷 | ✅ 是 | Pod 生命周期内的数据存储 |
容器日志（stdout/stderr） | ✅ 是 | 容器日志默认写入本地磁盘 |
/tmp、/var/log 等 | ✅ 是 | 临时文件、缓存、日志等 |
容器内操作如下载文件、缓存 | ✅ 是 | 例如 wget、Java agent dump |
🔍 进一步排查：是日志撑爆了节点磁盘
经过排查发现，导致节点存储空间耗尽的元凶是该服务在
/var/logs 中持续写入大量日志文件，最终触发 kubelet 的资源回收机制。kubelet 默认会根据如下设置执行驱逐操作：
也就是说，当节点可用磁盘空间小于 10% 时，就会主动驱逐 Pod 来释放资源。
🧨 为什么会触发 Evicted？
在 k8s 中，每个节点的 kubelet 会持续监控 CPU、内存、磁盘等资源使用。当系统检测到 磁盘资源紧张 时：
- 会驱逐部分 Pod，释放资源
- 被驱逐的 Pod 状态会标记为
Evicted
- 这种驱逐机制属于 k8s 的资源保护行为
触发驱逐的典型消息如下：
❗ Exit Code 137 是什么？
Exit Code: 137 表示容器收到了 SIGKILL 信号，通常有以下几种可能：- 容器 内存不足（OOM）
- 节点 资源紧张被系统强制回收
- 磁盘压力导致系统回收 ephemeral-storage
本案例符合第三种情况。
🧽 被驱逐 Pod 的资源会自动回收吗？
k8s 会在 Pod 被驱逐后自动执行资源清理：
- 删除容器的临时存储（包括 emptyDir、容器层文件系统、日志等）
- 回收对应节点的磁盘空间
这也是为什么节点在一段时间后“恢复正常”，磁盘资源回落到合理区间。
⚙️ 怎么为 Pod 配置 ephemeral-storage 资源限制
k8s 默认不强制设置
ephemeral-storage，需要手动添加。例如：建议特别关注以下几类 Pod，它们通常容易产生大量临时文件：
- 使用
emptyDir卷或访问/tmp
- 容器内主动写入日志（如日志未打入 ELK）
- Java Agent（如
SecPoint.jar）可能生成大量临时日志或 dump 文件
🧠 延伸：Kubernetes 的 Pod 驱逐优先级
Kubernetes 决定驱逐哪个 Pod 时，会依据以下几个因素：
优先级因素 | 描述 |
PodPriority | 明确设置的优先级值，值越低越容易被驱逐 |
QoS Class | BestEffort > Burstable > Guaranteed，优先驱逐低保障级别 Pod |
实际资源占用 | 占用资源多的 Pod 更可能被选中驱逐 |
驱逐策略配置 | kubelet 的驱逐参数设置决定触发条件 |
示例
kubectl get priorityclasses 返回：✅ 总结
微服务被频繁重启，可能并不是代码或服务异常，而是资源调度问题。
通过本次问题复盘，我们得出以下关键结论：
- Pod Evicted 通常源于节点资源（如
ephemeral-storage）不足
- 没有为 Pod 设置资源 requests/limits 是风险隐患
- 合理配置资源配额 + 监控机制，才能保障系统稳定运行
如果你也遇到类似现象，建议立刻排查节点磁盘资源情况，检查 Pod 是否未设置临时存储配额，并从配置层面进行修复与预防。
- 作者:Yibin
- 链接:https://yibin.dev/article/1f860b50-99a4-80b7-b7b0-ea518b6ed67a
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
