Pod 只写 stdout 也被 Evicted：日志会计入 ephemeral-storage

应用没有往 emptyDir 写文件，Pod 却因 ephemeral-storage 超限被标记为 Evicted，尤其是在打开 DEBUG 日志之后。先查看驱逐消息和容器日志占用：输出到 stdout 并不意味着日志不会落盘，CRI 运行时会按 kubelet 的安排把输出写进节点日志文件。

以下针对 kubelet 能正确统计本地临时存储的节点布局，以及普通磁盘日志。内存型 emptyDir 按内存计量，不能把两类资源混在一起。节点空间不足和单个 Pod 超过自身限制也是不同的驱逐原因。

emptyDir 没增长，日志仍可能用完预算

容器的本地临时存储统计包括可写层和对应的容器日志。Pod 总量还会计入磁盘型 emptyDir 等受管理空间。因此，应用只输出日志，也可能超过容器或 Pod 的临时存储限制。

先从目标对象保存只读信息，以下名称是示例：

kubectl -n team-app describe pod web-abc123
kubectl -n team-app get pod web-abc123 -o yaml
kubectl -n team-app get node worker-a -o yaml

核对实际 Pod 的每个容器 request、limit、卷介质、节点及最近事件，不只看 Deployment 清单。日志采集辅助容器也有自己的文件、缓冲和输出路径。

驱逐消息若明确指出容器或 Pod 本地临时存储超限，沿用量与对应限制排查。若指出 The node was low on resource: ephemeral-storage，还要处理节点整体容量和其他占用；不能认为把这一个 Pod 的 limit 调大就一定解决。request 用于调度，不是让 kubelet 忽略实际空间压力的保证。

日志轮换参数不等于 Pod 的资源限制

当前 kubelet 的容器日志轮换常见默认值是 containerLogMaxSize 为 10Mi，containerLogMaxFiles 为 5。实际集群可以调整，需由节点配置和运行方式确认，不能据默认值推算所有节点。

轮换与空间统计按各自周期运行，日志突增时也不能把“文件大小乘份数”当成绝对不会超出的硬上界。容器预算若很小，日志还没到预期轮换时机就可能触发资源限制。

kubectl logs 通常只能读到当前日志文件，不能把命令返回的字节数当作所有保留文件的总占用。经授权由节点管理者查看对应 Pod UID 的日志目录、kubelet统计和运行时配置，并把日志、可写层与磁盘型 emptyDir 分开核对。读取内容时控制敏感信息和数据量。

如果日志同时写入应用文件，再由 sidecar 读出到 stdout，两份落盘可能重复消耗空间。需要保留哪份文件、采集断点和失败缓冲，都应按日志系统设计确定，不要为了减小数字直接删掉采集文件。

调整的是日志量、保留和资源预算

先排除持续错误重试、大对象重复输出或临时调试级别没有恢复。降低日志量时保留错误、审计和必要追踪信息，确认不会丢掉诊断与合规所需记录。

需要保留历史日志时，使用已经配置好的集中采集与独立存储，并核对采集延迟、重试缓冲及节点保留周期。仅增加一个采集器不会自动删除节点日志，也不保证断网期间没有更多本地积压。

若业务确实需要更多空间，按可测量的日志和工作目录需求制定 requests 与 limits，再检查节点 allocatable、命名空间配额和其他工作负载。这里的数量必须来自项目容量计划，不建议为了消除错误无上限放宽。

修改工作负载模板可能替换 Pod；emptyDir 没有跨 Pod 的持久保证。保存需要的任务状态、日志和配置后安排更新。调整 kubelet 轮换则是节点管理操作，可能影响该节点全部容器和日志采集，托管集群应走平台支持的配置流程。

不要删除运行时目录、关闭驱逐机制，或把 emptyDir 改成 memory 来隐藏磁盘占用；后者会转移到内存预算，可能引入新的失败。

覆盖日志高峰再验收

从原应用入口观察正常负载与调试高峰下的日志增长，确认轮换和采集持续有效，容器及 Pod 临时存储用量在预算内，节点没有持续空间压力。Pod 重建后暂时恢复，只说明旧临时空间离开了当前对象，不能证明日志增长已经受控。

回退时恢复保存的日志级别、工作负载资源和节点配置，并重新核对采集与容量。配置恢复不会找回已被轮换或驱逐删除的日志，也不会恢复已丢失的 emptyDir 数据，应依据保存记录另行恢复。