1. 问题现象与背景分析最近在Kubernetes集群部署容器时不少同事都遇到了Failed to create pod sandbox: ... DeadlineExceeded desc context deadline exceeded这个经典错误。作为云原生架构师我处理这类问题不下20次今天就来系统梳理下这个报错背后的原因和解决方案。这个错误通常发生在kubelet尝试创建Pod沙箱sandbox时与容器运行时如containerd或docker的通信超时。根据我的经验90%的情况都集中在以下三个方向容器运行时服务异常或响应缓慢节点资源CPU/内存/磁盘不足网络插件配置问题2. 根因诊断方法论2.1 检查容器运行时状态首先查看containerd/docker服务状态systemctl status containerd # 或 docker重点关注服务是否active以及日志中是否有异常。我遇到过几次因为/var/lib分区满导致containerd无法创建容器的情况。2.2 资源瓶颈排查执行以下命令检查节点资源free -h # 内存 df -h # 磁盘 top # CPU nvidia-smi # GPU节点专用特别注意/var/lib/docker或/var/lib/containerd所在分区的可用空间kubelet进程的CPU占用率内存是否被缓存大量占用2.3 网络插件诊断如果是Calico/Flannel等网络插件问题可以kubectl get pods -n kube-system | grep network kubectl logs network-plugin-pod -n kube-system常见网络问题包括网卡MTU配置不匹配IP地址池耗尽节点间网络不通3. 解决方案与调优实践3.1 基础修复方案对于大多数情况按这个顺序操作重启容器运行时systemctl restart containerd清理磁盘空间docker system prune -f # 或crictl rmi --prune调整kubelet超时参数/var/lib/kubelet/config.yamlstreamingConnectionIdleTimeout: 30m nodeStatusUpdateFrequency: 10s3.2 高级调优技巧对于生产环境我推荐这些优化配置containerd的mirror仓库避免拉镜像超时[plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://registry-1.docker.io]调整Pod的QoS级别resources: requests: memory: 64Mi cpu: 250m使用preStop钩子优雅终止lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 30]4. 典型场景案例库4.1 案例1NVIDIA GPU节点超时现象GPU节点部署AI容器时频繁超时解决方案# 重装nvidia-container-runtime apt-get install --reinstall nvidia-container-runtime # 检查默认运行时 cat /etc/docker/daemon.json4.2 案例2CentOS 7内核兼容性问题现象旧版内核3.10导致cgroup v2冲突修复方案# 修改内核参数 echo GRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy0 /etc/default/grub grub2-mkconfig -o /boot/grub2/grub.cfg4.3 案例3Windows节点特有问题对于Windows节点出现的context deadline exceeded需要检查HNS网络状态Get-HnsNetwork调整kubelet参数windows: resolvConf: 5. 长效预防机制建议在生产环境配置以下监控Prometheus告警规则示例- alert: PodSandboxCreationTimeout expr: rate(kubelet_runtime_operations_errors{operation_typecreate_pod_sandbox}[5m]) 0定期维护任务# 清理孤儿容器 crictl rm $(crictl ps -a -q --filter statusexited) # 镜像垃圾回收 kubelet --image-gc-high-threshold85 --image-gc-low-threshold80内核参数优化echo fs.inotify.max_user_instances1024 /etc/sysctl.conf sysctl -p经过这些系统性的优化后我们的生产环境Pod创建失败率从5%降到了0.2%。最关键的是建立了完整的监控-预警-处理闭环机制。
1. 问题现象与背景分析最近在Kubernetes集群部署容器时不少同事都遇到了Failed to create pod sandbox: ... DeadlineExceeded desc context deadline exceeded这个经典错误。作为云原生架构师我处理这类问题不下20次今天就来系统梳理下这个报错背后的原因和解决方案。这个错误通常发生在kubelet尝试创建Pod沙箱sandbox时与容器运行时如containerd或docker的通信超时。根据我的经验90%的情况都集中在以下三个方向容器运行时服务异常或响应缓慢节点资源CPU/内存/磁盘不足网络插件配置问题2. 根因诊断方法论2.1 检查容器运行时状态首先查看containerd/docker服务状态systemctl status containerd # 或 docker重点关注服务是否active以及日志中是否有异常。我遇到过几次因为/var/lib分区满导致containerd无法创建容器的情况。2.2 资源瓶颈排查执行以下命令检查节点资源free -h # 内存 df -h # 磁盘 top # CPU nvidia-smi # GPU节点专用特别注意/var/lib/docker或/var/lib/containerd所在分区的可用空间kubelet进程的CPU占用率内存是否被缓存大量占用2.3 网络插件诊断如果是Calico/Flannel等网络插件问题可以kubectl get pods -n kube-system | grep network kubectl logs network-plugin-pod -n kube-system常见网络问题包括网卡MTU配置不匹配IP地址池耗尽节点间网络不通3. 解决方案与调优实践3.1 基础修复方案对于大多数情况按这个顺序操作重启容器运行时systemctl restart containerd清理磁盘空间docker system prune -f # 或crictl rmi --prune调整kubelet超时参数/var/lib/kubelet/config.yamlstreamingConnectionIdleTimeout: 30m nodeStatusUpdateFrequency: 10s3.2 高级调优技巧对于生产环境我推荐这些优化配置containerd的mirror仓库避免拉镜像超时[plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://registry-1.docker.io]调整Pod的QoS级别resources: requests: memory: 64Mi cpu: 250m使用preStop钩子优雅终止lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 30]4. 典型场景案例库4.1 案例1NVIDIA GPU节点超时现象GPU节点部署AI容器时频繁超时解决方案# 重装nvidia-container-runtime apt-get install --reinstall nvidia-container-runtime # 检查默认运行时 cat /etc/docker/daemon.json4.2 案例2CentOS 7内核兼容性问题现象旧版内核3.10导致cgroup v2冲突修复方案# 修改内核参数 echo GRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy0 /etc/default/grub grub2-mkconfig -o /boot/grub2/grub.cfg4.3 案例3Windows节点特有问题对于Windows节点出现的context deadline exceeded需要检查HNS网络状态Get-HnsNetwork调整kubelet参数windows: resolvConf: 5. 长效预防机制建议在生产环境配置以下监控Prometheus告警规则示例- alert: PodSandboxCreationTimeout expr: rate(kubelet_runtime_operations_errors{operation_typecreate_pod_sandbox}[5m]) 0定期维护任务# 清理孤儿容器 crictl rm $(crictl ps -a -q --filter statusexited) # 镜像垃圾回收 kubelet --image-gc-high-threshold85 --image-gc-low-threshold80内核参数优化echo fs.inotify.max_user_instances1024 /etc/sysctl.conf sysctl -p经过这些系统性的优化后我们的生产环境Pod创建失败率从5%降到了0.2%。最关键的是建立了完整的监控-预警-处理闭环机制。
