Google Kubernetes Engine出现ErrImagePull: Too Many Links问题求排查思路

我之前处理过类似的K8s 1.8搭配CoreOS的镜像相关问题，给你整理几个针对性的排查方向，一步步来定位：

1. 先确认OverlayFS2是否真的在生效 #

• 登录出问题的Node节点，执行docker info，查看Storage Driver部分，确认输出是overlay2，而不是overlay、devicemapper这类其他驱动
• 检查节点内核版本：CoreOS要支持OverlayFS2需要内核3.18及以上，K8s 1.8对内核也有最低要求，执行uname -r确认内核版本符合要求
• 查看Docker启动参数：检查/etc/systemd/system/docker.service或者相关配置文件，确认是否明确指定了--storage-driver=overlay2，避免因为节点初始化配置遗漏导致驱动没切换

2. 验证K8s镜像清理机制的实际运行状态 #

• 先看节点磁盘使用情况：执行df -h，重点关注/var/lib/docker所在分区的使用率——K8s 1.8的kubelet默认用image-gc-high-threshold=85%和image-gc-low-threshold=80%触发镜像清理，要是磁盘使用率没到阈值，GC根本不会启动
• 查看kubelet日志：执行journalctl -u kubelet | grep "image garbage"，搜索镜像清理相关的日志，确认有没有出现“Failed to garbage collect images”这类错误，或者GC根本没运行的记录
• 手动触发GC测试：临时调整kubelet的GC阈值（测试用，生产环境谨慎操作），执行kubelet --image-gc-high-threshold=50 --image-gc-low-threshold=40，之后用docker images查看旧镜像是否被清理

3. 深挖CoreOS硬链接限制的残留问题 #

• 检查镜像存储分区的文件系统：执行df -T /var/lib/docker，如果是btrfs这类文件系统，即使启用了OverlayFS2，可能还存在额外的硬链接限制
• 统计Docker镜像相关的硬链接数量：执行find /var/lib/docker/overlay2 -type l | wc -l，对比CoreOS旧版本的硬链接限制（比如单目录最多65535个），看是否已经触达上限
• 查看Docker日志：执行journalctl -u docker | grep "hard link"，搜索有没有和硬链接相关的报错信息

4. 排查K8s 1.8镜像清理的已知Bug #

• K8s 1.8的镜像GC存在一些已知问题：比如被已停止但未彻底删除的Pod（比如Terminating/Unknown状态）引用的镜像，GC不会清理；或者镜像元数据损坏导致GC无法识别。执行kubectl get pods --all-namespaces -o wide，检查出问题节点上的Pod状态
• 手动检查节点镜像列表：执行docker images，对比K8s当前运行Pod使用的镜像，看是否有大量未被引用的旧镜像堆积；尝试手动删除一个旧镜像：docker rmi <image-id>，看是否能正常删除，有没有报错

如果能把kubectl describe的具体错误输出（比如Pod或者Node的描述内容）补充出来，能更精准地定位问题，但先从上面几个方向排查，应该能找到线索。

内容的提问来源于stack exchange，提问作者north.mister