K8s中Pod因磁盘不足被Evicted，本质是kubelet检测到DiskPressure或ephemeral-storage不足而触发的节点保护机制；需立即清理空间、定位日志/容器等占用源，并通过声明存储限制、调整驱逐阈值及迁移Docker根目录等措施长效防控。
当K8s集群中Docker容器因宿主机磁盘空间不足被驱逐（状态显示为 Evicted），本质是kubelet触发了节点级资源保护机制——检测到 DiskPressure 或 ephemeral-storage 不足，自动终止低优先级Pod以保节点存活。这不是随机行为，而是有明确触发条件和可干预路径。核心思路是：先止血（快速释放空间），再诊断（定位真实占用源），最后加固（防复发）。
立即止血：快速释放节点磁盘空间
驱逐发生后首要目标是让kubelet停止继续驱逐，并恢复调度能力：
- 登录异常节点，运行
df -h查看根分区或/var/lib/docker所在挂载点使用率，确认是否 ≥85%（kubelet默认阈值） - 执行
docker system prune -af --volumes清理所有停止容器、无用镜像、构建缓存和悬空卷（注意：生产环境慎用--volumes，需确认无业务数据卷） - 若日志文件暴涨（如
/var/log/containers/*.log或应用自身日志），用find /var/log -name "*.log" -size +100M -exec truncate -s 0 {} \;清空大日志（不删文件，避免应用句柄失效） - 检查
journalctl --disk-usage，用journalctl --vacuum-size=200M限制系统日志体积
精准定位：找出真正吃掉磁盘的“元凶”
不能只靠 df 看总量，要下钻到具体目录和容器：
- 运行
du -sh /var/lib/docker/* | sort -hr | head -10查看docker子目录（如overlay2、image、volumes）谁占得最多 - 用
docker system df -v显示各镜像、容器、卷的实际磁盘占用，重点关注 RECLAIMABLE 列高的项 - 对高占用容器，进其内部查日志/临时文件：
kubectl exec -it <pod-name> -- sh -c "du -sh /tmp /var/log /app/logs 2>/dev/null | sort -hr | head -5" - 检查是否有未绑定PVC的
emptyDir持久化了大量临时数据（尤其日志轮转失败时）
长期加固：从配置和架构上杜绝复发
单纯清理是治标，必须从K8s资源模型和Docker存储策略双端入手：
- 为所有Pod显式声明 ephemeral-storage requests/limits，例如：
resources:<br> requests:<br> ephemeral-storage: 2Gi<br> limits:<br> ephemeral-storage: 4Gi
避免默认 request=0 导致调度器无法感知存储压力 - 在 kubelet 启动参数中调高磁盘驱逐阈值（谨慎）：
--eviction-hard=imagefs.available<15%,nodefs.available<10%（默认是15%/10%，可根据磁盘大小调整） - 将Docker根目录迁移到大容量独立盘：
修改/etc/docker/daemon.json添加"data-root": "/mnt/docker-data"，重启docker服务 - 对日志密集型服务，强制使用
logrotate或转向 stdout/stderr + 日志采集Agent（如Fluent Bit），禁用文件本地落盘
驱逐不是故障终点，而是系统发出的明确告警信号。处理关键在于把“磁盘满”这个表象，拆解成可测量（df/docker system df）、可操作（prune/truncate）、可预防（resource limits/daemon.json）的三步动作。只要每一步都留痕、可验证，微服务中断就能控制在分钟级内恢复。
