1. 问题现象与初步排查那天凌晨3点监控系统突然告警——生产环境的核心业务接口开始大面积返回502错误。作为值班工程师我第一时间检查了Kubernetes集群状态发现部分Pod处于CrashLoopBackOff状态而Nginx入口日志里满是upstream prematurely closed connection的报错。通过kubectl describe pod命令查看异常Pod的事件记录发现关键线索Events: Warning BackOff 2m3s (x12 over 8m14s) kubelet Back-off restarting failed container Warning Evicted 1m58s (x3 over 7m52s) kubelet The node was low on resource: ephemeral-storage这提示我们遇到了经典的磁盘空间问题。但奇怪的是通过df -h查看节点磁盘使用率只有75%左右似乎并未达到Kubernetes默认的85%驱逐阈值。这里就引出了第一个关键知识点Kubernetes的磁盘压力驱逐DiskPressure实际上监控的是文件系统的inode使用率或特定目录如/var/lib/kubelet的使用情况而不仅仅是全局磁盘空间。2. 深度诊断与根因分析2.1 检查真实磁盘使用情况执行以下命令获取精确数据# 检查全局磁盘空间 df -h --outputsource,size,used,avail,pcent,target # 检查inode使用情况 df -i # 检查kubelet目录使用情况 du -sh /var/lib/kubelet/*在我的案例中发现/var/lib/kubelet/pods子目录占用了92%的空间。进一步分析发现某个日志采集Sidecar容器配置了不合理的日志轮转策略导致产生了数千个未压缩的日志文件。2.2 Kubernetes磁盘管理机制解析Kubernetes通过kubelet监控以下磁盘相关指标imagefs.available容器运行时存储镜像的文件系统剩余空间nodefs.availablekubelet使用的根文件系统剩余空间nodefs.inodesFree根文件系统的空闲inode数量当这些指标低于阈值时默认配置见下表kubelet会触发Pod驱逐参数名默认阈值说明imagefs.available15%镜像存储剩余空间nodefs.available10%根文件系统剩余空间nodefs.inodesFree5%空闲inode百分比3. 应急处理与长期解决方案3.1 立即恢复服务执行以下紧急操作# 1. 临时清理旧日志注意保留最近2小时日志 find /var/log/containers -name *.log -mtime 0.5 -exec rm -f {} \; # 2. 手动驱逐问题Pod比kubelet自动驱逐更可控 kubectl drain node-name --ignore-daemonsets --delete-emptydir-data # 3. 检查kubelet配置是否合理 ps aux | grep kubelet | grep -Eviction3.2 预防性配置优化修改kubelet启动参数/etc/kubernetes/kubelet.confapiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration evictionHard: imagefs.available: 20% nodefs.available: 15% nodefs.inodesFree: 10% evictionMinimumReclaim: imagefs.available: 1Gi nodefs.available: 500Mi3.3 日志管理最佳实践所有容器必须配置日志轮转apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: my-app resources: limits: ephemeral-storage: 2Gi volumeMounts: - mountPath: /var/log/my-app name: logs volumes: - emptyDir: sizeLimit: 1Gi name: logs使用Fluent Bit进行日志采集时添加过滤规则[INPUT] Name tail Path /var/log/containers/*.log Rotate_Wait 30 Mem_Buf_Limit 50MB Skip_Long_Lines On Refresh_Interval 104. 深度避坑指南4.1 容易被忽视的磁盘杀手未限制emptyDir卷大小emptyDir默认不限制大小建议始终设置sizeLimit容器镜像堆积定期执行docker system prune -a --filter until24hetcd数据膨胀配置合理的compaction-interval默认5分钟4.2 监控配置建议Prometheus应监控以下关键指标kubelet_volume_stats_available_byteskubelet_volume_stats_capacity_byteskubelet_volume_stats_inodes_freecontainer_fs_usage_bytes示例告警规则- alert: NodeDiskSpaceRunningLow expr: (kubelet_volume_stats_available_bytes{mountpoint/var/lib/kubelet} / kubelet_volume_stats_capacity_bytes{mountpoint/var/lib/kubelet}) * 100 20 for: 30m labels: severity: warning4.3 高级排查技巧当常规清理无效时可以使用lsof查找被删除但未释放空间的文件# 查找已删除但未释放的大文件 lsof L1 | grep -i deleted # 针对docker/containerd的特别检查 find /var/lib/docker/containers/ -type f -name *.log -size 100M5. 架构层面的优化建议对于长期稳定运行的生产环境建议独立存储分区将/var/lib/kubelet挂载到独立磁盘节点选择策略apiVersion: v1 kind: Pod spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/disk-pressure operator: DoesNotExist使用LocalPV替代emptyDir对需要持久化的临时数据使用带配额控制的LocalPV这次事故让我深刻体会到在Kubernetes环境中磁盘管理需要从容器运行时、编排系统、应用设计三个层面综合考虑。建议每个季度进行一次全集群的存储健康检查提前发现潜在风险。