pod崩溃频繁生成core dump会耗尽磁盘引发diskpressure；需用find -xdev定位core文件、crictl关联容器、清理+临时禁用core_pattern止血，并通过securitycontext和sysctl永久修复。
当Pod因崩溃频繁生成core dump文件，且这些文件未被及时清理或限制，会迅速耗尽宿主机磁盘空间，引发节点DiskPressure、Pod被驱逐、甚至kubelet失联；此时kubectl describe node中会出现disk pressure警告，df -h显示根分区或/var使用率100%，而find /var/lib/containerd/io.containerd.runtime.v2.task -name "core.*" -size +1M能扫出大量GB级core文件。
确认core dump是否真正在宿主机上堆积
登录异常节点，执行：sudo find / -xdev -name "core.*" -type f -size +10M 2>/dev/null | head -20。这一步必须加-xdev防止跨挂载点搜索，否则可能误扫到NFS或块设备上的无关文件；若输出为空，说明core根本没落地，问题不在磁盘占用，而是其他原因（如ulimit -c 0全局禁用）。
检查容器运行时是否启用core dump捕获：对containerd节点，运行sudo crictl ps -a | grep -E "(Exited|Unknown)"，挑一个已退出的容器ID，执行sudo crictl inspect <cid> | grep -A5 -B5 core</cid>；若返回空，说明该容器未配置securityContext.sysctls或linux.capabilities相关项，core dump行为由宿主机内核策略统一控制。
定位生成core的Pod与容器
方法一：用inode耗尽反向追踪
执行df -i，若Use%接近100%，说明是大量小core文件（如每秒崩溃生成一个KB级core）占满inode；此时运行sudo find /var/lib/kubelet/pods -xdev -inum <inode> 2>/dev/null</inode>（需先用sudo ls -i /var/lib/kubelet/pods找可疑目录），可快速锁定归属Pod。
方法二：按时间筛选最近core文件sudo find /var/lib/containerd -xdev -name "core.*" -mtime -1 -ls 2>/dev/null | sort -k7,7nr | head -5。注意：不要用-newermt，部分老版本ext4在纳秒时间戳下不兼容；排序字段7是文件大小，确保优先看到最大的几个罪魁祸首。
方法三：直接关联到Kubernetes对象
拿到core文件完整路径（如/var/lib/containerd/io.containerd.runtime.v2.task/k8s.io/abc123/rootfs/core.12345），提取其中的abc123——这是containerd沙箱ID；再执行sudo crictl ps -a --quiet --name abc123，返回的容器ID即对应Pod；最后用kubectl get pod --all-namespaces -o wide | grep 定位到具体Pod和命名空间。
紧急止血：清理+临时禁用
第一步：立即清理已存在的core文件sudo find /var/lib/containerd /var/lib/kubelet/pods -xdev \( -name "core.*" -o -name "core" \) -mmin +5 -delete 2>/dev/null。这里用-mmin +5而非-mtime +0，避免误删正在写入中的活跃core；2>/dev/null屏蔽Permission Denied提示，不影响主逻辑。
第二步：临时禁用所有新core生成
在宿主机执行：echo "/dev/null" | sudo tee /proc/sys/kernel/core_pattern。这会立即使所有进程生成的core dump被丢弃到黑洞，【此操作不可逆，重启后失效，但能立刻阻止磁盘继续被撑爆】。
第三步：验证禁用效果
在任意Pod里执行kill -SEGV $$（触发段错误），然后ls -l /proc/$(pidof sh)/root/tmp/core*；若无输出，说明禁用成功。注意：不要在生产Pod里反复测试，一次验证即可。
永久修复：从Pod配置层阻断core dump生成
步骤一：修改Pod YAML，在容器securityContext中显式关闭core dump
添加以下字段：
securityContext: sysctls: - name: kernel.core_pattern value: "/dev/null"
步骤二：若应用是Java且JVM启动参数含-XX:+CoreDumpOnCrash，必须同步移除；Go应用需检查是否设置了runtime.LockOSThread()导致信号处理异常，这类场景下即使禁用core_pattern，仍可能因glibc fallback机制生成core.<pid></pid>。
步骤三：为宿主机设置兜底防护
编辑/etc/sysctl.conf，追加kernel.core_pattern = /dev/null，然后执行sudo sysctl -p。这一步确保即使Pod未配置sysctls，宿主机层面也拒绝core落地。
验证修复是否生效
部署一个测试Pod，YAML中故意写错命令触发崩溃（如command: ["/bin/sh", "-c", "kill -SEGV $$"]），等待其重启两次；然后在节点上执行sudo find /var/lib/containerd -name "core.*" -mmin -5 2>/dev/null。若无任何输出，说明配置已生效。
