记一次阿里云 K3s 集群 Pod 陷入 ContainerCreating 死锁的排坑纪实 现象描述在一次常规的集群资源监控排查中我们尝试在阿里云 ECS (Master 节点) 上执行kubectl top nodes命令却收到报错error: Metrics API not available排查kube-system命名空间发现核心组件metrics-server和新部署的local-path-provisioner长时间卡在ContainerCreating状态长达数小时。️♂️ 剥茧抽丝排查全过程第一步定位直接死因 —— “难产”的 pause 镜像容器长时间处于Creating状态通常是网络分配或镜像拉取问题。执行kubectl describe pod查看底层EventsWarning FailedCreatePodSandBox ... failed to pull image rancher/mirrored-pause:3.6 ... dial tcp: lookup docker.anyhub.us.kg: Try again诊断结论Kubelet 在初始化 Pod 沙箱时试图拉取基础环境镜像pause:3.6。但配置的第一个镜像加速源某野生镜像站的 DNS 解析超时失败导致连沙箱地基都打不起来。第二步清理失效镜像源发现“案中有案”检查 K3s 的自定义镜像源配置cat /etc/rancher/k3s/registries.yaml发现其中混入了一些已经失效的公网加速源。果断将失效域名剔除并重启k3s进程同时踢掉卡死的 Pod 让其重新投胎。意外发生Pod 依然卡在ContainerCreating。第三步深挖 Root Cause —— 阿里云 DNS “黑洞”为什么清理了死源还是拉不到我们对节点底层的网络进行了暴力测试ping 8.8.8.8—— 秒通外网连通性正常。ping dockerhub.jobcher.com——终端直接挂起死锁。查看/etc/resolv.conf发现系统被托管到了阿里云 VPC 默认内网 DNS100.100.2.136。真相大白当我们请求外部的镜像源域名时阿里云内网 DNS 没有直接返回“域名不存在”而是静默丢弃了请求 (Drop)导致 K8s 进程陷入了极其漫长的网络超时等待 (Try again)。此外如果强行修改/etc/resolv.conf为外部 DNS如 8.8.8.8请求依然会超时疑似 VPC 级对外部 UDP 53 端口存在流量拦截或劫持。第四步绝地反击 —— 引入内网专属源与 DaoCloud 兜底既然公网 DNS 解析被“墙”我们决定“用魔法打败魔法”获取阿里云专属内网镜像源从阿里云容器镜像服务 (ACR) 控制台获取 VPC 内网专属加速器格式如https://[id].mirror.aliyuncs.com将其注入registries.yaml。由于走的是内网直接避开了公网 DNS 拦截。还原内网 DNS确保/etc/resolv.conf恢复为阿里云内网 DNS以便准确解析上述专属内网加速域名。戏剧性的一幕查阅底层的 containerd 拉取日志journalctl -u k3s时我们发现阿里云专属内网源竟然返回了404 Not Found原来rancher/mirrored-pause:3.6相对冷门阿里云镜像库并没有缓存这个特定的旧版本。最终是我们配置在末尾的第三方源DaoCloud (https://docker.m.daocloud.io)稳稳兜底它顶住了压力在 5 秒内返回了200 OK成功将沙箱镜像拽回了本地 总结与避坑指南Pod 为什么部分健康、部分死亡集群中较早启动的coredns能正常运行是因为它早期已将pause镜像缓存于本地。而新建的 Pod 如果被调度到本地无此缓存的节点上就会触发网络拉取一旦网络环境变更如镜像站失效就会惨死在摇篮里。K3s 镜像源的高可用配置至关重要不要盲目相信单一镜像源。强烈建议在/etc/rancher/k3s/registries.yaml中配置多梯队 fallback 方案Tier 1:云厂商 VPC 内网专属源速度最快受网络波动影响最小但可能缺冷门镜像。Tier 2:国内老牌靠谱大厂源如 DaoCloud、南京大学等作为全面缓存的兜底。警惕云厂商的“网关黑洞”在云服务器上排查网络问题时遇到挂起Hang现象一定要第一时间检查/etc/resolv.conf和systemd-resolved。很多时候外网是通的只是你的 DNS 请求被静默丢弃了。
记一次阿里云 K3s 集群 Pod 陷入 ContainerCreating 死锁的排坑纪实
记一次阿里云 K3s 集群 Pod 陷入 ContainerCreating 死锁的排坑纪实 现象描述在一次常规的集群资源监控排查中我们尝试在阿里云 ECS (Master 节点) 上执行kubectl top nodes命令却收到报错error: Metrics API not available排查kube-system命名空间发现核心组件metrics-server和新部署的local-path-provisioner长时间卡在ContainerCreating状态长达数小时。️♂️ 剥茧抽丝排查全过程第一步定位直接死因 —— “难产”的 pause 镜像容器长时间处于Creating状态通常是网络分配或镜像拉取问题。执行kubectl describe pod查看底层EventsWarning FailedCreatePodSandBox ... failed to pull image rancher/mirrored-pause:3.6 ... dial tcp: lookup docker.anyhub.us.kg: Try again诊断结论Kubelet 在初始化 Pod 沙箱时试图拉取基础环境镜像pause:3.6。但配置的第一个镜像加速源某野生镜像站的 DNS 解析超时失败导致连沙箱地基都打不起来。第二步清理失效镜像源发现“案中有案”检查 K3s 的自定义镜像源配置cat /etc/rancher/k3s/registries.yaml发现其中混入了一些已经失效的公网加速源。果断将失效域名剔除并重启k3s进程同时踢掉卡死的 Pod 让其重新投胎。意外发生Pod 依然卡在ContainerCreating。第三步深挖 Root Cause —— 阿里云 DNS “黑洞”为什么清理了死源还是拉不到我们对节点底层的网络进行了暴力测试ping 8.8.8.8—— 秒通外网连通性正常。ping dockerhub.jobcher.com——终端直接挂起死锁。查看/etc/resolv.conf发现系统被托管到了阿里云 VPC 默认内网 DNS100.100.2.136。真相大白当我们请求外部的镜像源域名时阿里云内网 DNS 没有直接返回“域名不存在”而是静默丢弃了请求 (Drop)导致 K8s 进程陷入了极其漫长的网络超时等待 (Try again)。此外如果强行修改/etc/resolv.conf为外部 DNS如 8.8.8.8请求依然会超时疑似 VPC 级对外部 UDP 53 端口存在流量拦截或劫持。第四步绝地反击 —— 引入内网专属源与 DaoCloud 兜底既然公网 DNS 解析被“墙”我们决定“用魔法打败魔法”获取阿里云专属内网镜像源从阿里云容器镜像服务 (ACR) 控制台获取 VPC 内网专属加速器格式如https://[id].mirror.aliyuncs.com将其注入registries.yaml。由于走的是内网直接避开了公网 DNS 拦截。还原内网 DNS确保/etc/resolv.conf恢复为阿里云内网 DNS以便准确解析上述专属内网加速域名。戏剧性的一幕查阅底层的 containerd 拉取日志journalctl -u k3s时我们发现阿里云专属内网源竟然返回了404 Not Found原来rancher/mirrored-pause:3.6相对冷门阿里云镜像库并没有缓存这个特定的旧版本。最终是我们配置在末尾的第三方源DaoCloud (https://docker.m.daocloud.io)稳稳兜底它顶住了压力在 5 秒内返回了200 OK成功将沙箱镜像拽回了本地 总结与避坑指南Pod 为什么部分健康、部分死亡集群中较早启动的coredns能正常运行是因为它早期已将pause镜像缓存于本地。而新建的 Pod 如果被调度到本地无此缓存的节点上就会触发网络拉取一旦网络环境变更如镜像站失效就会惨死在摇篮里。K3s 镜像源的高可用配置至关重要不要盲目相信单一镜像源。强烈建议在/etc/rancher/k3s/registries.yaml中配置多梯队 fallback 方案Tier 1:云厂商 VPC 内网专属源速度最快受网络波动影响最小但可能缺冷门镜像。Tier 2:国内老牌靠谱大厂源如 DaoCloud、南京大学等作为全面缓存的兜底。警惕云厂商的“网关黑洞”在云服务器上排查网络问题时遇到挂起Hang现象一定要第一时间检查/etc/resolv.conf和systemd-resolved。很多时候外网是通的只是你的 DNS 请求被静默丢弃了。
